[Replying to three messages] At Sat, 22 Feb 2020 08:05:28 -0800, Matthew Butterick wrote: > 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?
No. For most Racket users, you should *not* try to optimize for Racket CS, and Racket CS should just do the right thing. > For instance, how would I "take advantage of ... cheaper function > calls"? Jack's answer applies here. That is, you could take advantage of cheaper function calls by worrying about them even less. > 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? You should treat Racket BC and CS the same in this way. > 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? I'd say existing libraries are optimized for BC in the sense that they avoid some things that turn out to be cheaper in CS, so they might not have avoided those things if started on CS. Meanwhile, for things that turned out to be cheaper in BC, my strategy has been to make them cheaper in CS, too. > 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? Yes. At Sat, 22 Feb 2020 14:13:55 -0800 (PST), Jack Firth wrote: > 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. I'm reluctant to call that "optimizing for Racket CS", though. It's closer to "not optimizing manually". > 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. Agreed. At Sun, 23 Feb 2020 12:27:42 +0530, Alexis King wrote: > I’m curious what guarantees I can come to expect from the Racket CS > optimizer. I think you have in mind what I would call high-level optimizations, and there's not much difference between Racket CS and BC at that level. > But my understanding is that Chez’s optimizer is much more > sophisticated than Racket BC’s. I wouldn't characterize it that way. If anything, Racket BC is more sophisticated and aggressive than Chez Scheme on high-level optimizations, especially around type reconstruction and cross-module optimizations. (For Racket CS, Gustavo added a type-reconstruction pass to Chez Scheme, and schemify handles cross-module optimization.) Chez Scheme's advantages are more on the back end: register allocation, calling conventions, and continuation management. > At the very least, I’d expect it to be able to identify that `v` > is never used here and simplify it to this: > > (let loop ([i 0]) > (define j (add1 i)) > (if (< j N) > (loop j) > i)) None of Racket BC, Racket CS, or Chez Scheme by itself will optimize away the unused loop argument. That kind of interprocedural dead-code elimination is out of reach for the current compilers, except to the degree that inlining turns them into intraprocedural questions. > Now I’d wonder: if N is a known constant, could the optimizer just delete the > loop? Only for short loops: Racket BC will turn that into a constant for N up to 15. Racket CS will turn it into a constant only for N as 0. (Well, almost; both of them leave a `check-range` call behind, because they're not willing to inline it.) The difference between Racket CS and BC in this case reflects more aggressive inlining in Racket BC. > Could the whole thing be optimized to (sub1 N)? Given the performance > numbers in the blog post, I’m guessing the answer is no. Is the reason just > that Chez doesn’t perform this kind of optimization, or is there something > more fundamental? Converting loops into closed form requires more sophisticated and general induction reasoning than is typical in a compiler. Or it needs ad hoc pattern patching to cover a few cases --- which I have seen gcc do, but I don't think that's very common. -- 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/5e5276f9.1c69fb81.985f0.0cc3SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
