Re: Baby X is bor nagain

On 23/06/2024 20:21, bart wrote:

On 23/06/2024 13:25, David Brown wrote:

To be fair here, I have a /lot/ of flags for my builds, and the only thing I changed here was the main optimisation number.  Other flags might still have had an influence in the compiler run time, such as the warning flags.  But there's a limit to how much effort I'm going to spend playing around for a Usenet post.

 That depends on whether your want your findings to be accurate and not misleading. ATM your figures and also your comments raise some red flags for me.

I've given figures for what changing the optimisation level means to the timing of /my/ builds.  Things can be different for other people.  You have gone on and on about how compilation time is the only thing that matters to you, and how important it is to use "gcc -O0" to keep compile times low.  I've shown that, for my code and my builds, disabling optimisation has such a small impact on the build time that it is not remotely worth it.
This might not be /your/ experience, but it is my experience.  And of all the people I have worked with, I've never known a single occasion when anyone has used low optimisation because of build speed.  I've seen plenty of people compile without optimisation for various reasons (usually bad reasons or plain ignorance), but never because of speed.

 TBF this is a problem with smart compilers, some may find some way of caching previous results - beyond whatever the file system does - even if you delete the relevant binaries (I think Rust or Zig did this).

gcc does not cache previous results.  It is a program of *nix heritage - it does its job, and lets other programs do theirs.  So if you want caching of compilation, you use a different program - ccache.  (And I /do/ use that for some projects, especially if there is a lot of C++ or the builds involve a lot of parallel builds with different options for different target variants.  It was not used in the timings I gave here, however.)

 

  And a great many of the flags (not the warning flags) are important for actually generating the correct code for the correct target, so sorting out those that could be removed in order to make a completely pointless and useless near-unoptimised build is just not worth the effort.  However, changing the main optimisation number to 0 certainly reduced the code generation to much less efficient code - likely too slow to work for some critical aspects of the program.

 And yet, -O2 must have invoked all those dozens of optimising passes to make that difference, all for only 15% cost?
 

That's the numbers I measured.  I would not be surprised to see a significantly bigger difference on a single compile of a single file, independent of the rest of the build.  But such figures would be meaningless to me - the time it takes to build the target binaries is the relevant number.