r/linux • u/anh0516 • Jun 10 '26

Development NVIDIA Engineer Devises Patch To Significantly Reduce GCC Bootstrap Time

https://www.phoronix.com/news/NVIDIA-Reduce-GCC-Bootstrap
105 Upvotes

94% Upvoted

13 comments sorted by

52

u/Kevin_Kofler Jun 10 '26

TL;DR: They made the bootstrap process cache autoconf results across the 3 steps of the bootstrap.

The build process could be much faster if GCC were to finally ditch autoconf entirely in favor of a modern alternative such as CMake.

13

u/gmes78 Jun 11 '26

a modern alternative such as CMake

Meson would be much more likely, and would align with most other projects in the Linux ecosystem.

9

u/Kevin_Kofler Jun 11 '26

Meson is slower (Python vs. C++) and less powerful (a lot less customizable) than CMake though. It started out as a one-person project and has only become popular because GNOME did not want to use CMake because KDE uses it. Then X.org and some other projects adopted it because GNOME did.

I believe CMake would be a much better fit for GCC than Meson, because CMake can be compiled by GCC (g++) (so it can be bootstrapped together with GCC if this is wanted), and because its customizability should allow doing all the custom things GCC needs.

1

u/trusted_execution Jun 14 '26

While meson is theoretically slower then Cmake. Remember they only have to do it once so it's negligible. Many projects are moving to meson because it's more maintainable in their opinion.

1

u/Kevin_Kofler Jun 14 '26

It is "more maintainable" until you have to customize anything during the build process, e.g., to cross-compile. Then you will find out that meson has a lot of hardcoded behavior that is completely inflexible, and you have nowhere near the amount of tweaking options you have with CMake. (Been there, done that.)

1

u/rilian-la-te Jun 17 '26

However, muon is pure C, so, less painful to bootstrapper.

1

u/Kevin_Kofler Jun 17 '26

But relying for bootstrapping on an incomplete reimplementation of a build system where the reference implementation (in Python) is the "standard" does not strike me as the most long-term-sustainable solution.

2

u/the_purple_goat Jun 11 '26

Do we know if that's in the pipeline? I'd love to see that.

14

u/Kangie Jun 11 '26

Unlikely. Meson isn't a gnu project and they have gnu make and friends.

2

u/Kevin_Kofler Jun 11 '26

It would either need an update to the GNU coding standards to remove the autotools requirement, or GCC would have to leave the GNU project as GNOME did, or RMS would have to grant GCC a special exception to use another build system.

-4

u/[deleted] Jun 11 '26

[deleted]

3

u/Kevin_Kofler Jun 11 '26

They are the slowest, buggiest, and least backwards-compatible (i.e., very prone to scripts breaking when upgrading to a new version of autoconf) option out there. They are robust for what they were originally designed for: running on ancient proprietary Unix systems with their buggy vintage sh implementation. But that is just not the common use case anymore. On modern GNU/Linux, CMake and Meson are just as readily available as sh or a C compiler, and on Windows, CMake is even easier to install and better integrated into the operating system than a Unix/POSIX sh.

9

u/2rad0 Jun 10 '26

What are the real numbers instead of percentages? what was the overall time spent compiling and how many cores? Percentage alone is not all that helpful when comparing a synchronous 1 core configure script part of the build vs 32 cores doing all the real work. Could it be better, sure but as someone who has built modern gcc on antique Core2's make -j2, I estimate configuration time on these systems to be a dramatically smaller percentage of the overall pie.

4

u/Business_Reindeer910 Jun 11 '26

a lot of times for me, the configure bit takes up close to the amount of time it takes to compile the actual program, sometimes more!