Re: else ladders practice

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.

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

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.

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.

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.
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. Or even splitting things up into tiny modules. 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!

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.

Sure. But then I'm sure you're aware that most scripting languages include a compilation stage where source code might be translated to bytecode.
I guess you're OK with that being as fast as possible so that there is no noticeable delay. But I also guess that all those features go out the window, yet people don't seem to care in that case.
My whole-program compilers (even my C one now) can run programs from source code just a like a scripting language.
So a fast, mechanical compiler than does little checking is good in one case, but not in another (specifically, anything created by Bart).

  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.

Suppose I had a large C source file, mechanically generated via a compiler from another language so that it was fully verified.
It took a fraction of a second to generate it, all that's needed is a mechanical translation to native code. In that case you can keep your compiler that takes one hour to do analyses I don't need; I'll take the million line per second one. (A billion lines is not viable, one million is.)

  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.

Where have I said you should use my compiler? I'm simply making a case for the existence of very fast, baseline tools that do the minimum necessary with as little effort or footprint as necessary.
Here's an interesting test: I took sql.c (a 250Kloc sqlite3 test program), and compiled it first to NASM-compatible assembly, and then to my own assembly code.
I compiled the latter with my assembler and it took 1/6th for a second (for some 0.3M lines).
How long do you think NASM took?  It was nearly 8 minutes. Or a blazing 5 minutes if you used -O0 (do only one pass).
No doubt you will argue that NASM is superior to my product, although I'm not sure how much deep analysis you can do of assembly code. And you will castigate me for giving it over-large inputs. However that is the task that needs to be done here.
It clearly has a bug, but if I hadn't mentioned it, I'd like to have known how sycophantic you would have been towards that product just to be able to belittle mine.
The NASM bug only starts to become obvious above 20Kloc or so. I wonder how many more subtle bugs exist in big products that result in significantly slower performance, but are not picked up because people like you /don't care/. You will just buy a faster machine or chop your application up into even smaller bits.

 

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