Re: else ladders practice

On 24/11/2024 00:24, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

I'm not saying no optimisation is needed, ever, I'm saying that the NEED
for optimisation is far smaller than most people seem to think.

 There is also question of disc space.  'tcc' compiled by itself is
404733 bytes (code + data) (0.024s compile time), by gcc (default) is
340950 (0.601s compile time), by gcc -O is 271229 (1.662s compile
time), by gcc -Os is 228855 (2.470s compile time), by gcc -O2
is 323392 (3.364s compile time), gcc -O3 is 407952 (4.627s compile
time).  As you can see gcc -Os can save quite a bit of disc space
for still moderate compile time.

I thought David Brown said that disk space is irrelevant? Anyway this is the exact copy of what I tried just now, compiling a 5-line hello.c program. I hadn't used these compilers since earlier today:
   c:\c>tm gcc hello.c
   TM: 5.80
   c:\c>tm tcc hello.c
   TM: 0.19
   c:\c>tm gcc hello.c
   TM: 0.19
   c:\c>tm tcc hello.c
   TM: 0.03
 From cold, gcc took nearly 6 seconds (if you've been used to instant feedback all day, it can feel like an age). tcc took 0.2 seconds.
Doing it a second time, now gcc takes 0.2 seconds, and tcc takes 0.03 seconds! (It can't get much faster on Windows.)
gcc is just a lumbering giant, a 870MB installation, while tcc is 2.5MB. As for sizes:
   c:\c>dir hello.exe
   24/11/2024  00:44             2,048 hello.exe
   c:\c>dir a.exe
   24/11/2024  00:44            91,635 a.exe         (48K with -s)
(At least that's one good thing of gcc writing out that weird a.exe each time; I can compare both exes!)
As for mine (however it's possible I used it more recently):
   c:\c>tm cc hello
   Compiling hello.c to hello.exe
   TM: 0.04
   c:\c>dir hello.exe
   24/11/2024  00:52             2,560 hello.exe
My installation is 0.3MB (excluding windows.h which is 0.6MB). Being self-contained, I can trivally apply UPX compression to get a 0.1MB compiler, which can be easily copied to a memory stick or bundled in one of my apps. However compiling hello.c now takes 0.05 seconds.
(I don't use UPX because my apps are already tiny; it's just to marvel at how much redundancy they still contain, and how much tinier they could be.)
I know none of this will cut any ice; for various reasons you don't want to use tcc.
One of them being that your build process involves N slow stages so speeding up just one makes little difference.
This however is very similar to my argument about optimisation; a running app consists of lots of parts which take up execution time, not all of which can be speeded up by a factor of 9. The net benefit will be a lot less, just like your reduced build time.

And of course, there is a question why program with runtime that
does not matter is written in a low level language?

I mean it doesn't matter if it's half the speed. It might matter if it was 40 times slower.
There's quite a gulf between even unoptimised native code and even a fast dynamic language interpreter.
People seem to think that the only choices are the fastest possible C code at one end, and slow CPython at the other:
   gcc/O3-tcc-----------------------------------------------------CPython
On this scale, gcc/O3 code and tcc code are practically the same!

So the fastest version here doesn't use compiler optimisation, and it's
3 times the speed of gcc-O3. My unoptimised HLL code is also only 25%
slower than gcc-O3.

 Well, most folks would "not bother" with inline ASM and instead use
fastest wersion that C can give.  Which likely would involve
gcc -O2 or gcc -O3.

But in this case, it works by giving my a product that, even using a non-optimising compiler, makes an application faster than using gcc-O3.