Racket is a great language. I got introduced to it through
reading "How to Design Programs" (https://www.htdp.org/), which
is a really beautiful introduction to programming that focuses on
big-picture program design, rather than just writing code, but in
a way that is accessible even to people who are new to
programmers.
I recently got a chance to use it for a medium-sized personal
project, and it is one of the most enjoyable programming
languages that I have ever used. Unfortunately, its performance,
and especially the start-up time, is not that great. (At least
this was true last time I checked.)
As someone who hasn't been following Racket news, I'm not sure if the new Chez
Scheme backend is expected to improve performance. I found this blog post
(https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...), which seems
to indicate that it is not, but that may be quite outdated. What is the goal of
porting Racket to CS?
The idea is that someday the CS version will be faster than the traditional version. Now the CS is faster in some benchmarks, and slightly slower (205? 50%?) in others. IIRC the worst cases are in code that uses too many mutable pairs, and the futures block more often.
IIRC Many of the changes of the last year were to improve the transformation from Racket to Chez Scheme. For example, some structs can be used as function in Racket, so in (f 1 2 3) the transformation must add a check to see if f is a real function or a struct that contains a function. If the transformation know which variables contain real functions and which struct, then the checks can be avoided, and hopefully the function can used in the constant folding and other transformation.
(Some of the checks can be eliminated by the optimizations in Chez Scheme, but some are just too difficult, so it's important to improve the transformation. For example, I think that the unnecessary continuation marks are very difficult to remove using only the information available in Chez Scheme, and the continuation marks are used heavily when the debug mode is enabled.)
I am curious: by slow startup time do you mean starting the IDE or running a pre-compiled and linked application? I find the first slow to start and the second to be quick enough.
EDIT: I have found disk IO to be perhaps slow, or at least in an example I wrote that loads one of my trained Keras/TensorFlow models (saved as a CSV file) into memory and uses the native matrix library to use the model for predictions. The whole thing takes about two seconds to load which seems like a long time.
5 comments
[ 5.4 ms ] story [ 20.8 ms ] threadI recently got a chance to use it for a medium-sized personal project, and it is one of the most enjoyable programming languages that I have ever used. Unfortunately, its performance, and especially the start-up time, is not that great. (At least this was true last time I checked.)
As someone who hasn't been following Racket news, I'm not sure if the new Chez Scheme backend is expected to improve performance. I found this blog post (https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...), which seems to indicate that it is not, but that may be quite outdated. What is the goal of porting Racket to CS?
The idea is that someday the CS version will be faster than the traditional version. Now the CS is faster in some benchmarks, and slightly slower (205? 50%?) in others. IIRC the worst cases are in code that uses too many mutable pairs, and the futures block more often.
IIRC Many of the changes of the last year were to improve the transformation from Racket to Chez Scheme. For example, some structs can be used as function in Racket, so in (f 1 2 3) the transformation must add a check to see if f is a real function or a struct that contains a function. If the transformation know which variables contain real functions and which struct, then the checks can be avoided, and hopefully the function can used in the constant folding and other transformation.
(Some of the checks can be eliminated by the optimizations in Chez Scheme, but some are just too difficult, so it's important to improve the transformation. For example, I think that the unnecessary continuation marks are very difficult to remove using only the information available in Chez Scheme, and the continuation marks are used heavily when the debug mode is enabled.)
EDIT: I have found disk IO to be perhaps slow, or at least in an example I wrote that loads one of my trained Keras/TensorFlow models (saved as a CSV file) into memory and uses the native matrix library to use the model for predictions. The whole thing takes about two seconds to load which seems like a long time.
p30 of https://www.mpoffald.com/papers/depmacros.pdf has a table comparing the macro systems of various langs
Seems only Racket has enough juice to do this, for now :)
(though I do wonder if some of those missing features couldn't be provided by libraries in other languages)