Re: Lua memory usage

[David Jones <drj@...>]

In message <BB7E8938.25F53%mhamburg@adobe.com>, Mark Hamburg writes:
> On the other hand, perusing the code does lead me to ask whether there is a
> space efficiency issue with Lua. It looks to me like one is faced with the
> following sizes:
> 
> TObject: 16 bytes. A type value followed by a double which because of 8 byte
> alignment forces the effective size up to 16 bytes.
> 
> Node: 40 bytes. 2 TObjects and then a pointer. Padding out to an 8-byte
> boundary takes us to 40 bytes.
> 
> How much data is there really in a Node? Assuming 32-bit pointers, there is
> essentially 1 + 8 + 1 + 8 + 4 = 22 bytes of information. 24 bytes on a
> 64-bit architecture. That's a wasting of 40-45% of the space.
> 
> Has this arisen as an issue in practice or am I just seeing a theoretical
> potential issue? Cutting memory consumption is a performance win from the
> standpoint of data caches and potentially from the standpoint of garbage
> collection frequency.

Architectures that pad out to 8 bytes are a pain for Lua for just this
reason.  When I was using one I used the compiler switch (a #pragma
actually) to force 4 byte alignment.  Happily the architecture supported
that with only a 1-cycle penalty for 8-byte loads that straddled an
8-byte alignment boundary.  It only used 8-byte loads for access to
64-bit doubles anyway.

There was no noticeable change in speed (we might expect it to be
faster, as you point out, for cacheing, but slower if misaligned
accesses are penalised) and as for size about a 300KB saving on a
2MB heap, which seems like rather a lot now.

I don't think it's worth changing Lua, all the most popular
architectures align to 4 bytes with no or almost no penalty and that
will be the case for a long time.  Architectures that routinely align to
8 bytes can usually to be convinced to use 4 byte alignment with little
or no penalty.

BTW some architectures will use 4 bytes for alignment except for doubles
and structs containing doubles which will be 8 byte aligned.  Switching
to "float" rather than "double" can improve the situation on such
architectures.

David Jones