Re: else ladders practice

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.