Hacker News Reader

Comment by radarsat1 | Hacker News Reader

I'm not sure I understand the attraction of writing a fast interpreter, as opposed to writing a JIT or ahead-of-time compiler. If you're going to the trouble of optimizing the hell out of your interpreter, yet compiling will always result in faster execution time, why not go directly from an easy, one-off slow implementation to writing a compiler, instead of spending your time optimizing the execution loop?

View on HN

Writing an interpreter can be a lot simpler than coding an equivalent compiler. Suppose you have an old game you want to play that was written in hand crafted 8080 ASM. You can emulate an old CPU at reasonable speeds and get a complete working solution. But, if uses say self modifying code there really is no way to directly map 8080 to x86(64) instructions.

But, a more common case is it let's you debug systems. Even if you can't run an iPhone app in full speed on your desktop you can inspect what's going on in detain with an emulator in a way you can't really do with compiled code.

A fast interpreter is not an easy task, but it is still much easier than a jit or aot compiler that provides similar performance.

Case in point - LuaJIT2's interpreter is faster than LuaJIT1 compiler (LuaJIT2's compiler is significantly better than either) - and the interpreter is much simpler, although neither is in no way simple.

Writing a good compiler for dynamic language is extremely hard - PyPy took 6 years to reach speed parity with the Python interpreter (and has been improving since), Python2C and UnladenSwallow didn't manage to improve on it in any significant way. V8 / JaegerMonkey are super-complex JITs that seem - at this point in time - to be comparable with the performance of LuaJIT2's interpreter.

Both LuaJITs were written by Mike Pall, single handedly as far as I can tell.

If you read Mike Pall (mikemike on reddit, and whatever he puts up on the lua-list and luajit.org), you'll appreciate interpreters more.

Writing a JIT is often very difficult, and requires making many assumptions (particularly regarding self-modifying code, in the case of emulators). Some languages and architectures are inherently difficult or inefficient to JIT.

At the time of writing, some of the other commentors have already provided answers regarding the ease of implementation aspect of interpreters. Another important advantage of implementing an interpreter is that it usually gives you portability for free (or with modest extra works).

The nice point of figuring out optimization of interpreters is that you get the speedup on all architectures, while in a JIT you usually have to change the backend (or worse if you have to create a new backend from scratch.)

edit: I am sorry, another commenter already hinted at the portability aspect.

No need to write a separate back end for each target platform.

Reply on news.ycombinator.com