Optimizing the unoptimizable: a journey to faster C++ compile times • Hacker News Board

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

#11

Post by pjmlp » Sun, Jan 07, 2024, 8:20 PM UTC

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.

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

#12

Post by mkoubaa » Sun, Jan 07, 2024, 8:51 PM UTC

vitaut wrote: post #8

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?

AFAICS the main problem is that pulls in a lot of dependencies.

Surely this is an implementation detail that vendors can change

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

#13

Post by stabbles » Sun, Jan 07, 2024, 9:36 PM UTC

Looks like the stdio example includes compilation and linking, fmt example only times compilation.

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

#14

Post by krapht » Sun, Jan 07, 2024, 9:36 PM UTC

foofie wrote: post #9

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.

> 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".

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

#15

Post by jll29 » Sun, Jan 07, 2024, 9:46 PM UTC

citrin_ru wrote: post #7

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.

Modules is one of reasons why Pascal is fast to compile and I wish it was more popular than it was.

Even more so in Modula-2 (as the name suggests), where you can compile module definitions separately from their implementations and already have the compiler perform syntax checks against APIs defined therein before they are even implemented.

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

#16

Post by vitaut » Sun, Jan 07, 2024, 10:03 PM UTC

mkoubaa wrote: post #12

vitaut wrote: post #8

Earlier quoted context omitted.

AFAICS the main problem is that pulls in a lot of dependencies.

Surely this is an implementation detail that vendors can change

Implementations can be improved somewhat but there is a certain set of dependencies that must be included according to the standard and for string it's pretty big.

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

#17

Post by vitaut » Sun, Jan 07, 2024, 10:11 PM UTC

stabbles wrote: post #13

Looks like the stdio example includes compilation and linking, fmt example only times compilation.

Good catch, thanks! Fixed now. This explains why the difference was kinda low compared to another benchmark: https://github.com/fmtlib/fmt?tab=readme-ov-file#compile-tim....

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

#18

Post by vitaut » Sun, Jan 07, 2024, 10:35 PM UTC

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

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).

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

#19

Post by vitaut » Sun, Jan 07, 2024, 10:53 PM UTC

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.

I agree that modules is the right long-term solution and in fact {fmt} is modularized: https://vitaut.net/posts/2023/cxx20-modules-in-clang/.

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

#20

Post by cozzyd » Mon, Jan 08, 2024, 2:34 AM UTC

foofie wrote: post #9

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.

> 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…

Somehow my Fedora laptop seemed to automagically use ccache, which made me happy.