Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Sun, 23 Jun 2024 19:21:07 +0100
Organization: A noiseless patient Spider
Lines: 171
Message-ID: <v59p2j$eodu$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 23 Jun 2024 20:21:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0266ed5046595e5c7aa872240b0c2e48";
	logging-data="483774"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX186lpjNmNkX9HKIQtzpL4PR"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:oSVqVrYQ8OF+tA3/CjzDok1BKrs=
Content-Language: en-GB
In-Reply-To: <v5948h$bale$1@dont-email.me>
Bytes: 8269

On 23/06/2024 13:25, David Brown wrote:
> On 21/06/2024 23:47, bart wrote:
>> On 21/06/2024 14:34, David Brown wrote:
>>> On 21/06/2024 12:42, bart wrote:
>>>> On 21/06/2024 10:46, David Brown wrote:
>>>>> On 20/06/2024 22:21, Vir Campestris wrote:
>>>>>> On 17/06/2024 20:29, David Brown wrote:
>>>>>>> I do my C development with optimisations enabled, which means 
>>>>>>> that the C compiler will obey all the rules and requirements of 
>>>>>>> C. Optimisations don't change the meaning of correct code - they 
>>>>>>> only have an effect on the results of your code if you have 
>>>>>>> written incorrect code.  I don't know about you, but my aim in 
>>>>>>> development is to write /correct/ code. If disabling 
>>>>>>> optimisations helped in some way, it would be due to bugs and luck.
>>>>>>
>>>>>> To me disabling optimisations does one slightly useful thing 
>>>>>> (compiles a little quicker) and one really useful one. It makes 
>>>>>> the interactive debugger work. Optimised code confuses the 
>>>>>> debugger, especially when it does things like reorder code, unroll 
>>>>>> loops, or merge equivalent functions.
>>>>>>
>>>>>> Of course I then test with the optimised version.
>>>>>>
>>>>>> Andy
>>>>>
>>>>>
>>>>> I understand your viewpoint and motivation.  But my own experience 
>>>>> is mostly different.
>>>>>
>>>>> First, to get it out of the way, there's the speed of compilation. 
>>>>> While heavy optimisation (-O3) can take noticeably longer, I never 
>>>>> see -O0 as being in any noticeable way faster for compilation than 
>>>>> -O1 or even -O2.
>>>>
>>>> Absolute time or relative?
>>>
>>> Both.
>>>
>>>> For me, optimised options with gcc always take longer:
>>>
>>> Of course.  But I said it was not noticeable - it does not make 
>>> enough difference in speed for it to be worth choosing.
>>>
>>>>
>>>>   C:\c>tm gcc bignum.c -shared -s -obignum.dll        # from cold
>>>>   TM: 3.85
>>>
>>> Cold build times are irrelevant to development - when you are working 
>>> on a project, all the source files and all your compiler files are in 
>>> the PC's cache.
>>>
>>>
>>>>
>>>>   C:\c>tm gcc bignum.c -shared -s -obignum.dll
>>>>   TM: 0.31
>>>>
>>>>   C:\c>tm gcc bignum.c -shared -s -obignum.dll -O2
>>>>   TM: 0.83
>>>>
>>>>   C:\c>tm gcc bignum.c -shared -s -obignum.dll -O3
>>>>   TM: 0.93
>>>>
>>>>   C:\c>dir bignum.dll
>>>>   21/06/2024  11:14            35,840 bignum.dll
>>>
>>> Any build time under a second is as good as instant.
>>>
>>> I tested on a real project, not a single file.  It has 158 C files 
>>> and about 220 header files.  And I ran it on my old PC, without any 
>>> "tricks" that you dislike so much, doing full clean re-builds.  The 
>>> files are actually all compiled twice, building two variants of the 
>>> binary.
>>>
>>> With -O2, it took 34.3 seconds to build.  With -O1, it took 33.4 
>>> seconds.  With -O0, it took 30.8 seconds.
>>>
>>> So that is a 15% difference for full builds.  In practice, of course, 
>>> full rebuilds are rarely needed, and most builds after changes to the 
>>> source are within a second or so.
>>
>> Then there's something very peculiar about your codebase.
> 
> 
> 
> In my experience, programs don't usually consist of a single C file. And 
> if they do, build time is rarely long enough to worry anyone.
> 
> I think, from the history of discussions in this group, that it is more 
> likely that your codebases are the peculiar ones.


I specifically excluded any of my own. I tried a variety of distinct 
projects, all sharing the same characteristics: that -O3 generally 
doubled build time, sometimes a bit less, often a lot more.

But you seem remarkably unbothered that in your code-base, the 
difference is only 15% [for -O2]. I'd be quite curious.

If that really was typical, and I was in charge of gcc, I'd seriously 
consider whether to bother with the -O0 and -O1 levels.

However the following timings to build TCC/lUA are typical of my 
experience of gcc over 10-20 years:

    (tcc  0.10)
    -O0   2.84 seconds to build tcc.exe
    -O1   5.70
    -O2  10.78
    -O3  13.21

    (tcc  0.25)
    -O0   7.74 seconds to build lua.exe
    -O1  10.63
    -O2  14.95
    -O3  18.24

I've shown the timings from building with Tcc to give some perspective. 
The proportional difference between -O3 and -O0 is indeed small compared 
with that between -O0 and tcc!


> However, it is certainly fair to say that codebases vary a lot, as do 
> build procedures.
> 
>>
>> Either there's disproportionate percentage of declarations compared to 
>> executable code (like my tests with headers).
> 
> No.
> 
>>
>> Or a big chunk of the source either contains lots of redundant code, 
> 
> No.
> 
>> or generates such code, or maybe conditional code, 
> 
> There's a bit, but not much.
> 
>> that is eliminated before it gets to the optimising stages.
> 
> 
> 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.

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).

>  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 
========== REMAINDER OF ARTICLE TRUNCATED ==========