The way lua values are made in C is best for dynamic typing. No matter if it's a number or a table, they allocate the same size in memory with type info.
Making it space efficient still needs metadata for the content and type checking. And maybe it won't be even performing because of that. LuaJIT has similar thing: ffi C definitions. But it's advantage is JIT compilation which makes the access to the structure in the most efficient way.
On 5 Nov 2021, 11:32 +0300, 云风 Cloud Wu <cloudwu@gmail.com>, wrote:
Roberto Ierusalimschy <roberto@inf.puc-rio.br> 于2021年10月12日周二 上午12:40写道：
Hugo Gualandi came with the idea of using a packed structure to store
Lua values. Intel CPUs (and it seems ARMs too) can work with unaligned
data (or aligned with weaker boundaries) and, at least for some
architectures, with very small (or even none) performance penalties.
As a very fast check, I simply changed the following line in lobject.h:
-typedef struct TValue {
+typedef struct __attribute__((packed)) TValue {
TValuefields;
} TValue;
This is valid in gcc and clang. (It gives one warning in ltable.c which
for now I am ignoring. It is a trivial change to correct that: pass the
second parameter of 'mainposition' by value instead of by reference.)
I quickly tested that in two Intel i7. As expected, memory use
by arrays is cut by almost half (9/16). Maybe unexpected, I did
not see any relevant performance penalties at all. (In a few
benchmarks, performance even improved, probably because there
is less memory trafic.)
I think the point is the types of values in the array.
In many use cases, the types are determined. For example, we always
use 4 numbers of a table for a vector4 type in 3d game.
I suggest lua to add a built-in tuple type, it will be a special kind
of table. For vector4, we can write:
-- n : number
-- i : integer
-- b : boolean
-- s : string
local v = table.tuple "nnnn" -- initial: { 0,0,0,0 }
v[1] = 0
v[2] = 0
v[3] = 0
v[4] = 1
The string "nnnn" is the type annotations for the tuple, and it can
store in the internal object.
We can implement a library for this, but a built-in support would have
better performance. (compact memory layout and efficient
implementation.)
--
http://blog.codingnow.com
