2 ms·
> Implementations which are written in another language and use an interpreter also have a very large difference in performance between code written in the lang
by samatman 4y ago
> Implementations which are written in another language and use an interpreter also have a very large difference in performance between code written in the language used for the implementation, and the language being implemented.
There's no need to write things like this in the current decade. LuaJIT has been able to provide comparable performance to the implementation language, in important cases, since 2.0.
It achieves this with a very different philosophy to what's being proposed here, one which in fact requires considerable assembler for each instruction set.
It's certainly not the only way to get the job done, other comments have pointed to the various ways Scheme has tackled this problem.
What isn't the case is that implementing a runtime for an interpreted language in a 'systems language' requires that code written in the interpreted language be slower than comparable code in the systems language, let alone that a "very large difference in performance" is inherent to the approach.
- hayley-patton 4y agoIf 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.
- samatman 4y agoLuaJIT 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.
- hayley-patton 4y agoThere 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_development_areas_2022_edition/htwk2ew/ https://old.reddit.com/r/Compilers/comments/sae1iy/compiler_...
- rrss 4y agobut 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.