Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Thu, 21 Nov 2024 14:00:04 +0100
Organization: A noiseless patient Spider
Lines: 163
Message-ID: <vhnasl$l8h5$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me>
 <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me>
 <vgd3ro$2pvl4$1@paganini.bofh.team> <vgdc4q$1ikja$1@dont-email.me>
 <vgdt36$2r682$2@paganini.bofh.team> <vge8un$1o57r$3@dont-email.me>
 <vgpi5h$6s5t$1@paganini.bofh.team> <vgtsli$1690f$1@dont-email.me>
 <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me>
 <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team>
 <vhje8l$2412p$1@dont-email.me> <vhl1up$5vdg$1@dont-email.me>
 <vhlg53$8lff$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 21 Nov 2024 14:00:06 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b6ed00619860c2c2b961b44de806e1e6";
	logging-data="696869"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ypQ9+S4M06P5eVDZXGEV16CNn/cDH91w="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:ICVfg3dS9/Y1E05hAO1ACO4UyP8=
In-Reply-To: <vhlg53$8lff$1@dont-email.me>
Content-Language: en-GB
Bytes: 8636

On 20/11/2024 21:17, Bart wrote:
> On 20/11/2024 16:15, David Brown wrote:
>> On 20/11/2024 02:33, Bart wrote:
> 
>>> It's funny how nobody seems to care about the speed of compilers 
>>> (which can vary by 100:1), but for the generated programs, the 2:1 
>>> speedup you might get by optimising it is vital!
>>
>> To understand this, you need to understand the benefits of a program 
>> running quickly.
> 
> As I said, people are preoccupied with that for programs in general. But 
> when it comes to compilers, it doesn't apply! Clearly, you are implying 
> that those benefits don't matter when the program is a compiler.

No - you are still stuck with your preconceived ideas, rather than ever 
bothering reading and thinking.

As I have said many times, people will always be happier if their 
compiler runs faster - as long as that does not happen at the cost of 
the functionality and features.

Thus I expect that whoever compiles the gcc binaries that I use 
(occasionally that is myself, but like every other programmer I usually 
use pre-built compilers), uses a good compiler with solid optimisation 
enabled when building the compiler.  And I expect that the gcc (and 
clang/llvm) developers put effort into making their tools fast - but 
that they prioritise correctness first, then features, and only then 
look at the speed of the tools and their memory usage.  (And I don't 
expect disk space to be of the remotest concern to them.)


> 
>>   Let's look at the main ones:
> 
> <snip>
> 
> OK. I guess you missed the bits here and in another post, where I 
> suggested that enabling optimisation is fine for production builds.
> 

I saw it.  But maybe you missed the bit when the discussion was about 
serious software developers.  Waldek explained, and I've covered it 
countless times in the past, but since you didn't pay attention then, 
there is little point in repeating it now.

> For the routines ones that I do 100s of times a day, where test runs are 
> generally very short, then I don't want to hang about waiting for a 
> compiler that is taking 30 times longer than necessary for no good reason.
> 

Your development process sounds bad in so many ways it is hard to know 
where to start.  I think perhaps the foundation is that you taught 
yourself a bit of programming in the 1970's, convinced yourself at the 
time that you were better at software development than anyone else, and 
have been stuck in that mode and the same methodology for the last 50 
years without ever considering that you could learn something new from 
other people.

> 
>> There is usually a point where a program is "fast enough" - going 
>> faster makes no difference.  No one is ever going to care if a 
>> compilation takes 1 second or 0.1 seconds, for example.
> 
> If you look at all the interactions people have with technology, with 
> GUI apps, even with mechanical things, a 1 second latency is generally 
> disastrous.
> 
> A one-second delay between pressing a key and seeing a character appear 
> on a display or any other feedback, would drive most people up to wall. 
> But 0.1 is perfectly fine.
> 

As I said, no one is ever going to care if a compilation takes 1 second 
or 0.1 seconds.

> 
>> It doesn't take much thought to realise that for most developers, the 
>> speed of their compiler is not actually a major concern in comparison 
>> to the speed of other programs.
> 
> Most developers are stuck with what there is. Naturally they will make 
> the best of it. Usually by finding 100 ways or 100 reasons to avoid 
> running the compiler.
> 

So your advice is that developers should be stuck with what they have - 
the imaginary compilers from your nightmares that take hours to run - 
and that they should make a point of always running them as often as 
possible?  And presumably you also advise doing so on a bargain basement 
single-core computer from at least 15 years ago?

People who do software development seriously are like anyone else who 
does something seriously - they want the best tools for the job, within 
budget.  And if they are being paid for the task, their employer will 
expect efficiency in return for the budget.

Which do you think an employer (or amateur programmer) would prefer?

a) A compiler that runs in 0.1 seconds with little static checking
b) A compiler that runs in 10 seconds but spots errors saving 6 hours 
debugging time


Developers don't want to waste time unnecessarily.  Good build tools 
means you get all the benefits of good compilers, without wasting time 
re-doing the same compilations when nothing has changed.

I can't understand why you think that's a bad thing - what is the point 
of re-doing a build step when nothing has changed?  And a build tool 
file is also the place to hold the details of how to do the build - 
compiler versions, flags, list of sources, varieties of output files, 
additional pre- or post-processing actions, and so on.  I couldn't 
imagine working with anything beyond a "hello, world" without a build tool.

>> While writing code, and testing and debugging it, a given build might 
>> only be run a few times, and compile speed is a bit more relevant. 
>> Generally, however, most programs are run far more often, and for far 
>> longer, than their compilation time.
> 
> Developing code is the critical bit.
> 

Yes.

I might spend an hour or two writing code (including planing, 
organising, reading references, etc.) and then 5 seconds building it. 
Then there might be anything from a few minutes to a few hours testing 
or debugging.  How could that process be improved by a faster compile? 
Even for the most intense code-compile-debug cycles, building rarely 
takes longer than stretching my fingers or taking a mouthful of coffee.

But using a good compiler saves a substantial amount of developer time 
because I can write better code with a better structure, I can rely on 
the optimisation it does (instead of "hand-optimising" code to get the 
efficiency I need), and good static checking and good diagnostic 
messages help me fix mistakes before test and debug cycles.

> Even when a test run takes a bit longer as you need to set things up, 
> when you do need to change something and run it again, you don't want 
> any pointless delay.
> 
> Neither do you want to waste /your/ time pandering to a compiler's 
> slowness by writing makefiles and defining dependencies. 

That is not what "make" is for.  Speed is a convenient by-product of 
good project management and build tools.

> Or even 
> splitting things up into tiny modules.

Speed is not the reason people write modular, structured code.

> I don't want to care about that 
> at all. Here's my bunch of source files, just build the damn thing, and 
> do it now!
> 

You apparently don't want to care about anything much.


<snip the rest to save time>