5 ms·

I have tried using LLVM as a JIT for Lua [0] (7 years ago), but found the codegen to be too slow [1] and use too much memory. It might have improved since then

I have tried using LLVM as a JIT for Lua [0] (7 years ago), but found the codegen to be too slow [1] and use too much memory. It might have improved since then, but I really don't think it can compete with LuaJit's highly optimized tracing JIT. Others [2] have also found LLVM to be unsuitable as a JIT. 0. https://github.com/Neopallium/llvm-lua https://github.com/Neopallium/llvm-lua 1. http://stackoverflow.com/questions/4077396/llvm-jit-speed-up-choices/4097930#4097930 http://stackoverflow.com/questions/4077396/llvm-jit-speed-up... 2. http://stackoverflow.com/a/6833494/98107 http://stackoverflow.com/a/6833494/98107

jheriko 9y ago
Is he trying to solve jit though? Maybe he is sick of native full compile times... e.g. He might be working on a jit :I
elementalest 9y ago
I followed reference [2] and the highest voted answer (not the selected one) concludes: > I think the results speak for themselves and demonstrate unequivocally that LLVM is perfectly suitable for JIT compilation.
- neopallium 9y ago
  I don't think that answer was there when I had first come across that question (back in 2010-2011). That answer is about typed languages. The issue is with dealing with dynamic types. There is a lot more code generated for the JIT to compile.
patrec 9y ago
Why not use DynASM, especially since you are using the Lua eco-system already? https://luajit.org/dynasm.html https://luajit.org/dynasm.html
- my123 9y ago
  DynASM isn't that portable... not remotely even near LLVM
- neopallium 9y ago
  LLVM-lua was just an experiment. I wanted to see what kind of performance statically compiled Lua could achieve. I didn't really need the JIT feature. But I did add support for it because Lua code can dynamically generate/load more Lua code. I just found that the runtime overhead (memory and stack space) of LLVM was too high for my needs.
achamayou 9y ago
Have you had a look at the ORC JIT API?
- neopallium 9y ago
  I hadn't heard about that. I have been working on other projects, so haven't had the time to keep up with the developments in LLVM. Thanks for the heads up. The main issues I had with LLVM was the partly do to the memory usage. It can product very good machine code, but the time needed to JIT a block of code was sometimes longer then just running the it in the interpreter. One of the features I like about Lua the most is the low resource overhead. LLVM was just too big for what I was looking for. Usage LLVM to JIT/AOT compile Lua code was really just an experiment, something I wanted to try out. I re-wrote [0] the llvm-lua project with a simple C code-gen backend for compiling Lua code to native code. Which is a bit more useful, since it is easier to cross-compile pure C code, then LLVM bitcode. A lot of the people that tried using llvm-lua wanted to cross-compile Lua code and embed it into an iOS application. 0. https://github.com/Neopallium/slua https://github.com/Neopallium/slua

jheriko 9y ago

Is he trying to solve jit though? Maybe he is sick of native full compile times... e.g. He might be working on a jit :I

elementalest 9y ago

I followed reference [2] and the highest voted answer (not the selected one) concludes: > I think the results speak for themselves and demonstrate unequivocally that LLVM is perfectly suitable for JIT compilation.

neopallium 9y ago
I don't think that answer was there when I had first come across that question (back in 2010-2011). That answer is about typed languages. The issue is with dealing with dynamic types. There is a lot more code generated for the JIT to compile.

patrec 9y ago

Why not use DynASM, especially since you are using the Lua eco-system already? https://luajit.org/dynasm.html https://luajit.org/dynasm.html

my123 9y ago
DynASM isn't that portable... not remotely even near LLVM
neopallium 9y ago
LLVM-lua was just an experiment. I wanted to see what kind of performance statically compiled Lua could achieve. I didn't really need the JIT feature. But I did add support for it because Lua code can dynamically generate/load more Lua code. I just found that the runtime overhead (memory and stack space) of LLVM was too high for my needs.

achamayou 9y ago

Have you had a look at the ORC JIT API?

neopallium 9y ago
I hadn't heard about that. I have been working on other projects, so haven't had the time to keep up with the developments in LLVM. Thanks for the heads up. The main issues I had with LLVM was the partly do to the memory usage. It can product very good machine code, but the time needed to JIT a block of code was sometimes longer then just running the it in the interpreter. One of the features I like about Lua the most is the low resource overhead. LLVM was just too big for what I was looking for. Usage LLVM to JIT/AOT compile Lua code was really just an experiment, something I wanted to try out. I re-wrote [0] the llvm-lua project with a simple C code-gen backend for compiling Lua code to native code. Which is a bit more useful, since it is easier to cross-compile pure C code, then LLVM bitcode. A lot of the people that tried using llvm-lua wanted to cross-compile Lua code and embed it into an iOS application. 0. https://github.com/Neopallium/slua https://github.com/Neopallium/slua