Le jeudi 22 septembre 2016 à 14:54 -0700, Tsur Herman a écrit :
> By the way my test3 functions is super fast
> 
>  @time test3(r)
>   0.000032 seconds (4 allocations: 160 bytes)
Beware, if you don't return 'total' from the function, LLVM optimizes
away the whole loops and turns the function into a no-op (have a look
at @code_llvm or @code_native).


Regards


> > 
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> > > 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.
> > > 
> > > > 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?
> > > > > 
> > > > 
> > > > 
> > > 
> > 

Reply via email to