4 ms·
> So while, say, Python is "batteries included", LuaJIT is "all the batteries". Do you say this because LuaJIT can call shared libraries dynamically? If so, wh
by Sean1708 8y ago
> So while, say, Python is "batteries included", LuaJIT is "all the batteries".
Do you say this because LuaJIT can call shared libraries dynamically? If so, what about ctypes[0]? Is LuaJIT's FFI just easier to use, or does it do something that ctypes can't?
[0]: https://docs.python.org/3/library/ctypes.html https://docs.python.org/3/library/ctypes.html
- ufo 8y agoThe two most appealing features of the LuaJIT FFI: 1) The syntax. To specify the types of the FFI functions you you use a DSL that is similar to C declarations. Often you can copy paste function prototypes from ".h" files with very minimal modifications. With ctypes you need to specify the types with Python function calls. See "ffi.cdef": https://luajit.org/ext_ffi.html https://luajit.org/ext_ffi.html 2) Performance. If your code is inside a JIT-compiled trace, LuaJIT FFI calls have minimal overhead. They compile down to something very similar to what a C compiler would generate. Ctypes, on the other hand, must "interpret" the FFI calls which adds more runtime overhead (although admittedly this is also true for LuaJIT if your code ends up outside a compiled trace).