Hacker News Reader

Comment by hayley-patton | Hacker News Reader

If LuaJIT is the example, is Lua being interpreted? I know that there is a bytecode interpreter hand-coded in assembly, but isn't the JIT used for hot code?

Edit: perhaps this is about missing the word "primarily", that performance in such an implementation is bound by interpretation speed.

View on HN

LuaJIT is written in another language, C with assembler intrinsics, and uses an interpreter.

These are the two requirements of the sentence I quoted.

There's no need for the Zero Feet proposal to say something untrue to justify their approach. I'm not imputing malice because I see none, but moderating that sentence or just removing it would strengthen their case.

There is also the requirement in this counter argument that the interpreter design substantially affects runtime performance. Generally, when there is a JIT compiler and an interpreter, my understanding is that one attempts to spend most cycles running in compiled code. Does LuaJIT not do that?

HotSpot also uses an interpreter, but its performance comes from the C2 compiler, for example. Quoth Cliff Click [1]:

> if you are spending any amount of time beyond e.g. 5% in the interpreter / stage-0 JIT you need to adjust your JIT'ing strategy. Not saying "no-gain" in a stage-0-only, but definitely should not be a super high payoff if there's a stage-1 following you.

[1] https://old.reddit.com/r/Compilers/comments/sae1iy/compiler_...

but when actually using the interpreter (and not running jit compiled code), is it as fast?

I don’t think the fact that jit compilers exist makes this sentence about interpreters untrue.

Reply on news.ycombinator.com