Funny enough, very similar question today on Stackoverflow: http://stackoverflow.com/questions/27673278/why-is-this-devectorized-julia-code-over-20x-too-slow/
@ivo welch, see https://github.com/JuliaLang/julia/issues/8870 and the linked issues from it. On Sunday, December 28, 2014 5:22:52 PM UTC+13, ivo welch wrote: > > > would it make sense to warn the user about "slowing down" global variables > from julia itself? and/or about other slowing constructs that are almost > always "beginner's mistakes" that julia can guess at? my guess is that > if a program does not reuse a global outside its context, this is defacto a > programmer error that julia can warn the user about. > > in fact, this particular one is so common a scenario and programmer > mistake that it is worth dealing with. ideally, the compiler would > recognize this mistake and auto-rewrite the code. global variables would > be local by default, and assigned into a global only once at program (or > local context) termination. the easier solution would be to issue a > warning when a variable could be declared local but is declared global. > (this could be a warning with a pragma to turn it off.) > > it is so easy to make suggestions when one does not have to write code... > > > On Sunday, December 28, 2014 11:24:32 AM UTC+8, Bob Quazar wrote: >> >> The devectorized code below should be much faster than equivalent >> vectorized code, according to "Fast Numeric Computation in Julia >> <http://julialang.org/blog/2013/09/fast-numeric/>" on the official >> julialang.org web site. But I find just the opposite! >> >> julia> x = randn(10000000); >>> julia> y = randn(10000000); >>> julia> r = zeros(10000000); >>> julia> @time r[:] = exp(-abs(x-y)); >>> elapsed time: 1.233813455 seconds (320000432 bytes allocated, 14.20% gc >>> time) >>> julia> @time for i = 1:length(x) >>> r[i] = exp(-abs(x[i]-y[i])) >>> end >>> elapsed time: 10.326934093 seconds (1599983704 bytes allocated, 21.29% >>> gc time) >> >> >> Can someone explain what's going on? The devectorized version appears to >> allocate 5x as much memory. >> >> Thanks much! >> >>
