I announced the development of Ravi back in January 2015. It started as an experiment - I was not certain whether Ravi could achieve the performance levels of LuaJIT, the reigning monarch for Lua JIT compilation.
I am pleased to report that Ravi is able to match LuaJIT's performance for a few selected benchmarks. More details are available here. While this is positive news, there is still much to do to make Ravi competitive in a variety of situations.
LuaJIT offers a powerful FFI interface for interfacing with external libraries and like. This is very convenient for sure, but the approach taken is not compatible with Lua. After some thought I decided that rather than creating an FFI interface for Ravi, a more general capability would be to allow both Lua and Ravi users to write JIT code using LLVM. Work on this has just started so there is not much to show yet, but I hope to make progress fairly quickly.
LLVM is a very low level api - lower level than C. This has its pluses and minuses. On the plus side the LLVM binding will allow Lua and Ravi users to exploit the full power of LLVM. On the minus side even writing trivial functions can be quite some effort.
I am pleased to report that Ravi is able to match LuaJIT's performance for a few selected benchmarks. More details are available here. While this is positive news, there is still much to do to make Ravi competitive in a variety of situations.
LuaJIT offers a powerful FFI interface for interfacing with external libraries and like. This is very convenient for sure, but the approach taken is not compatible with Lua. After some thought I decided that rather than creating an FFI interface for Ravi, a more general capability would be to allow both Lua and Ravi users to write JIT code using LLVM. Work on this has just started so there is not much to show yet, but I hope to make progress fairly quickly.
LLVM is a very low level api - lower level than C. This has its pluses and minuses. On the plus side the LLVM binding will allow Lua and Ravi users to exploit the full power of LLVM. On the minus side even writing trivial functions can be quite some effort.
4 comments:
Is Ravi bytecode universal (like LuaJIT) or non-universal (like Lua)?
Hi Anthony,
Not sure what you mean by 'universal' and 'non-universal' - please would you explain?
Thanks
I mean that normal lua makes different bytecode dependant on the bit size and eindien of the cpu that it was created on
LuaJit makes the same bytecode independent of the cpu.
Hi Anthony
Thanks for explaining. I haven't changed the way Lua bytecode is serialized - I guess that is when the representation matters. How the bytecode is held internally doesn't matter I think. I suppose you are referring to the fact that if the Lua bytecode is dumped - it can only be read back in the same architecture.
I will look at this problem but it is not something that affects me right now. Let me know if there particular use cases where this is important.
Regards
Post a Comment