[HN Gopher] Optimizing the unoptimizable: a journey to faster C+...
___________________________________________________________________
Optimizing the unoptimizable: a journey to faster C++ compile times
Author : coffeeaddict1
Score : 47 points
Date : 2024-01-06 19:21 UTC (1 days ago)
(HTM) web link (vitaut.net)
(TXT) w3m dump (vitaut.net)
| npalli wrote:
| The real solution to fast compilation is to have modules. These
| kind of one-off hacks are interesting but will not scale.
| citrin_ru wrote:
| Modules is one of reasons why Pascal is fast to compile and I
| wish it was more popular than it was.
| jll29 wrote:
| 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.
| foofie wrote:
| > 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 build times to a residual length which if
| my memory doesn't fail me was dubbed horizontal architecture.
| It consists of designing every single subprojects to be stand-
| alone and leave any integration to the linking stage. I've used
| it in the past on a legacy C++ project that took slightly over
| 1h to pull off an end-to-end build, and peeling out 4 or 5
| subprojects following the horizontal architecture approach
| allowed me to cut down full end-to-end build times to slightly
| over 8 minutes and incremental builds down to less than a
| minute, without bothering with compiler caches. I'm sure that
| if I bothered onboarding ccache I could drive incremental build
| times to just a few seconds.
|
| If you know what you are doing, you can do a lot without
| begging for magic.
| krapht wrote:
| 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".
| pjmlp wrote:
| 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.
| vitaut wrote:
| 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/.
| widdershins wrote:
| 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?
| vitaut wrote:
| AFAICS the main problem is that <string> pulls in a lot of
| dependencies.
| mkoubaa wrote:
| Surely this is an implementation detail that vendors can
| change
| vitaut wrote:
| 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.
| pjmlp wrote:
| 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 << "Hello World!\n"; }
| vitaut wrote:
| 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).
| stabbles wrote:
| Looks like the stdio example includes compilation and linking,
| fmt example only times compilation.
| vitaut wrote:
| 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....
___________________________________________________________________
(page generated 2024-01-07 23:01 UTC)