lua-users home
lua-l archive

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

Maybe related?

I've been using LLVM to write and JIT compile performance critical code within a Lua script. Basically, along the lines of llvm-py [1], i.e. binding the most useful parts of the LLVM C++ API to Lua, and generating machine code by manipulating LLVM IR. The binding is a bit messy at the moment, but I'm hoping to clean it up and make it public sometime soon. It can also compile inlined C, using LLVM's Clang driver. Interfacing with Lua is basically by means of the Lua C API, in both cases.

It's definitely fast, but the API is cumbersome... I'm toying with LPEG to write a kind of slimmed down C that talks more seamlessly with Lua, as a more usable alternative for JIT compiled inline code. Definitely some potential, but also some trickiness.


On Jul 3, 2009, at 9:04 PM, steve donovan wrote:

Of course, luatcc does this already, but does not free you from having
to write the binding code, such as would be generated by tolua++.

Inling performance-critical code can be an effective trick:

Now the question is, is it worth pursuing this for Lua?  tolua++ works
rather nicely, but you have to maintain a separate .c/.cpp file and
hand-roll the .pkg file (the cleaned header).  So, for
proof-of-concept, I'd build on tolua++.  After the first compile, a
quick dependency check means that the inlined code need not be
recompiled.  One has to make sure that the .so/.dll is loadable from
the same location as the original Lua file, etc.

I've been generally thinking about Lua and High-Performance Computing.
A library like this, plus MPI bindings, and one has a means to write
very effective parallelized programs in a nicer language than FORTRAN.
Actually, modern FORTRAN is a good companion to Lua in this context,
since it's cleaner and faster than C, especially for things like bulk
array operations and complex arithmetic.

Any thoughts?

steve d.