Re: Baby X is bor nagain

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.
Options do /not/ include disabling compiler optimisation or changing to tcc.

>
If gcc was ten times slower than it is, it might get annoying sometimes, and I'd then get a faster computer.

 The wrong approach.
 

The professional approach.  If each build is wasting $75 (figures from your forum post), it doesn't take many of them to cover the cost of a faster machine.
Of course there are many other ways to speed up builds.  I know of several ways to speed up my own builds, if I felt the need - but I don't need to because they are more than fast enough already.