4 ms·

Nash – A tracing JIT compiler for Scheme [pdf]

94 points by jsnell 10y ago

Johnny_Brahms 10y ago
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.
- sabauma 10y ago
  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.
  - throwaway7645 10y ago
    Is Chez AOT compiled or JIT based? If it is AOT, would the REPL still be interpreted and just a finished program AOT compiled?
    - sabauma 10y ago
      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.
      - fiddlerwoaroof 10y ago
        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.
      - throwaway7645 10y ago
        Ah. So if Racket uses the Chez Compiler it could use it for the REPL as well.
      - sedachv 10y ago
        > 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.
- orangeshark 10y ago
  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/msg00009.html https://lists.gnu.org/archive/html/guile-user/2017-03/msg000...
CoffeeDregs 10y ago
Would transpiling Scheme to Javascript and then executing the resulting Javascript on NodeJS give good performance?
- tonyg 10y ago
  In principle, maybe; in practice, currently, no: Scheme requires proper tail calls, and Javascript engines as a rule do not provide them. Yet.
  - e12e 10y ago
    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?
    - ufo 10y ago
      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.
  - microcolonel 10y ago
    http://kangax.github.io/compat-table/es6/ 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.
- ufo 10y ago
  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.

94 points by jsnell 10y ago

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.

sabauma 10y ago
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.
- throwaway7645 10y ago
  Is Chez AOT compiled or JIT based? If it is AOT, would the REPL still be interpreted and just a finished program AOT compiled?
  - sabauma 10y ago
    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.
    - fiddlerwoaroof 10y ago
      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.
    - throwaway7645 10y ago
      Ah. So if Racket uses the Chez Compiler it could use it for the REPL as well.
    - sedachv 10y ago
      > 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.
orangeshark 10y ago
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/msg00009.html https://lists.gnu.org/archive/html/guile-user/2017-03/msg000...

CoffeeDregs 10y ago

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

tonyg 10y ago
In principle, maybe; in practice, currently, no: Scheme requires proper tail calls, and Javascript engines as a rule do not provide them. Yet.
- e12e 10y ago
  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?
  - ufo 10y ago
    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.
- microcolonel 10y ago
  http://kangax.github.io/compat-table/es6/ 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.
ufo 10y ago
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.