By the way my test3 functions is super fast @time test3(r) 0.000032 seconds (4 allocations: 160 bytes)
On Friday, September 23, 2016 at 12:48:50 AM UTC+3, Tsur Herman wrote: > > > On my side both function perform equally. although test2 had to be timed > twice to get to the same performance. > > julia> test2(x)= sum( [t^2 for t in x] ) > > julia> @time test2(r) > 0.017423 seconds (13.22 k allocations: 1.339 MB) > > julia> @time test2(r) > 0.000332 seconds (9 allocations: 781.531 KB) > > I think the discrepancy comes from the JITing process because if I time > it without using the macro @time, it works from the first run. > > julia> test2(x)= sum( [t^2 for t in x] ) > WARNING: Method definition test2(Any) in module Main at REPL[68]:1 > overwritten at REPL[71]:1. > test2 (generic function with 1 method) > > julia> tic();for i=1:10000 ; test2(r);end;toc()/10000 > elapsed time: 3.090764498 seconds > 0.0003090764498 > > About the memory footprint -> test2 first constructs the inner vector then > calls sum. > > since the type was not inferred the zero-element could not be created. >> > The sum of an empty set or vector is undefined it is not zero. > you can rewrite it in a more explicit way > > test3(r) = begin > total = Float64(0); > for t in r total+=t ;end;end > > > > > > > On Thursday, September 22, 2016 at 10:50:39 PM UTC+3, Patrick Kofod > Mogensen wrote: >> >> I've seen the same, and the answer I got at the JuliaLang gitter channel >> was that it could not be inferred because r could be of length 0, and in >> that case, the return type could not be inferred. My Julia-fu is too weak >> to then explain why the comprehension would be able to infer the return >> type. >> >> On Thursday, September 22, 2016 at 9:27:37 PM UTC+2, Stefan Karpinski >> wrote: >>> >>> I see the same, yet: >>> >>> julia> r = rand(10^5); >>> >>> julia> @time test1(r) >>> 0.000246 seconds (7 allocations: 208 bytes) >>> 33375.54531253989 >>> >>> julia> @time test2(r) >>> 0.001029 seconds (7 allocations: 781.500 KB) >>> 33375.54531253966 >>> >>> >>> So test1 is efficient, despite the codewarn output. Not sure what's up. >>> >>> On Thu, Sep 22, 2016 at 2:21 PM, Christoph Ortner <christop...@gmail.com >>> > wrote: >>> >>>> I hope that there is something I am missing, or making a mistake in the >>>> following example: >>>> >>>> r = rand(10) >>>> test1(r) = sum( t^2 for t in r ) >>>> test2(r)= sum( [t^2 for t in r] ) >>>> @code_warntype test1(r) # return type Any is inferred >>>> @code_warntype test2(r) # return type Float64 is inferred >>>> >>>> >>>> This caused a problem for me, beyond execution speed: I used a >>>> generator to create the elements for a comprehension, since the type was >>>> not inferred the zero-element could not be created. >>>> >>>> Is this a known issue? >>>> >>> >>>
