lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Em sex., 5 de nov. de 2021 às 05:32, 云风 Cloud Wu <> escreveu:
Roberto Ierusalimschy <> 于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
What if we create a new TValue that only uses 7 bytes for the value and 1 byte for the type?

typedef struct TValue {
 lu_byte value_[7]; /* 7 bytes */
 lu_byte tt_; /* 1 byte */
} TValue;

Total Size: 8 bytes
It would have to be considered the big-endian and little-endian,
to store and read.

Ranier Vilela