Curiously, I don't even see it on my copy of julia 0.3. Will, one tip: julia optimizes within functions. Anytime you see something weird like this, try to separate allocation and operation into two separate functions. That way, the function that's performing lots of computation will receive a concrete type as an input, and be well-optimized.
--Tim On Friday, December 05, 2014 06:38:28 PM John Myles White wrote: > I think this might be a problem with Julia 0.3. I see it on Julia 0.3, but > not on the development branch for Julia 0.4. > > — John > > On Dec 5, 2014, at 6:27 PM, Will Dobbie <[email protected]> wrote: > > Hi, > > > > I have a program which copies elements between two arrays of immutables in > > a tight loop. The sizes of the arrays never change. I've been struggling > > to get it to avoid spending a large chunk of its time in the garbage > > collector. I have an example of what I mean below. > > > > With arrays of Int64 I get: > > elapsed time: 0.164429425 seconds (0 bytes allocated) > > > > With arrays of an immutable the same size as Int64 I get: > > elapsed time: 1.421834146 seconds (320000000 bytes allocated, 15.97% gc > > time) > > > > My understanding was arrays of immutables should behave like arrays of > > structs in C and not require heap allocation. Is there a way I can > > achieve that? I'm using Julia 0.3.3. > > > > Thanks, > > Will > > > > > > > > module immtest > > > > immutable Vec2 > > > > x::Float32 > > y::Float32 > > > > end > > > > # typealias element_type Vec2 # Results in allocation in the > > loop below > > typealias element_type Int64 # Does not cause allocation > > > > function runtest(reps) > > > > dst = resize!(element_type[], 100_000) > > src = resize!(element_type[], 10) > > > > @time begin > > > > for i=1:reps > > > > copy!(dst, 1000, src, 1, length(src)) > > # dst[1000:1009] = src # same performance as > > above > > > > end > > > > end > > > > end > > > > runtest(10_000_000) > > > > end
