Path: ...!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: Tue, 25 Jun 2024 10:19:25 +0200
Organization: A noiseless patient Spider
Lines: 181
Message-ID: <v5duid$1fid4$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> <v5cnm9$14dri$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 25 Jun 2024 10:19:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9cf53d04b66d1800440e1f149c520af4";
	logging-data="1558948"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19BgScYtD4iNSVQ28/R3XhGNhLwg2DVY7M="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:8XAUkpfWAyDDOlIzsAaY7P3SWhk=
In-Reply-To: <v5cnm9$14dri$1@dont-email.me>
Content-Language: en-GB
Bytes: 9807

On 24/06/2024 23:15, bart wrote:
> 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:
>>>

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

How many times does this need repeated?  I want my builds to be /fast 
enough/.  Fast enough is all that anyone needs.  As long as a task is 
fast enough not to hinder other tasks, doing it any faster gives no 
benefits.  I care that my builds are fast enough - I don't care if they 
are faster.  (I'm quite happy if they are faster, of course.)

If my gcc builds took too long, becoming a nuisance to my workflow, then 
that would be an issue.  Maybe I'd get a faster computer.  Maybe I'd 
change the workflow - perhaps doing more compiles without linking, or 
separating compilation and static error checking.  Maybe I'd start using 
pre-compiled headers, or modules in C++.  The one thing I will /not/ do 
is compromise on the quality of the tools I use or cut down on the 
features I rely on.

> It's perfectly 
> alright for 90% of the time to build a project to be spent executing 
> auto-conf scripts.

Please point me to references of Usenet posts where I have said anything 
remotely like that.  In particular, show me where I have said I use 
autoconf for my projects.

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

Linking can take a significant amount of time.  In particular, C++ 
linking is usually /far/ more work than C linking.  So for big C++ 
projects the build time - including compiling and linking - can often be 
a lot slower than people like.


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

No, your "car" is, at best, a home-made go-cart.  It can go really fast 
down steep slopes with a disregard to safety, and that seems to be all 
you want from it.  That's fine for you, since that's all you want to do.

> 
> Let's go back a few weeks 

Let's not.

>> 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?

For my work?  No.  For /some/ other people's work?  Yes.

Perhaps it would do you some good to raise your eyes from your little 
projects with your highly unusual and restricted style of C, and think 
about the rest of the world.  Consider, just for a moment, that when the 
rest of the world sees things differently from you, it is not because 
/you/ are right and everyone else is crazy.  Imagine the possibility 
that other people have different needs than you.

Compile times /are/ long for some code.  Build times /are/ big for some 
projects.

Compile times for almost all /C/ code are short, even with gcc and heavy 
optimisation.  Build times for /C/ projects are usually fairly short. 
Build times for /my/ /C/ projects are easily fast enough not to be of 
any concern to me.

Compile times for big /C++/ files can often be long.  Build times for 
huge /C++/ projects are often a significant inconvenience.  The /C++/ 
powers that be are dealing with that (more slowly than many would like) 
with C++ modules in the language, and improving tools such as by making 
new linkers designed from the outset with C++'s needs in mind, and with 
as much parallel processing as practically possible.

At no point in all this does anyone care in the slightest about the 
speed of your little toys or of the cute little tcc.  tcc might be ideal 
for the half-dozen people in the world who think C scripts are a good 
idea, and it had its place in a time when "live Linux" systems were 
booted from floppies, but that's about it.



> 
>  > 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.
> 
> This is the reason I stopped being a Java developer and embraced JS. 
> Even the 1-3 minutes of build time was a big hit for me because it was 
> just enough time for me to get distracted by something else and then the 
> next thing you know, you have wasted 30 mins.
> ------------------
> 
> Maybe you should tell these guys how it's done!

It seems they have already figured it out.  If their build times are too 
long for convenience, do something about it.  Options include buying 
faster build machines, distributing builds across existing workstations 
(since most machines are 95%+ idle), changing languages, improving the 
way the builds are done, using more dynamic linking (fixing whatever 
their technical hinder was), using partial links, changing tools, 
changing languages.

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