Hacker News new | past | comments | ask | show | jobs | submit login

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

1. http://stackoverflow.com/questions/4077396/llvm-jit-speed-up...

2. http://stackoverflow.com/a/6833494/98107

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.

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.

Why not use DynASM, especially since you are using the Lua eco-system already?


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.

DynASM isn't that portable... not remotely even near LLVM

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

Have you had a look at the ORC JIT API?

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact