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 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: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> 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: Bytes: 5393 On 24/11/2024 00:24, Waldek Hebisch wrote: > Bart 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.