Hello! With help from Claude Opus 5 and GPT 5.6 Sol, you can now write LuaJIT code that gets compiled to efficient and fast SIMD instructions (just for x86-64 for now, but aarch64 eventually too)!
> Why SIMD?
There's a lot in LuaJIT (mainly with games, but also parsers, ML, etc) that is quite limited with how LuaJIT cannot compile to SSE/AVX instructions and use their extended registers, but now it can!
> Why FFI vector types instead of Lua tables?
Keeps implementation much simpler and much faster, + it makes you be more careful how you are structuring and writing your code.
> Compatability?
This fork adds new bytecode and a new ffi.simd module, but is fully backwards compatible.
> Current limitations
Biggest issue is that it is x86-64 only, but I am going to be adding aarch64 support soon. Also, no AVX512 backend (I do not have an AVX512 CPU), 8 and 64 byte vectors are interpreter only, no JIT. Only 8 and 16 byte vectors can be used in external FFI calls (same as regular LuaJIT rules), use pointers for 32 byte ones.
frityet•58m ago
> Why SIMD?
There's a lot in LuaJIT (mainly with games, but also parsers, ML, etc) that is quite limited with how LuaJIT cannot compile to SSE/AVX instructions and use their extended registers, but now it can!
> Why FFI vector types instead of Lua tables?
Keeps implementation much simpler and much faster, + it makes you be more careful how you are structuring and writing your code.
> Compatability?
This fork adds new bytecode and a new ffi.simd module, but is fully backwards compatible.
> Current limitations
Biggest issue is that it is x86-64 only, but I am going to be adding aarch64 support soon. Also, no AVX512 backend (I do not have an AVX512 CPU), 8 and 64 byte vectors are interpreter only, no JIT. Only 8 and 16 byte vectors can be used in external FFI calls (same as regular LuaJIT rules), use pointers for 32 byte ones.