Hacker News Reader

Comment by snicker7 | Hacker News Reader

It is good to see languages like Crystal and Julia having both a compiler and an interpreter.

I would really like to see a hybrid approach, where an interpreter is used for the outer loop and a compiler for the inner loop. I believe Guile takes this approach by automatically compiling frequently called functions.

View on HN

> where an interpreter is used for the outer loop and a compiler for the inner loop

That's just a standard JIT isn't it?

Also - note there are multiple ways to automatically make a compiler from an interpreter, so really you just need the interpreter.

What's a good starting point for someone to study that? Specifically going from an interpreter to a compiler automatically. Are there any special considerations before implementing the interpreter? I'm vaguely familiar with RPython which I think delivers on that.

For context: I'm just a hobbyist interested in PLs and want to learn more about JITs, I found Crafting Interpreters super helpful for a lot of foundational knowledge.

Yeah RPython and Truffle/Graal are the two major implementations of this idea today.

https://www3.hhu.de/stups/downloads/pdf/BoCuFiRi09_246.pdf

https://chrisseaton.com/truffleruby/pldi17-truffle/pldi17-tr...

ChakraCore, the former JavaScript engine of Microsoft's Edge browser, has in its repo a decent high-level description of how its JIT compilation is integrated: https://github.com/chakra-core/ChakraCore/wiki/Architecture-...

I found the source code to be quite readable too, last time I delved into it. Also its command line tool ("ch"), when compiled in debug mode, has loads of options available to show what it's doing internally when it executes a JavaScript program.

Some jits have a very cheap baseline compiler. This is nice vs the interpreter because you don't need to worry about abi.

Important to note that this is a modality, not the primary way to execute crystal code in production, which remains building a binary executable. This saves compilation time while developing at the expense of performance.

The runtime performance of crystal executables are great, of course, comparable with C or C++ in the given web development domain, of course, where the Boehm GC isn’t a problem, given the request response cycle and the standard lib http and socket objects, etc

> The runtime performance of crystal executables are great, of course, comparable with C or C++ in the given web development domain

I don't think that's true. Crystal seems to be more in the ballpark of Go or Java:https://www.techempower.com/benchmarks/

Isn't that the same ballpark?

It's close but you do pay a performance cost for garbage collection (with Go, Java, and Crystal all being garbage collected). There are some benchmarks at the following link, but note that many of the examples are hyper-optimized so you should look at the implementations to make sure the results aren't misleading. As an example though if you don't want to click, the nbody benchmark clocks the slowest C++ program at 387ms compared to Crystal at 580ms

https://programming-language-benchmarks.vercel.app/crystal-v...

That's an incredible achievement for Crystal given how high-level that language is. But you're right technically of course.

You mean a JIT? Or are you talking about something else, like some sort of hybrid interpreter/AOT compilation?

old lisp implementations allowed you to freely intermix compiled and interpreted code. it wasn't compiled on demand, each function could independently be compiled AOT. and dynamically replaced with an interpreted or compiled version

Why the past tense? That capability is very much still present in modern implementations.

sorry - its me thats past tense. didn't want to presume that things are still done that way. fwiw i don't why more environments don't have the same flexibility.

Reply on news.ycombinator.com