Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Wed, 20 Nov 2024 17:15:20 +0100
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <vhl1up$5vdg$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 20 Nov 2024 17:15:22 +0100 (CET)
Injection-Info: dont-email.me; posting-host="5ce3813f242e5ddf194d2a4a39226dfb";
	logging-data="196016"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+4PadpwcDXRfk0S6EN6HmeTAVvaGCxmbI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:G2ZUEK1AHCXw4iLMDaz0/6kTyaI=
In-Reply-To: <vhje8l$2412p$1@dont-email.me>
Content-Language: en-GB
Bytes: 5935

On 20/11/2024 02:33, Bart wrote:
> On 19/11/2024 23:41, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
> 

>> I do not think I will use your system language.  And for C compiler
>> at least currently it does not make big difference to me if your
>> compiler can do 1Mloc or 5Mloc on my machine, both are "pretty fast".
>> What matters more is support of debugging output, supporting
>> targets that I need (like ARM or Risc-V), good diagnostics
>> and optimization.
> 
> 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.  Let's look at the main ones:

1. If it is a run-to-finish program, it will finish faster, and you have 
less time waiting for it.  A compiler will fall into this category.

2. If it is a run-continuously (or run often) program, it will use a 
smaller proportion of the computer's resources, less electricity, less 
heat generated, less fan noise, etc.  That covers things like your email 
client, or your OS - things running all the time.

3. If it is a dedicated embedded system, faster programs can mean 
smaller, cheaper, and lower power processors or microcontrollers for the 
given task.  That applies to the countless embedded systems that 
surround us (far outweighing the number of "normal" computers), and the 
devices I make.

4. For some programs, running faster means you can have higher quality 
in a similar time-frame.  That applies to things like simulators, static 
analysers, automatic test coverage setups, and of course games.

5. For interactive programs, running faster makes them nicer to use.

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.


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.  And for everyone other than developers, it 
is of no concern at all.

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.  (If not, then you should most 
likely have used a higher level language instead of a compiled low-level 
language.)  So compile time is relatively speaking of much lower 
priority than the speed of the result.

I think it's clear that everyone prefers faster rather than slower.  But 
generally, people want /better/ rather than just faster.  One of the 
factors of "better" for compilers is that the resulting executable runs 
faster, and that is certainly worth a very significant cost in compile time.


And as usual, you miss out the fact that toy compilers - like yours, or 
TinyC - miss all the other features developers want from their tools.  I 
want debugging information, static error checking, good diagnostics, 
support for modern language versions (that's primarily C++ rather than 
C), useful extensions, compact code, correct code generation, and most 
importantly of all, support for the target devices I want.  I wouldn't 
care if your compiler can run at a billion lines per second and gcc took 
an hour to compile - I still wouldn't be interested in your compiler 
because it does not generate code for the devices I use.  Even if it 
did, it would be useless to me, because I can trust the code gcc 
generates and I cannot trust the code your tool generates.  And even if 
your tool did everything else I need, and you could convince me that it 
is something a professional could rely on, I'd still use gcc for the 
better quality generated code, because that translates to money saved 
for my customers.

> 
> BTW why don't you use a cross-compiler? That's what David Brown would say.
> 

That is almost certainly what he normally does.  It can still be fun to 
play around with things like TinyC, even if it is of no practical use 
for the real development.