I wish them every success, but i hope for a more balanced overview of pros and cons rather than gushing praise at every step...
Cranelift code generation comes to Rust
31–40 of 117 posts
Re: Cranelift code generation comes to Rust
#32Slightly off-topic, but if you fancy writing compilers in your free time, Cranelift has a great Rust library[0] for doing code generation - it’s a pleasure to use! [0]: https://docs.rs/cranelift-frontend/0.105.3/cranelift_fronten...
Re: Cranelift code generation comes to Rust
#33This article provides an excellent overview of the latest in speed of optimizer vs quality of optimization . In particular, copy-and-patch compilation is still the fastest approach because it uses pre-compiled code, though leaves little room for optimization. Cranelift uses e-graphs to represent equivalence on the IR. This allows for more optimizations than the copy-and-patch approach. Of course, the most optimized o…
Agree, especially when developing, I'd assume speed of optimizer matters more than quality of optimization. I wonder though if LLVM spent less time on that "phase ordering" problem, what is the tradeoff between these two factors?
Re: Cranelift code generation comes to Rust
#34Re: Cranelift code generation comes to Rust
#35[flagged]
Re: Cranelift code generation comes to Rust
#36Can anyone explain why Cranelift is expected to be faster than LLVM? And why those improvements can't also be applied to LLVM?
It’s also unlikely that the resulting code will ever be as fast as a traditional compiler’s output. It’s great for development, but I wouldn’t use it in a release build.
Re: Cranelift code generation comes to Rust
#37Earlier quoted context omitted.
From the article: > A full debug build of Cranelift itself using the Cranelift backend took 29.6 seconds on my computer, compared to 37.5 with LLVM (a reduction in wall-clock time of 20%) That seems much smaller difference than what I would have expected
Those numbers are the entire compile time, parsing/typecheck/MIR+MIR optimization/linking Don't have numbers handy, so hard to say how much faster Cranelift is making the codegen portion, but gets into Amdahl's Law
…why is it still the default?
Re: Cranelift code generation comes to Rust
#38I see that there are many comments on full debug builds, but for me the most important difference are incremental build times when making minor changes. In my opinion this is what speeds up the development iterations. Here are my build times when making a trivial change to a print-statment in a root function, comparing nightly dev vs adding cranelift + mold for rust-analyzer[0] (347_290 LoC) and gleam[1] (76_335 LoC)…
Re: Cranelift code generation comes to Rust
#39I see that there are many comments on full debug builds, but for me the most important difference are incremental build times when making minor changes. In my opinion this is what speeds up the development iterations. Here are my build times when making a trivial change to a print-statment in a root function, comparing nightly dev vs adding cranelift + mold for rust-analyzer[0] (347_290 LoC) and gleam[1] (76_335 LoC)…
$ time cargo build
Compiling example-todos v0.1.0 (/home/user/ws/rust/example-todos)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.65s
cargo build 1.49s user 0.58s system 123% cpu 1.685 total
Compiling example-todos v0.1.0 (/home/user/ws/rust/example-todos)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.55s
cargo build 0.47s user 0.13s system 102% cpu 0.590 total
[0] https://github.com/tokio-rs/axum/tree/main/examples/todosRe: Cranelift code generation comes to Rust
#40It 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.