Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing the unoptimizable: a journey to faster C++ compile times

vitaut.net

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#21

Post by pjmlp »

vitaut wrote: post #18
pjmlp wrote: post #10

Earlier quoted context omitted.

It isn't when using modules, import std brings in the whole standard C++ faster than that #include. EDIT: This compiles in 1 second on an i7 laptop. import std; int main() { std::cout

Unfortunately the std module alone doesn't help much because 1 second is 3x slower than before the optimization described in the post but maybe more fine-grained modules will (or if std module import made faster).

For the whole library, everything.

Also Microsof Office team has been migrating to modules, with great build improvements.

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#22

Post by OskarS »

pjmlp wrote: post #10
widdershins wrote: post #6

So why on earth is std::string so slow to compile, if it's possible to compile this full-featured formatting library in 1/4 of the time?

It isn't when using modules, import std brings in the whole standard C++ faster than that #include. EDIT: This compiles in 1 second on an i7 laptop. import std; int main() { std::cout

Not to be "that guy", but... one second is a VERY VERY long time to compile a hello world program.

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#23

Post by pjmlp »

OskarS wrote: post #22
pjmlp wrote: post #10

Earlier quoted context omitted.

It isn't when using modules, import std brings in the whole standard C++ faster than that #include. EDIT: This compiles in 1 second on an i7 laptop. import std; int main() { std::cout

Not to be "that guy", but... one second is a VERY VERY long time to compile a hello world program.

Including compiling from scratch the complete C++ standard library on first use, which I should probably have mentioned.

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#24

Post by foofie »

krapht wrote: post #14
foofie wrote: post #9

Earlier quoted context omitted.

> The real solution to fast compilation is to have modules. I don't agree. The real solution for fast compilation times is to not have to recompile things. This means onboarding tools like ccache, organize your project around independent subprojects which eliminate/minimize compile-time dependencies, and leverage incremental builds. There's a C++ book somewhere that describes how the subprojects approach helps lower…

Nah, C++ needs more than that. There's some ridiculous template heavy code out there where the majority of time is spent linking. You can't even do a debug build without optimizations on Windows with these programs because the coff file format can't handle it, even when compiling with "/bigobj".

> Nah, C++ needs more than that. There's some ridiculous template heavy code out there where the majority of time is spent linking.

C++ does not "need" more than that. You personally might find it more convenient if you don't have to think through your software architecture, but the truth of the matter is that you only need to spend a few minutes looking at your project to speed everything up, which is exactly what everyone does the very moment they feel they have a problem.

It makes no sense at all to demand a whole tech stack to change around you when you can't even spend a few minutes looking for an answer to the problem you have.

> There's some ridiculous template heavy code out there where the majority of time is spent linking.

That is not a problem. Templates are only special in a build because compilers spend time generating code. Again, you can work around that without any problem at all with the tools available to you for the past two or three decades.

Properly modularizing your app with explicit template instantiation already drives down the build time of any naive project structure to a fraction of the time, and basic stuff like onboarding a compiler cache tool and moving template code out of interface headers is enough to get the linking stage to be the most expensive step of a build.

> You can't even do a debug build without optimizations on Windows with these programs because the coff file format can't handle it, even when compiling with "/bigobj".

I'm sorry but this is simply not true. I suggest you start to look at your projects to break it down to subprojects and see where the critical path of your build is. There is absolutely no project in the world whose build would not take less than a minute (or even a few seconds) with incremental builds, even if it's code that uses template metaprogramming extensively.

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#25

Post by oldpersonintx »

pjmlp wrote: post #11
npalli wrote: post #5

The real solution to fast compilation is to have modules. These kind of one-off hacks are interesting but will not scale.

Available since C++20, C++23 brings the whole standard library in a simple import std; and is already available in VC++, clang 17/cmake, with GCC 14 catching up.

[dead]

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#26

Post by za3faran »

pjmlp wrote: post #21
vitaut wrote: post #18

Earlier quoted context omitted.

Unfortunately the std module alone doesn't help much because 1 second is 3x slower than before the optimization described in the post but maybe more fine-grained modules will (or if std module import made faster).

