I have some issues that I did n’t get them well.
1- Why when using · @btime, it is needed to used
$ before the parameters?
B. below constant or non-constant variables?
A = randn(3,3); b = randn(3);
julia> @btime A\b
julia> @btime $A\$b
Check out this previous thread and the linked SO answer
I recently asked a
Stack Overflow question about interpolating into benchmarking expressions. But I still have some lingering confusion about the impact on performance of passing global variables as arguments to functions. The Julia manual in the Performance Tips section says
A global variable might have its value, and therefore its type, change at any point. This makes it difficult for the compiler to optimize code using global variables. Variables should be local, or passed as arguments to f…
In your example,
$ is used to get a sense of the performance of
either local and type-stable inside a function (including if they’re arguments) or they’re declared as
const globals. It’s the former that most folks are interested in when benchmarking because that’s the happy path for high-performance Julia.
You’ve not declared
const, so they’re not constant.
Thanks for your reference.
B are not const. Are they global? As far as I know, they are not global because no
global word is put in front of them, correct?
they are global. Any variable that isn’t declared in a scope (i.e. a function or let block) is global.
so the benefit of using the keyword
global in front of a variable is to let it be seen (global) out of its scope, right?
global keyword only matters for code like
x = 5
x=5 would define a new local variable.
Ah, I see where the disconnect is. The 4x difference you’re seeing in sin isn’t really a 4x multiple. It’s a ~constant 15ns. In that 15ns, Julia looks up the method table for sin, figures out which method to dispatch to, then calls the appropriate sin(::Float64). The remaining 5ns is actually doing the computation of the sine. If you have a heavy duty computation, calling it from global scope isn’t going to make it run 4x slower. It’ll make it run 15ns slower. The time it takes to do dyna…
15ns is actually consumed during the compilation stage not during the run-time, and since the performance matters during runt-time, so
$ is used, correct?
The goal of BenchmarkTools is to assess the runtime of a function as though it were written that way inside another function. The trouble is that when you write sin(x), it’s not clear whether x is a global (and slow, see the very first bullet of the [performance tips]) or a local variable. The special $ flag is how BenchmarkTools can distinguish these two cases. The same thing goes when you write sin(0.5) — that 0.5 could be a hard-coded constant (and eligible for constant propagation) or a r…
How can the BenchmarkTools distinguish between these two cases? Does it start to check the performance after the compilation stage is finished, at which the case (type) of variables is known?