This surprised me:
immutable A
a::UInt32
b::UInt32
c::UInt64
d::UInt64
end
sizeof(A[A(0,0,0,0), A(0,0,0,0)]) # 48
immutable B
a::UInt32
b::UInt32
c::Vector{UInt64}
d::Vector{UInt64}
end
sizeof(B[B(0,0,[],[]), B(0,0,[],[])]) # 16
I expected the latter to also have size 48 ie 2xI
>
> Are only transitively immutable types stored inline?
Yes. You can check `isbits(T)`, which in this case returns false because
`B.pointerfree == false`.
> Is this documented
> anywhere?
Unfortunately, the only hint at the moment appears to be
http://docs.julialang.org/en/release-0.4/devdoc
Thanks :)
In this case I'm not worried about compatibility with C but about reducing
pointer hops in a tree. I suppose that allowing pointers to be inlined into
arrays would require storing offsets in the array meta so the GC can find
them. I'll have to figure out something else.
On Tuesday, 5
Of possible interest:
https://github.com/simonster/StructsOfArrays.jl
--Tim
On Tuesday, January 05, 2016 04:41:37 AM Jamie Brandon wrote:
> Thanks :)
>
> In this case I'm not worried about compatibility with C but about reducing
> pointer hops in a tree. I suppose that allowing pointers to be i
That may well help, although I note:
> While you can create a StructOfArrays of non-isbits immutables, this is
probably slower than an ordinary array, since a new object must be heap
allocated every time the StructOfArrays is indexed.
I'll try it out, and even if it doesn't work directly I may