Path: ...!weretis.net!feeder8.news.weretis.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: Mon, 24 Jun 2024 22:15:53 +0100
Organization: A noiseless patient Spider
Lines: 202
Message-ID: <v5cnm9$14dri$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>
 <20240624160941.0000646a@yahoo.com> <v5bu5r$va3a$1@dont-email.me>
 <v5c275$vq9k$1@dont-email.me> <v5c6bf$10sr7$1@dont-email.me>
 <v5c9jk$1159j$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 23:15:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b9ae78d5a8a2c8822d3975b378ef6e69";
	logging-data="1193842"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pri5BK9sutiGE6U2Ig2u1"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2hiNgYyMyeDjtuivyDlyfpMycJA=
In-Reply-To: <v5c9jk$1159j$1@dont-email.me>
Content-Language: en-GB
Bytes: 10936

On 24/06/2024 18:15, David Brown wrote:
> On 24/06/2024 18:19, bart wrote:
>> On 24/06/2024 16:09, David Brown wrote:
>>> On 24/06/2024 16:00, bart wrote:
>>
>>>> However, is there any way of isolating the compilation time (turning 
>>>> .c files into either or .o files) from 'make' the linker?
>>>
>>> Why would anyone want to do that?  At times, it can be useful to do 
>>> partial builds, but compilation alone is not particularly useful.
>>
>> It is useful when you are trying to establish the true cost of -O2 
>> compared to -O0.
> 
> And the relevance of that is... what?  Absolutely nothing.  We've 
> already established that for some files, the difference is below the 
> measurement threshold and for some (such as Scott's C++ example) it is 
> massive.
> 
> But just to please you, and not because it has any bearing on reality, I 
> isolated a couple of C files from my code, removed the stuff that is 
> specific to the target, and compiled with native gcc -O0 and -O2.
> 
> For one file (the largest C file in the project), "gcc -O0" took 0.085 
> seconds.  "gcc -O2" took 0.134 seconds.  Yes, optimising was slow - but 
> the time was negligible.  For the other file, both compiles were 0.025 
> seconds - too fast to be distinguishable from noise.

On my Windows machine, gcc -O0 took 0.20 seconds to build the 4-line 
hello.c. As measured with clock() when executing 'system("gcc hello.c")'.

On WSL using 'time', it took 0.146 seconds 'real' time, 0.007 seconds 
'user' time, and 0.051 seconds 'sys' time.

I'm not sure what these mean, or which one, or which combination, you 
used to present your figures.

However, if someone is waiting for it to finish, it is the elapsed time 
that is relevant, since that is how long they have to wait!

> Why do you think that is an appropriate way to guess the size of the 
> project?  Michael does embedded development - that's likely to be a 
> pretty big project with a lot of files.  This is not PC compilation 
> where a "Hello, world" file can reach that size if statically linked.


> No one cares about your figures.  No one, except you, cares about /my/ 
> figures.  Sometimes people care about the build speed of /their/ code, 
> using /their/ choice of compiler and /their/ choice of options on 
> /their/ computers.  Do you /really/ not understand that the timings you 
> get are utterly pointless to everyone else?


Obviously /you/ don't care about fast build systems. It's perfectly 
alright for 90% of the time to build a project to be spent executing 
auto-conf scripts.

Some people also cared enough about linkers to develop a new generation 
of linker (maybe 'gold', maybe something even newer) that is supposed to 
be 5 times the speed of 'ld'.

Who told them that linking was a bottleneck? Obviously not you! (And not 
me either; linking is just a nuisance, but I hadn't noticed it being a 
drag on the stuff I did.)


>>>
>>> No one denies that "gcc -O0" is faster than "gcc -O3" for individual 
>>> compiles, and that the percentage difference will vary and sometimes 
>>> be large.

>> Yes, gcc ticks all the boxes. Except the last.
> 
> No, it does not tick all the boxes.  The toolchains I use tick most of 
> them (including all the ones that I see as hard requirements), and do 
> better than any alternatives, but they are not perfect.  They do, 
> however, happily pass the last one.  I have yet to find a C compiler 
> that was not fast enough for my needs.
> 
>> For me it would be like driving my car at walking pace all over town, 
>> even though most of my time would be spent at various stopping places.
> 
> You still don't understand.  You are telling people how fantastically 
> fast your car is, without realising it is just a remote-controlled toy 
> car.  Nobody cars if your toy runs faster than a real tool - people will 
> still choose the real tool.  And the real tools run fast enough for real 
> developers doing real work.

You're wrong. My 'car' would do the equivalent job of driving around 
town. Unless someone /wanted/ a vehicle that was more like a 40-tonne truck.

Let's go back a few weeks to when the topic was translating millions of 
lines like this:

   unsigned char data[N] = {
          1,
          2,
          ....
   };

This is not very demanding of a compiler; there is little static 
analysis to do, no advanced code generation, not even a way of 
minimising size: it has to occupy at least N bytes in the output.

So would you really demand gcc be used here, because an object file 
produced by any lesser compiler woudldn't be up to scratch? gcc will of 
course take 20 times longer to do the job. (And 200 times longer than my 
language takes to directly embed the original binary.)

Would you allow the use of a dedicated utility program which turns such 
text into a binary file? It would rather churlish to say yes to this, 
and no to the use of Tiny C which could probably do the job too.

How about assemblers, which aren't too challenging either; would you be 
snobbish and patronising about those too?

I see basic compilation, naively translating source code to native code, 
as an equally low level, mechanical task. It should always be available 
as something to fall back on.

>>> I use gcc - specifically toolchains built and released by ARM - 
>>> because that is the tool that I rate highest on these factors.  If 
>>> there were a similar featured clang toolchain I'd look closely at 
>>> that too.  And over the years I have used many toolchains for many 
>>> targets, some costing multiple $K for the license.
>>>
>>> Of course everyone likes faster compiles, all other things being 
>>> equal. But the other things are /not/ equal when comparing real-world 
>>> development tools with the likes of tcc or your little compiler.  The 
>>> idea that anyone should reasonably expect to get paid for wasting 
>>> customer time and money with those is just laughable.
>>
>> That's a good point. How much money has been wasted in paying 
>> programmers by the hour to twiddle their thumbs while waiting for a 
>> rebuild?
> 
> None that I know of.  Your worries about compiler speed are imaginary or 
> self-imposed.

So cartoons like https://xkcd.com/303/ have no basis in fact? It's just 
made up?

 > You /do/ realise that the only person that "suffers" from slow gcc times
 > is /you/ ?

Forums abound with horror stories. Here are quotes from just one thread:

------------------
Well a build used to take 6 or 7 minutes, and that's a long time for my 
little attention span. I'd always get distracted waiting for builds and 
waste even more time.

In short, if a developer is waiting on a build to run for one hour and 
doing nothing in that timeframe, the business is still spending $75 on 
average for that developer’s time—and potentially losing out on time 
that developer could be focusing on building more code.

I worked on a system where only linking the binary took 40-50 minutes. 
For some technical reasons there was no dynamic linking - only static - 
so you had to go through that delay for the slightest change.

This is why my computer and build server have an 11900k. Builds went 
from 45 minutes to 15.

========== REMAINDER OF ARTICLE TRUNCATED ==========