4 ms·
I guess my question is - what is to be done? Even C++ is quite slow to compile. If all rustc development stopped and there was a years-long effort to write it "
by insanitybit 4y ago
I guess my question is - what is to be done? Even C++ is quite slow to compile. If all rustc development stopped and there was a years-long effort to write it "fast", what sort of improvements could we see?
- vegerot 4y agoThey should rewrite it in Rust
- xnickb 4y agoIt is already in rust. Which is a major problem for anyone trying to bootstrap rust for packages.
- strager 4y agoGood question! Based on my profiling, it seems like the code gen backend (LLVM) is a big offender. A code generator optimized for build times would be nice. (Cranelift seems to be a failure in that regard.) C++ has an explicit template instantiation feature which helps reduce backend time. I wonder if this can be done in Rust too. Maybe this is what -Zshare-generics=y is for?
- Bedon292 4y agoI don't know enough C++ or Rust to judge but is it possible that they are optimized around Rust that isn't C++ style? I know I have seen articles about other languages where some very minor changes make a huge difference because the optimizations in place didn't understand what was happening and had to work harder. And did you try any of the optimization strategies again at 24x? I would be curious if there are differences there.
- strager 4y ago> I don't know enough C++ or Rust to judge but is it possible that they are optimized around Rust that isn't C++ style? I know I have seen articles about other languages where some very minor changes make a huge difference because the optimizations in place didn't understand what was happening and had to work harder. Are you talking about run-time optimizations? My article is focused on build times. I don't think what you mentioned applies to build times. I could be wrong, though. (There are certainly compile time traps you can fall into, but I wouldn't know what those are in Rust.) > And did you try any of the optimization strategies again at 24x? I would be curious if there are differences there. No, I did not. That's a good suggestion. But I was pretty tired of this project by the time I made the scaling benchmarks. xD
- Bedon292 4y agoI did actually mean build time. I figured there could be optimizations within the build process which allows some specific style of code to build faster because it has to check things. Perhaps around memory safety, which could be a big deal in the line for line translation. And I totally understand being tired of it by that point. You did an extremely detailed and well documented process, and it was quite impressive. Thank you for sharing it.
- brabel 4y agoThe author mentioned it at the end: use Zig :)
- insanitybit 4y agoHow is Zig going to be that much faster?
- strager 4y agoGood question. The author of Zig claims that dev build times will be amazing. One technique is to avoid LLVM. Another technique is to integrate the linker. But all of that is a work-in-progress project.
- insanitybit 4y agoI'm skeptical. Cranelift was designed to do something similar - avoid LLVM and be fast enough for JIT. It's easy to claim to be fast when you're extremely early on, we'll see how that holds up.
- remorses 4y agoReplace LLVM with an alternative backend focused on compile time speed, Zig is already doing this.
- insanitybit 4y agoThat's what cranelift is, and that's what was tested here - it was not a massive speedup.