3 ms·
Benchmarks beg to differ: https://blog.racket-lang.org/2021/01/racket-status.html https://blog.racket-lang.org/2021/01/racket-status.html. But those may be (bei
by forgotpwd16 6y ago
Benchmarks beg to differ: https://blog.racket-lang.org/2021/01/racket-status.html https://blog.racket-lang.org/2021/01/racket-status.html. But those may be (being the official ones) biased, so a third-party running them will be nice. Also performance wasn't the only reason. Maintainability and easier development were as well, which for language like Racket, I believe, are more important.
- gus_massa 6y agoI agree. IIRC the benchmarks is the union of few benchmarks sets that were floating around, like some usual benchmarks for Scheme implementations [1] and old versions of the The Computer Language Benchmarks Game [2] In particular you can see the comparison of "Racket" (aka Racket CS) and "Racket BC" with the current version of the The Computer Language Benchmarks Game in https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/racket-racketbc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (The set of problems and measurements of runtime are made by someone that is not in the Racket team.) [1] That are somewhat bad for Racket because some of them use mutable pairs/cons. [2] They are frozen to test backward compatibility and to ensure any progress is due to improvements in the compiler.
- samth 6y agogus_massa knows this, but building Racket from source (which is basically just running a lot of Racket code) is now faster with Racket CS than with Racket BC.