Hacker News Reader

Comment by unnouinceput | Hacker News Reader

Word "Interpreter" and "fast" don't belong together in my brain :).

Probably why I love native binaries.

I had the good fortune to have Ole Caprani as my 2nd year teacher at the university and he really drilled home the message that it's all the same the whole way down. The more you understand the whole stack, the more you realize that even the CPU is just an interpreter for it's own language (the ISA).

A sufficiently smart interpreter for a language can be faster than a native binary as the former has the freedom to adapt to dynamic conditions. This is the essential point of JITs. It beats ahead of time compilation when dynamic conditions do change but slowly enough to amortize the overhead of adapting to it.

Please show me just one example of such an interpreter. You chose the architecture and the operating system. I'll follow up with a C compiled native and see who's faster at doing the same thing.

Synthesis kernel by massalin comes to mind. not sure if there is a modern equivalent. pretty sure lisp systems like SBCL can do things like function specialization and loop unrolling at runtime but I haven't tried.

Try it and put GitHub link. For bench-marking purposes do a simple project of calculating first million prime numbers. I'll do the same in C using your chosen algorithm.

That's not a particularly good representative of real applications, but I'll be happy to do the study for you. Let me introduce you to my consulting fees.

There's nothing inherent that would make JIT interpreted languages slower than AOT compiled languages. In fact JITs can apply optimizations that are difficult to do AOT.

The only reason why interpreted languages are usually much slower is semantics of the language itself. And maybe JITing itself, but that tends to get amortized rather quickly.

I would argue that a runtime that makes heavy use of JIT compilation ceases to really be an "interpreter".

Reply on news.ycombinator.com