4 ms·

Lua is small and embeddable. You can run multiple independent instance of it in the same process. The lua table is a very useful data structure. Then you have

by malkia 15y ago

Lua is small and embeddable. You can run multiple independent instance of it in the same process. The lua table is a very useful data structure. Then you have luajit - also a small, easy to embed solution, that approaches standard "C" written code, and it's main weakness, from what I understood (Mike Pall had a post about it) is it's garbage collector. On top of that, ffi bindings make "C" calls extremely fast, when the jit is active, and not very bad when the interpretter runs (but slower). And the lua/luajit license allows you to embed it in your application, without the need to share source code. Mike Pall is working on ppc, arm versions (and I think there might be already ppc jit). Not last to forget - awesome community (comp.lang.lua).

strait 15y ago
Using LuaJIT with minimal FFI C code to optimize, seems to be the best way forward in maximizing both performance and maintainability. What would be really interesting is to see someone highlight specific cases where this approach ultimately fails to measure up in performance with using pure C. I would think that the LuaJIT approach would be tens of times more maintainable for a sufficiently large application, so it's really imperative here that we ask 'Why not?'
- malkia 15y ago
  You can always find cases where it would fail. And that's ok. For what it's doing, and what it allows it's simply unbelievable (at least to me) how it succeeds in doing it (I understand very little of compilers, and little of interpretters). One area which is not easy translatable is OpenMP (www.openmp.org), inlined assembly, and SSE packed floats. But that's okay, and even then there is probably a better alternative - a language more suited to such tasks, instead of "C" - OpenCL (www.khronos.org) or DirectCompute. But for general coding, it's very very good.

by malkia 15y ago

strait 15y ago

Using LuaJIT with minimal FFI C code to optimize, seems to be the best way forward in maximizing both performance and maintainability. What would be really interesting is to see someone highlight specific cases where this approach ultimately fails to measure up in performance with using pure C. I would think that the LuaJIT approach would be tens of times more maintainable for a sufficiently large application, so it's really imperative here that we ask 'Why not?'

malkia 15y ago
You can always find cases where it would fail. And that's ok. For what it's doing, and what it allows it's simply unbelievable (at least to me) how it succeeds in doing it (I understand very little of compilers, and little of interpretters). One area which is not easy translatable is OpenMP (www.openmp.org), inlined assembly, and SSE packed floats. But that's okay, and even then there is probably a better alternative - a language more suited to such tasks, instead of "C" - OpenCL (www.khronos.org) or DirectCompute. But for general coding, it's very very good.