And Stephen Vavasis writes:
> You say that probably no improvement would be possible if 'fast'
> updating were available for immutable in my code. In this case, why
> is there such a huge difference between fast and slow updating for
> the non-immutable case? Is there some optimization available in the
> 'immutable' case but not the 'type' case, or is this a compiler bug?
Likely, not possible... And I admit I'm going more by
familiarity with gcc optimizations than llvm ones.
> function immut_upd_slow()
[...]
> @inbounds a[i] = xyimmut(a[i].x, a[i].y, a[i].z, true)
With a value type (and without aliasing, also without signaling
NaNs signaling on motion), the compiler could detect that
a[i].{x,y,z} do not change. Because it's a value type and not a
general object, the compiler could know there's no allocation.
An allocation *may* trigger a GC, so there are side-effects. I
know gcc pulls this off with C structs in some doubled-precision
code.
I suppose Julia could maintain extra attributes on general
objects to decide if they're morally value objects, but that
wanders close to sufficiently smart compiler territory.
Besides, if you really want this to be fast, the "array" should
be an object holding three arrays: one Int array for x, one
Float64 2-d array for y & z, and one Bool array for summed. Just
like Matlab's complex, and with all the interop issues, but then
you avoid needless cache lines, open up vectorization, etc...
