111–117 of 117 posts
It sucks that there is no way to use cranelift from outside of rust to create your own toy language. I would have loved to use cranelift in a toy compiler, but I am not ready to pay the Rust price of complexity.
[1]: https://docs.rs/cranelift-frontend/0.105.3/cranelift_fronten... [2]: https://pyo3.rs/v0.15.1/
Earlier quoted context omitted.
Superoptimizers: https://en.wikipedia.org/wiki/Superoptimization Also, program distillation: https://www.researchgate.net/publication/220989887_Distillat...
Isn't it a bit weird that this isn't just the standard? Like imagine if Chrome was optimized with such a superoptimizer; let the optimizer spend a couple hours every month or so when cutting a new release. Surely that has to be worth it?
Earlier quoted context omitted.
Can you memoize across invocations so that the time spent optimizing is cumulative across all builds?
Speaking as an e-graph rookie - I believe so, with caveats. You can certainly store the chosen extractions/optimizations and re-use any that don't change. For example, if a long chain of rewrites yields A ==> B ==> ... ==> Z, you could short-circuit that and assume that Z is still what you want to replace A with. Perhaps each time you compiled, you could only rewrite the 'changed' sections of the program, along with…
EDIT: Right. Blech. Theta & Phi nodes.
Very excited for Cranelift for debug builds to speed up development iteration - in particular for WASM/Frontend Rust where iteration speed is competing with the new era of Rust tooling for JS which lands in the sub 1 second builds sometimes (iteration speed in Frontend is crucial). Sadly, it does not yet support ARM macOS, so us M1-3 users will have to wait a bit :/
Very excited for Cranelift for debug builds to speed up development iteration - in particular for WASM/Frontend Rust where iteration speed is competing with the new era of Rust tooling for JS which lands in the sub 1 second builds sometimes (iteration speed in Frontend is crucial). Sadly, it does not yet support ARM macOS, so us M1-3 users will have to wait a bit :/
As someone who doesn't work in the frontend much, what tools are you talking about?
- Rspack (webpack compatible)
- Rolldown (rollup compatible)
- Turbopack
- Oxc (linter)
- Biome (linter and more)
- Bun (writing in Zig, does crazy fast bundling)
There’s several parts here that are crucial to Frontend development
For production you need:
- Minificion of source code
- Bundling of modules and source code into either one JS file or split into multiple for lazy loading only the parts you need
- Transforming various unsupported high-level constructs into something older target browsers support
- Typechecking/compiling, or stripping TypeScript if that’s in use
Build times could easily go to 10-20 minutes with older tools.
The development loop also gets hurt, here you’d want the loop from saving your change to seeing it in the UI to be almost instant. Anything else means you’ll have to develop crutch methods to workaround this (imagine moving and styling components only to need to sit and wait during each small incremental change).
Earlier quoted context omitted.
As someone who doesn't work in the frontend much, what tools are you talking about?
There’s been a recent trend of rewriting tools in Rust with insanes speed gains - Rspack (webpack compatible) - Rolldown (rollup compatible) - Turbopack - Oxc (linter) - Biome (linter and more) - Bun (writing in Zig, does crazy fast bundling) There’s several parts here that are crucial to Frontend development For production you need: - Minificion of source code - Bundling of modules and source code into either one JS…