Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

The compile time issues for C++ are entirely because of the creaky header mechanism that doesn't permit efficient parsing. Generics have worked fine in Ada since its inception. Any modern language can adopt the same process of tracking a formal abstract interface that is parsed once and expanded into concrete code as necessary.

View on HN

The process of expanding genetic code into concrete code based on the types (monomorphizing) can also be an expensive process. At least, people in the rust world point to it a lot as a reason why some crates compile slowly. Monomorphizing multiplicatively increase how much code LLVM needs to process (and optimize).

Mind you, C/C++’s ridiculous header system is probably still a much bigger issue. Especially because C++ templates usually need to go in header files.

Although monomorphization takes a significant chunk of a typical Rust compilation, it pales in comparison to LLVM codegen and execution of procedural macros. So although it's academically worthy of note, optimization-wise it's not where the focus should be. Personally, I'd like to see someday a Rust compiler which is not based on LLVM. Both Zig and Jai compile much faster when using their non-LLVM backends than when using LLVM, so Rust is not the odd one here either.

> Although monomorphization takes a significant chunk of a typical Rust compilation, it pales in comparison to LLVM codegen

It's not the monomorphization itself that takes a long time, it's the LLVM codegen due to all the extra code being generated from duplicated function implementations. I've heard macros slow for largely the same reason, it's not the macro execution itself that's slow, it's compiling all the generated code.

> I've heard macros slow for largely the same reason, it's not the macro execution itself that's slow, it's compiling all the generated code.

If that were true, the same issue would apply to hygienic macros, yet it doesn't. It's distinctly a problem with proc macros.

> Mind you, C/C++’s ridiculous header system is probably still a much bigger issue. Especially because C++ templates usually need to go in header files.

IDK about that. A project I'm working on is template-heavy in a major way, entirely header-only (~15kloc of this: https://github.com/celtera/avendish/blob/main/include/avnd/c... more or less) but with a barely correctly set-up dev environment with clang and PCH (a couple lines in CMake), ninja and mold, individual rebuilds are pretty much instant ; a complete rebuild which on my machine builds 49 libraries and 38 executables takes a whopping 7 seconds, CMake included.

Increases compared to what? If you don't use generics and write the code for each type manually, you'll end up with exactly the same thing.

I often wonder about that - if I was going to write by hand I might end up extracting a simple interface, do some type coercion/promotion or some other trick to reduce the number of functions I need to write.

I read about how .Net does Generics at the VM level and was very impressed, a good compromise between C++ "macro expansion" and Java "type erasure", both of which seem extreme.

At the end of the day, though, when generics are present I stop worrying and just use List<int>, List<float>, List<char>, etc. without a second thought. The compiler, VM or runtime can deal with it although I might get punished in some way.

Increased compile time compared to doing polymorphism with an extra layer of indirection, I’m guessing

Isn't that solved with c++ modules [1]?

[1] https://en.cppreference.com/w/cpp/language/modules

Not really, in C++ templates still need to be instantiated in every module but modules don't have to each repeat the parsing of template definitions. The module that declares the template will do the job of parsing the template and producing some intermediate representation of it that other modules can consume. Okay that does save some amount of time but the overwhelming majority of time spent compiling templates is in instantiating them, not parsing them from literal text into an AST.

Modules don't make instantiating templates any faster, it only makes parsing them faster.

They sure do, make the most common expansions avaiable as extern templates.

That has nothing to do with modules. You can extern a template going back to C++11.

Modules make it more convinient to do so, and allow for more build speedups.

Yes, with VC++ offering the best experience currently.

I am confused. Why was this downvoted? Is GCC and Clang doing better? (Or another C++ compiler?)

Because the answer is false, modules do not solve the problem of having common/shared template instantiations.

As for the comment about MSVC, it's mostly off topic, doesn't relate to the question that was asked (which had nothing to do with which compiler provides the best experience), and even if you accept that MSVC provides the best module experience, it's support for it is still very buggy and not suitable for anything other than experimenting and beta testing.

Rust also has (relatively) bad compile times due to generics. Not as bad as C++, but you can notice it's significantly worse than Go.

Rust does compile slower than Go, but it's not due to generics. It's mostly due to LLVM codegen and procedural macros. Go has the benefit of not relying on LLVM and not having procedural macros.

A lot of the IR comes from expanding huge stacks of generic functions. I don't think the issue can't be neatly partitioned up like that.

Absolutely true. I’d add that Rust is also doing a lot more expensive optimizations in release builds.

Until recently Go didn't even use registers for passing arguments, it just put everything on the stack like in a 1965 textbook (https://go.googlesource.com/proposal/+/refs/changes/78/24817...)

If you mean for function calls, I believe you're correct, not taking into account inline functions.

However, for code generation Go obviously uses registers since way before the 1.0 days.

You are right of course about LLVM being source of slowness.

In general discussion I see around is that all Rust's perf optimizations are to Rust's credit (nothing about LLVM optimization) while all woes around Rust's compile time lay at step of LLVM and Rust is not be blamed.

D, Ada, Eiffel, Delphi go as counter example, and C++ modules are already proving a much better experience in VC++.

Delphi didn't have generics. Not sure about more modern versions, but the power of the generics also impacts compile times. Java generics barely impact compile times at all but they're also nowhere as powerful as Rust and C++ ones.

You stop using Delphi long time ago, I would say.

To pick one of my examples, D templates and compile time metaprogramming are even more powerfull than Rust and C++ ones, yet it compiles just as fast.

Delphi added generics in 2009

So it had them roughly as long as Go existed

There is tinygo with llvm backend and the build times are abysmal.

That's not true, Rust doesn't have those headers and has the same compile time issues as C++.

Rust has macros and an expensive type system though, and compilation is getting faster.

Reply on news.ycombinator.com