Nash – A tracing JIT compiler for Scheme [pdf] | Hacker News Reader

Nash – A tracing JIT compiler for Scheme [pdf]

scheme2016.snow-fort.org

94 pointsjsnell16 comments

What's most impressive about Nash is that it is a one man show. I don't thing any of the guile devs knew about Nash when Atshro stood up and introduced it at scheme workshop 2016.

There was talk about merging it, but I dont know what happened with that. We moved to chez at work, so we sort of lost interest.

Chez is pretty tough to compete with in terms of Scheme performance. On the benchmarks presented in the paper, Chez averages faster than all the systems presented, even Pycket post warmup. Its not the fastest on every benchmark, but gives consistently good performance without huge warmup time, which is Pycket's biggest weakness. With Racket planning to switch over to Chez, it may be difficult to justify Pycket's existence, especially if some of Chez's known performance sore spots receive attention.

Is Chez AOT compiled or JIT based? If it is AOT, would the REPL still be interpreted and just a finished program AOT compiled?

Chez is an AOT compiler. I am not sure how the REPL operates, but I believe it just compiles expression on the fly before executing them. I suppose you could characterize that as JIT compilation, but the optimizer does not make use of any runtime profiling information. Racket's "JIT" is similar in that code is generated for a function when it is first called, but the optimizer is run on the bytecodes of the program before anything is run.

In Common Lisp it's fairly common for eval to compile the code and then execute it. For example, sbcl's repl usually compiles the entered expression and then executes it: although recent versions also provide an interpreted mode.

> I suppose you could characterize that as JIT compilation, but the optimizer does not make use of any runtime profiling information.

That is JIT compilation. AFAIK James Gosling started using the phrase in the 1990s to pretend that it was something novel and to ignore the fact that that is how Lisp and Smalltalk systems have always worked. This is really confusing today because a lot of people started using "JIT" to be synonymous with dynamic recompilation techniques like tracing.

Ah. So if Racket uses the Chez Compiler it could use it for the REPL as well.

There is still discussions on the Guile mailing list[0] about it. Someone is maintaining a repo of guile with Nash and keeping it up to date with guile master.

[0] https://lists.gnu.org/archive/html/guile-user/2017-03/msg000...

Would transpiling Scheme to Javascript and then executing the resulting Javascript on NodeJS give good performance?

No.

NodeJS (V8) is slower than Racket in many benchmarks:

https://benchmarksgame.alioth.debian.org/u64q/measurements.p...

Note that Racket is not even in the top 5 for most Scheme compiler benchmarks:

https://ecraven.github.io/r7rs-benchmarks/benchmark.html

There are a bunch of Scheme implementations in JS, none of them are benchmarked in the previous link: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

JavaScript is a really shitty language to target because it has very few performant control structures and terrible data types (you need ints and good arrays). Scheme also has first-class continuations, which cannot be implemented efficiently in JavaScript. Even if you leave out continuations IMO it is impossible to make a performant transpiler for most languages that targets JavaScript.

Let me help you with a benchmarks game URL --

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

I wouldn't be very optimistic. How do you plan on transpiling Scheme to Javascript?

The easiest way to transpile would be to write a Javascript interpreter for Scheme, but that would completely confuse the Javascript JIT compiler, since all it would see is one big hot loop with very branchy code inside it. That said, Pycket (which is mentioned in the paper) takes exactly this approach. They take advantage of PyPy's meta-JIT framework, which was designed exactly for this sort of thing.

The other way would be to try to transpile Scheme directly into Javascript. But now you face the problem that there is a big mismatch between the two languages. The datatypes aren't the same, Javascript doesn't have guaranteed tail recursion, and so on. Just writing the transpiler will be a lot of work and even if you succeed, the end result is not going to look like idiomatic Javascript, so there is a good chance that the Javascript JIT won't do a good job at optimizing it.

In principle, maybe; in practice, currently, no: Scheme requires proper tail calls, and Javascript engines as a rule do not provide them. Yet.

http://kangax.github.io/compat-table/es6/ < The most popular version of the most popular javascript engine supports tail call optimization.

That said, it would still probably be worth doing the optimization in the transpiler, to avoid having the JS compiler have to work out if your program runs into any JS pitfalls.

Wouldn't any scheme runtime/compiler need to handle that, though? In other words, wouldn't a transform to a loop (on the js side) be one possible approach?

Only if you know at compilation time what function(s) you will be calling in a tail recursive manner. If the function you call comes from a parameter or variable (for example, in continuation passing style code) then there is no straightforward way to compile it into a loop.

Reply on news.ycombinator.com