4 ms·
Actually C/C++ compilers are shooting themselves in the foot performance-wise with the header mechanism, so writing a compiler that's faster than C/C++ is not t
by rob74 4y ago
Actually C/C++ compilers are shooting themselves in the foot performance-wise with the header mechanism, so writing a compiler that's faster than C/C++ is not that hard. Not sure what the reasons of the Rust compiler being (even more?) slow are, maybe the ability to easily interface with C code has something to do with it?
- nine_k 4y agoLast time I checked [1], the Rust part of the Rust compiler is not the slowest. LLVM spends a lot of time processing relatively poor IR code which the Rust compiler emits. Rust compilation is not intrinsically slow; better IR and more incremental compilation can and will improve it. Incremental compilation (only changed files, not crates) is 7 years in making though. [1]: https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow
- rob74 4y agoThanks for that link! That sounds like the really major factor is the decision to recompile the entire crate when a file in the crate changes. I'm sure that made sense at the time ;) And, if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision - incremental compilation might have its edge cases and pitfalls, but other compilers are doing it just fine, so it shouldn't be rocket science? Other reasons: - suboptimal LLVM IR code, as you mentioned, and other tech debt - the preferred strategy of monomorphising generics is fast at runtime, but slow to compile, using trait objects is faster - the complex type system of course also plays a part - LLVM itself is of course not optimized for Rust
- rbanffy 4y ago> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision Maybe we are giving Rust developers computers that are too fast. ;-) OTOH, it's always wise to design for the future, so it also makes sense to give Rust developers beefy server grade hardware so they can play with SIMD pipelines and all those extra cores and threads, because that's what workstations will be a couple years from now.
- asoneth 4y ago> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision I'm not sure it was a "bad decision" if it was something that can be addressed after the fact and allowed them to ship working software more quickly. The vast majority of the popular projects I am aware of have this kind of technical debt, likely due to survivorship bias. Project teams that refuse to take on technical debt are rarely successful enough to become popular.
- flohofwoe 4y agoIn this case I really have to nitpick about the use of "C/C++": This specific problem really only exists in C++, because there it is common to put implementation code into headers via inline and template functions (worst example is the C++ stdlib), while in C you only put declarations into headers, and just parsing a few hundred lines of struct and function declarations won't blow up your build times (while just including a common C++ stdlib header like <vector> pulls in tens of thousands of lines of tricky template code.
- pjmlp 4y agoIn VC++ "import std", which imports the whole C++ standard library, is faster than just doing "#include <iostreams>". It is only a matter of time, until GCC and clang finally catch up.
- jeffparsons 4y agoAccording to Wikipedia, both have support for precompiled headers: https://en.m.wikipedia.org/wiki/Precompiled_header https://en.m.wikipedia.org/wiki/Precompiled_header Shouldn't this be enough? Or does it require explicitly including the precompiled header whereas VC++ has magic to make that transparent?
- pjmlp 4y agoC++20 modules and pre-compiler headers aren't the same thing in terms of technology.