Of the convergence of Racket BC and CS performance, Matthew Flatt wrote: [1]
> development to date has been aimed at making Racket CS match the performance > of Racket BC on a code base that was developed and tuned for Racket BC, and > that obviously gives Racket BC an advantage. For example, Racket BC makes > dormant code relatively cheap, so Racket libraries generate a lot of code. > Future Racket libraries will likely shift to take advantage of Racket CS’s > cheaper function calls and dramatically cheaper continuations. 1) As a package maintainer with zero exposure to Chez Scheme, how do I start to optimize for Racket CS? Are there certain patterns and idioms from BC that should be systematically eradicated? For instance, how would I "take advantage of ... cheaper function calls"? 2) With Racket BC, I've generally found that the JIT optimizes my code better than I do. So I write the simplest code and ignore the details. Is that less true with CS? Should I be thinking more about manual tuning? 3) Lurking here, I gather, is the bugaboo that even though core Racket runs on CS, the existing base libraries are optimized for BC. Is it considered important to optimize these for CS, in order to get the most benefit from the switch? How can Racket developers contribute to this? 4) Building both BC and CS is easy (thank you). What would be the most reliable technique for doing performance comparisons as one refactors code? Is it as simple as running `raco test ···` and `racocs test ···` in succession? [1] https://blog.racket-lang.org/2020/02/racket-on-chez-status.html -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/12D39EEF-E58B-476F-8159-78F97E340FE1%40mbtype.com.
