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: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 24 Nov 2024 01:36:44 +0000
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <vhtvvc$1ukc7$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <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> <WGl%O.42744$LlWc.33050@fx42.iad>
 <vhkr9e$4bje$1@dont-email.me> <vhptmn$3mlgf$1@paganini.bofh.team>
 <vhq6b4$17hkq$1@dont-email.me> <vhqm3l$3ntp7$1@paganini.bofh.team>
 <vhso61$1o2of$1@dont-email.me> <vhtrns$71ic$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 24 Nov 2024 02:36:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ce2114238f6dc927920bdb19bad491fa";
	logging-data="2052487"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/JcZUS+fFdp/Y4L5DHyVGZ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Twfk3vSKgQAkTztoxECxhD8nh34=
Content-Language: en-GB
In-Reply-To: <vhtrns$71ic$1@paganini.bofh.team>
Bytes: 5393

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.