Yea those were averages of 5 runs each, minus the first for JIT.
On Friday, January 22, 2016 at 1:24:00 PM UTC-5, Stefan Karpinski wrote: > > Make sure you time it twice – the faster version may generate more code. > > On Fri, Jan 22, 2016 at 1:21 PM, Bryan Rivera <future...@gmail.com > <javascript:>> wrote: > >> dude.. >> >> dictZ = Dict{Int, Int}() >> >> for z = 1:1000 >> dictZ[z] = z >> end >> >> function testNoFunCopy() >> for z = 1:1000 >> function2.z = dictZ[z] >> # do whatever with function2, including making a copy >> end >> end >> >> @code_llvm testNoFunCopy() >> @code_native testNoFunCopy() >> >> @time testNoFunCopy() >> >> # Test to see if multiple functions are created. They are. >> # We would only need to create a single function if we used julia anon, >> but its time inefficient. >> >> dict = Dict{Int, Any}() >> >> for z = 1:1000 >> function2 = @anon c -> (c + z) >> dict[z] = function2 >> end >> >> a = 1 >> b = 2 >> >> function testWithFunCopy() >> for z = 1:1000 >> function1(a,b, dict[z]) >> end >> end >> >> >> @code_llvm testWithFunCopy() >> @code_native testWithFunCopy() >> >> @time testWithFunCopy() >> >> >> For 1000 elements: >> >> 0.00019s vs 0.035s respectively >> >> Thanks! >> >> Is the reason the faster code has more allocations bc it is >> inserting vars into the single function? (Opposed to the slower >> code already having its vars filled in.) >> >> >> On Friday, January 22, 2016 at 12:23:59 PM UTC-5, Tim Holy wrote: >>> >>> Just use >>> >>> z = 1 >>> function2 = @anon c -> c + z >>> for z = 1:100 >>> function2.z = z >>> # do whatever with function2, including making a copy >>> end >>> >>> --Tim >>> >>> On Friday, January 22, 2016 08:55:25 AM Cedric St-Jean wrote: >>> > (non-mutating) Closures and FastAnonymous work essentially the same >>> way. >>> > They store the data that is closed over (more or less) and a function >>> > pointer. The thing is that there's only one data structure in Julia >>> for all >>> > regular anonymous functions, whereas FastAnonymous creates one per >>> @anon >>> > site. Because the FastAnonymous-created datatype is specific to that >>> > function definition, the standard Julia machinery takes over and >>> produces >>> > efficient code. It's just as good as if the function had been defined >>> > normally with `function foo(...) ... end` >>> > >>> > >>> > for z = 1:100 >>> > function2 = @anon c -> (c + z) >>> > >>> > dict[z] = function2 >>> > end >>> > >>> > >>> > So we end up creating multiple functions for each z value. >>> > >>> > >>> > In this code, whether you use @anon or not, Julia will create 100 >>> object >>> > instances to store the z values. >>> > >>> > The speed difference between the two will soon be gone. >>> > <https://github.com/JuliaLang/julia/pull/13412> >>> > >>> > Cédric >>> > >>> > On Friday, January 22, 2016 at 11:31:36 AM UTC-5, Bryan Rivera wrote: >>> > > I have to do some investigating here. I thought we could do >>> something >>> > > like that but wasn't quite sure how it would look. >>> > > >>> > > Check this out: >>> > > >>> > > This code using FastAnonymous optimizes to the very same code below >>> it >>> > > where functions have been manually injected: >>> > > >>> > > using FastAnonymous >>> > > >>> > > >>> > > function function1(a, b, function2) >>> > > >>> > > if(a > b) >>> > > >>> > > c = a + b >>> > > return function2(c) >>> > > >>> > > else >>> > > >>> > > # do anything >>> > > # but return nothing >>> > > >>> > > end >>> > > >>> > > end >>> > > >>> > > >>> > > z = 10 >>> > > function2 = @anon c -> (c + z) >>> > > >>> > > >>> > > a = 1 >>> > > b = 2 >>> > > @code_llvm function1(a, b, function2) >>> > > @code_native function1(a, b, function2) >>> > > >>> > > Manually unrolled equivalent: >>> > > >>> > > function function1(a, b, z) >>> > > >>> > > if(a > b) >>> > > >>> > > c = a + b >>> > > return function2(c, z) >>> > > >>> > > else >>> > > >>> > > # do anything >>> > > # but return nothing >>> > > >>> > > end >>> > > >>> > > end >>> > > >>> > > >>> > > function function2(c, z) >>> > > >>> > > return c + z >>> > > >>> > > end >>> > > >>> > > >>> > > a = 1 >>> > > b = 2 >>> > > z = 10 >>> > > >>> > > >>> > > @code_llvm function1(a, b, z) >>> > > >>> > > @code_native function1(a, b, z) >>> > > >>> > > However, this is a bit too simplistic. My program actually does >>> this: >>> > > >>> > > # Test to see if multiple functions are created. They are. >>> > > # We would only need to create a single function if we used julia >>> anon, >>> > > but its time inefficient. >>> > > >>> > > dict = Dict{Int, Any}() >>> > > for z = 1:100 >>> > > >>> > > function2 = @anon c -> (c + z) >>> > > >>> > > dict[z] = function2 >>> > > >>> > > end >>> > > >>> > > >>> > > a = 1 >>> > > b = 2 >>> > > >>> > > function test() >>> > > >>> > > function1(a,b, dict[100]) >>> > > function1(a,b, dict[50]) >>> > > >>> > > end >>> > > >>> > > @code_llvm test() >>> > > @code_native test() >>> > > >>> > > >>> > > >>> > > So we end up creating multiple functions for each z value. We could >>> use >>> > > Julia's anon funs, which would only create a single function, >>> however >>> > > these >>> > > lamdas are less performant than FastAnon. >>> > > >>> > > So its a space vs time tradeoff, I want the speed of FastAnon, >>> without the >>> > > spacial overhead of storing multiple functions. >>> > > >>> > > Can we be greedy? :) >>> > > >>> > > On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean >>> wrote: >>> > >> Something like this? >>> > >> >>> > >> function function1(a, b, f) # Variable needed in callback fun >>> injected. >>> > >> >>> > >> if(a > b) >>> > >> >>> > >> c = a + b >>> > >> res = f(c) # Callback function has been injected. >>> > >> return res + 1 >>> > >> >>> > >> else >>> > >> >>> > >> # do anything >>> > >> # but return nothing >>> > >> >>> > >> end >>> > >> >>> > >> end >>> > >> >>> > >> type SomeCallBack >>> > >> >>> > >> z::Int >>> > >> >>> > >> end >>> > >> Base.call(callback::SomeCallBack, c) = c + callback.z >>> > >> >>> > >> function1(2, 1, SomeCallBack(10)) >>> > >> >>> > >> Because of JIT, this is 100% equivalent to your "callback function >>> has >>> > >> been injected" example, performance-wise. My feeling is that .call >>> > >> overloading is not to be abused in Julia, so I would favor using a >>> > >> regular >>> > >> function call with a descriptive name instead of call overloading, >>> but >>> > >> the >>> > >> same performance guarantees apply. Does that answer your question? >>> > >> >>> > >> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera >>> wrote: >>> > >>> I think what I wrote above might be too complicated, as it is an >>> attempt >>> > >>> to solve this problem. >>> > >>> >>> > >>> In essence this is what I want: >>> > >>> >>> > >>> >>> > >>> # wasmerged, _, _, _ = elide_pairwise!(ttree1, ttree2, canmerge; >>> nbrs=idbgv) >>> >>> > >>> function function1(a, b, onGreaterThanCallback) >>> > >>> >>> > >>> if(a > b) >>> > >>> >>> > >>> c = a + b >>> > >>> res = onGreaterThanCallback(c, z) >>> > >>> return res + 1 >>> > >>> >>> > >>> else >>> > >>> >>> > >>> # do anything >>> > >>> # but return nothing >>> > >>> >>> > >>> end >>> > >>> >>> > >>> end >>> > >>> >>> > >>> >>> > >>> global onGreaterThanCallback = (c) -> c + z >>> > >>> >>> > >>> function1(a, b, onGreaterThanCallback) >>> > >>> >>> > >>> >>> > >>> Problems: >>> > >>> >>> > >>> The global variable. >>> > >>> >>> > >>> The anonymous function which has performance impact (vs other >>> > >>> approaches). We could use Tim Holy's @anon, but then the value of >>> `z` >>> > >>> is >>> > >>> fixed at function definition, which we don't always want. >>> > >>> >>> > >>> I think that the ideal optimization would look like this: >>> > >>> function function1(a, b, z) # Variable needed in callback >>> fun >>> > >>> >>> > >>> injected. >>> > >>> >>> > >>> if(a > b) >>> > >>> >>> > >>> c = a + b >>> > >>> res = c + z # Callback function has been injected. >>> > >>> return res + 1 >>> > >>> >>> > >>> else >>> > >>> >>> > >>> # do anything >>> > >>> # but return nothing >>> > >>> >>> > >>> end >>> > >>> >>> > >>> end >>> > >>> >>> > >>> >>> > >>> function1(a, b, z) >>> > >>> >>> > >>> In OO languages we would be using an abstract class or its >>> equivalent. >>> > >>> >>> > >>> But I've thought about it, and read the discussions on >>> interfaces, and >>> > >>> >>> > >>> don't see those solutions optimizing the code out like I did >>> above. >>> > >>> >>> > >>> Any ideas? >>> >>> >