Chez Scheme vs. SBCL: a comparison (2019)
22 points by gnyeki
22 points by gnyeki
As well as Racket, Chez Scheme provides the back end for Idris 2.
Protips: Chez itself is faster (e.g. going through levels of indirection), but SBCL’s library is more optimized. If you’re able to use SBCL built ins for things vs. rolling your own, it’ll out perform. But also (declaim (optimize (speed 3) (debug 0) (safety 0)) makes SBCL way faster and binaries a fair bit smaller. And it’s not hard to use disassemble then use its resulting assembly in line for another speed up. In my tests (inference on dozens of GB of data) some years ago, SBCL was 3x faster than base Racket on Chez but honestly I found CL easier and didn’t dig too far into optimizing either.
With the opening comparison, was trying to paraphrase this comment and just found it:
I have found chez to produce slightly faster “general purpose” code, but that the standard library in sbcl has had a lot more optimization work done. Just compare the isqrt functions to see what I mean. The chez standard library relies a lot more on general optimisations than on trying to make individual functions fast, which meanstight loops relying only on standard library stuff is faster in sbcl, but larger programs tend to be about the same or slightly faster in chez. I suspect the whole block optimization business in sbcl will close that gap.
in my own, very unscientific benchmarks that is. I ported three personal programs (static site generator, a little program I have to do statistics about my personal finances, and a small home server doing basic network logging) and found the whole experience delightful. chez really is amazing.
I also ported a select number of solutions to project Euler problems, and found that in the cases where SBCL was faster, it was usually due to individual stdlib functions being faster. - Bjoli
the sbcl compiler is a hot pile of crap, and chez is probably much closer to being pareto optimal (performance vs complexity), but last time i looked at chez compiler output (admittedly i didn’t look too closely so it’s possible i missed something) it was extremely and unfixably stupid in ways sbcl just wasn’t. whereas you do not generally need to turn off safety or write unportable code to get ‘decent’ performance out of sbcl (you might need light tuning, and it seems plausible that some code that’s written in the most straightforward way performs better in chez than sbcl—though even in such a case i’d place even odds that it’s due to cl’s semantics being harder than scheme’s rather than chez being smarter or cleverer—but if turning safety off increases performance a lot, it’s usually possible to get most it back without talomg drastic measures)
One thing I recently learned about Chez Scheme: it also has an interpreter-only “Petite Chez Scheme” that is ~350 KB.
This somewhat echoes the main factor that made me settle on CL over Clojure: interactivity. Yes Clojure is interactive and you can hotswap too, etc., but CL takes it a hair further. It’s like the difference between a 90% and a 95% on a test. I’ll happy take that 90% though if it’s all I have available! (and Clojure tooling is better)
How does it take it further?
Just a guess but probably due to the condition system; when you encounter an error, you immediately get it in your repl and it doesn’t unwind the stack.
You can do this in Clojure, but it’s opt-in, so every error thrown by the libraries you use will not take advantage of it.
Yeah, support for conditions throughout the entire language and restarting execution at a past stack frame of my choice are pretty invaluable to me by this point.