41–50 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.
Can anyone explain why Cranelift is expected to be faster than LLVM? And why those improvements can't also be applied to LLVM?
LLVM is a huge and bloated ecosystem (it has tons of tools and millions of LoC), also the code base itself is pretty old or rather the project has his age, so there's a lot of legacy code, other aspect is that is hard to try new/radical things because how big the project itself is.
Any fresh compilation time benchmarks and comparisons to LLVM?
Few reports comparing Cranelift to LLVM from this day old reddit thread [1] - 29.52s -> 24.47s (17.1%) - 27s -> 19s (29.6%) - 11.5s -> 8.4s (26.9%) - 37.5s -> 29.6s (28.7%) - this measurement from TFA. To put these numbers in context, all the perf improvements over the last 4 years have helped the compiler become faster on a variety of workloads by 7%, 17%, 13% and 15%, for an overall speed gain of 37% over 4 years.…
Can anyone explain why Cranelift is expected to be faster than LLVM? And why those improvements can't also be applied to LLVM?
> why those improvements can't also be applied to LLVM? LLVM is a huge and bloated ecosystem (it has tons of tools and millions of LoC), also the code base itself is pretty old or rather the project has his age, so there's a lot of legacy code, other aspect is that is hard to try new/radical things because how big the project itself is.
> The developers of Cranelift chose to use a more generic architecture, which means that Cranelift is usable outside of the confines of WebAssembly.
One would think this has more to do with Wasm being the source language, as it's fairly generic (compared to JS or Python), so there are no specific assumptions to encode.
Great article though. It's quite interesting to see E-matching used in compilers, took me down a memory lane (and found myself cited on Wikipedia page for e-graphs).
You can use different backends and optimization for different crates. It often makes sense to use optimized LLVM builds for dependencies, and debug LLVM or even Cranelift for your own code. See https://www.reddit.com/r/rust/comments/1bhpfeb/vastly_improv...
[flagged]
Seriously, spam at HN? That is pretty unusual to see.
Earlier quoted context omitted.
Maybe your build is not limited by code generation, which seems like the only thing that changed here. There was a good thread recently about the variation in what slows down compilation: https://news.ycombinator.com/item?id=39721922
Edited my comment now, forgot I was caching the release builds with sccache so wasn't actually compiling all the units, but fetching a lot of them instead :/
Even cooler would be if LLVM itself could also cache internal expensive parts of compilation and optimization across process instances. That would make a huge impact in cutting down incremental builds.
Can anyone explain why Cranelift is expected to be faster than LLVM? And why those improvements can't also be applied to LLVM?
> why those improvements can't also be applied to LLVM? LLVM is a huge and bloated ecosystem (it has tons of tools and millions of LoC), also the code base itself is pretty old or rather the project has his age, so there's a lot of legacy code, other aspect is that is hard to try new/radical things because how big the project itself is.
(years pass...)
Y is too bloated! We need Z...