Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Mon, 24 Jun 2024 10:16:09 +0200
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <v5ba09$r66u$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <v4p37r$k32n$1@dont-email.me>
 <v4pei3$m5th$2@dont-email.me> <v4plsk$nn9o$2@dont-email.me>
 <v4pnq6$o4fs$1@dont-email.me> <v4q245$si2n$1@dont-email.me>
 <v4q2rl$sqk3$1@dont-email.me> <v52308$2nli8$3@dont-email.me>
 <v53i4s$33k73$2@dont-email.me> <v53lf7$34huc$1@dont-email.me>
 <v53vh6$368vf$1@dont-email.me> <v54se1$3bqsk$1@dont-email.me>
 <v5948h$bale$1@dont-email.me> <v59p2j$eodu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Jun 2024 10:16:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="995058d498c537c0d70be20402ad0eb4";
	logging-data="891102"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX194XcaFMxGYfmLsxXzrogRpk2bUH++5zp4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:lDr+ZndYXSYFeFZNWulGLVgxkLI=
Content-Language: en-GB
In-Reply-To: <v59p2j$eodu$1@dont-email.me>
Bytes: 4911

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.