For the whole library, everything. Also Microsof Office team has been migrating to modules, with great build improvements.

Any place where I can read up more about this?

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#27

Post by pjmlp »

za3faran wrote: post #26
pjmlp wrote: post #21

Earlier quoted context omitted.

For the whole library, everything. Also Microsof Office team has been migrating to modules, with great build improvements.

Any place where I can read up more about this?

https://devblogs.microsoft.com/cppblog/integrating-c-header-...

https://devblogs.microsoft.com/cppblog/integrating-c-header-...

Key takeway

"Fortunately, we were able to show a build performance improvement great enough that the team agreed to adopt header units into the Office production build system alongside msvc 17.6.6!"

Unfortunely the performance findings blogpost is still WIP.

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#28

Post by MauranKilom »

foofie wrote: post #24
krapht wrote: post #14

Earlier quoted context omitted.

Nah, C++ needs more than that. There's some ridiculous template heavy code out there where the majority of time is spent linking. You can't even do a debug build without optimizations on Windows with these programs because the coff file format can't handle it, even when compiling with "/bigobj".

> Nah, C++ needs more than that. There's some ridiculous template heavy code out there where the majority of time is spent linking. C++ does not "need" more than that. You personally might find it more convenient if you don't have to think through your software architecture, but the truth of the matter is that you only need to spend a few minutes looking at your project to speed everything up, which is exactly what e…

I agree with the thrust of your argument that there are a lot of compile-time-encapsulation tools you can employ to reduce build times.

However, I will still challenge you on your build time/object size claim. Take a codebase structured around lazy tasks (i.e. every function is a coroutine), factor in runtime parallelism/SIMD dispatch, multiply with loop abstractions (think std::ranges) and you get frighteningly close to linker limits in no time (which, of course, also implies minutes of compilation per source file). Each of those pieces is templates through and through, and there's no explicit template instantiation way out of any of them.

Also, I have to (sadly) point out that explicit template instantiation declarations only take you so far. Yes, they reduce compiler time spent in codegen, but also cause the compiler to create all required transitive (!) declarations in every TU, which will quickly offset those gains when talking about template types that have lots of small member functions.

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#29

Post by OskarS »

pjmlp wrote: post #23
OskarS wrote: post #22

Earlier quoted context omitted.

Not to be "that guy", but... one second is a VERY VERY long time to compile a hello world program.

Including compiling from scratch the complete C++ standard library on first use, which I should probably have mentioned.

What's the incremental compile time? If you just change that "Hello World" string to something else, does it compiler faster the second time?

Re: Optimizing the unoptimizable: a journey to faster C++ compile times

#30

Post by foofie »

MauranKilom wrote: post #28
foofie wrote: post #24

Earlier quoted context omitted.

> Nah, C++ needs more than that. There's some ridiculous template heavy code out there where the majority of time is spent linking. C++ does not "need" more than that. You personally might find it more convenient if you don't have to think through your software architecture, but the truth of the matter is that you only need to spend a few minutes looking at your project to speed everything up, which is exactly what e…

I agree with the thrust of your argument that there are a lot of compile-time-encapsulation tools you can employ to reduce build times. However, I will still challenge you on your build time/object size claim. Take a codebase structured around lazy tasks (i.e. every function is a coroutine), factor in runtime parallelism/SIMD dispatch, multiply with loop abstractions (think std::ranges) and you get frighteningly clos…

> However, I will still challenge you on your build time/object size claim. (...)

Nothing in your example suggests long compilation times are a hard requirement. Just move your components into submodules and remove template code from interfaces. Your build only needs to recompile what you tell it to recompile.

> Also, I have to (sadly) point out that explicit template instantiation declarations only take you so far.

It takes you as far as you need to go. You instantiate what you need, you move your template code into submodules and out of interface headers, and you're set. This is not sourcery. It's common sense.

I recommend you read "large scale C++,vol1 - process and architecture" to get acquainted with basic C++ techniques to structure your project so that builds don't waste time chewing through code they don't need to touch.

Post reply on HN