I'm no expert, but I have a feeling that optimizing for Racket CS will involve relying more on function calls and indirection, especially to avoid generating (or just writing) large amounts of code. So I suspect we'll see more of the following:
1. Implementing macro-generating macros by having the root macro expand to calls to a helper function to create the generated macro. For example, `(define-syntax generated-macro (make-my-generated-macro ...))` instead of `(define-syntax-rule (generated-macro ...) ...)`. This is already a good idea in Racket BC, because it vastly cuts down on expanded code size. Racket CS will probably make the effect more pronounced because the function call will be faster and the price of generating unnecessary code will rise. 2. More reliance on generic interfaces. The dynamic dispatch of generic interfaces is much cheaper on Racket CS, so passing around sequences instead of lists suddenly doesn't seem like such a bad idea anymore. Maybe we'll even start using generic collections. 3. Less avoidance of generators and similar features that use continuations under the hood, since continuations won't tank performance as much anymore. Further down the line, we might also see more opportunities to leverage parallelism. Making the Racket BC VM allow parallel execution (so Racket code could use multiple thread without firing up a separate place - and thus an entire separate VM - for each thread) would be an infeasible amount of work, but on ChezScheme the possibilities look brighter. For mere mortal users of Racket, I think a good way to contribute to this effort would be to explore the performance costs of generic interfaces on Racket CS. Make some benchmarks, try using collections other than just lists and hashes, and see what happens in real-world codebases. Don't just look at the speed differences either: consider what impact the flexibility of generic interfaces has on the structure of the codebase. On Saturday, February 22, 2020 at 8:05:35 AM UTC-8, Matthew Butterick wrote: > > 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/5f0815ee-1e02-4dc8-9b2f-d1465263f205%40googlegroups.com.
