Re: Baby X is bor nagain

On 25/06/2024 23:28, Michael S wrote:

On Tue, 25 Jun 2024 17:08:42 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

>
Do you think the developers of gcc don't care?

 That's about right. At least for C, they don't.

I don't think speed of compilation for C is a big priority for gcc developers.  But that's not the same as saying they don't care.  Like any other big development project, they have limited resources and priorities - when Intel, ARM, Red Hat, Google, and other companies pay people to work on gcc, they want a concentration on the issues that matter to them and their customers.  Intel is not bothered about the speed of C compilation, because their customers are not bothered about it - they are a lot more interested in having the generated code running faster (especially on /their/ chips).

Most likely the same applies even stronger to Fortran.

Again, people don't care about the speed of Fortran compilation.  It is more than fast enough.
There are only two reasons anybody uses Fortran.  One is because they have a large code base in Fortran and are stuck with it.  The other is because they have code that does massive numerical calculations and they can get slightly more speed from it than the same thing in C (or C++). Compile speed is almost entirely irrelevant to both groups.

For C++ they would love to not care, but then their compiler would
become unusable. So they have to care, but probably very sorry about it.
 

C++, especially modern template-heavy code with header-only libraries, can easily take an order of magnitude or more longer to compile than roughly equivalent C.  It can easily take an order of magnitude or more longer to link.  And since projects in C++ are often far bigger than those in C - since C's lack of namespaces of any sort makes it a poor language for large code bases - speed of compilation is a different world here.

However bigger reason is not lack of care, but the style of their
development process. It's best described as a patchwork.
 

It is, yes.  It is a massive project built by vast numbers of people over three and a half decades.  Sometimes there are big renovations and significant parts get re-written for big gains.  But those are rare - they take a great deal of development resources, and they are a serious risk for new problems.  gcc is the backbone of far too much critical software to take big risks easily.
Some twenty years ago, someone also thought that gcc's code structure and development process was inflexible and limiting for a compiler, and it would be better to start with a clean, modern design with modern languages and tools, that allowed more modular development, streamlined and faster compilation, better error messages and cross-module link-time optimisations.  When llvm/clang was young, in comparison to gcc it was very much faster, had much nicer error messages and supported much more efficient link-time optimisation - at the expense of significantly less efficient generated code and less static checking.  Now llvm/clang is much more mature, and is comparable to gcc in generated code quality (clang wins some benchmarks, gcc wins most, but the differences are often minor).  And its compile times are not much faster than gcc.  It turns out that quality code generation takes time.
There are basically two things to be done about C++ compilation speed. One is to move past the literal inclusion of headers as a language model.  The problem with C++ compilation is not that it takes a long time to analyse and compile 2000 lines of code in a .cpp file.  It is that the compiler also has to deal with a million lines of include files for that compilation.  Thus we have C++ modules.  Unfortunately, retrofitting a good module solution to a language that has always used literal includes, is far from easy, and it has taken longer than anyone would have wanted to get them defined and standardised in the language, and to get implementations in place.  As these fall into place, however, it will be possible to move projects to being mostly module based and improve C++ build speeds in a way that you couldn't dream of by streamlining a C++ compiler.
The second challenge for C++ build times on large projects is linking. Here there are new linkers being developed that have C++ in mind, rather than being mere modifications of traditional linkers that targeted assembly, C and Fortran.