Path: ...!weretis.net!feeder8.news.weretis.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 24 Nov 2024 00:24:30 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vhtrns$71ic$1@paganini.bofh.team>
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>
Injection-Date: Sun, 24 Nov 2024 00:24:30 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="230988"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 6165
Lines: 109

Bart <bc@freeuk.com> wrote:
> On 22/11/2024 19:29, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
> 
>> clang -O3 -march=native       126112us
>> clang -O3                     222136us
>> clang -O                      225855us
>> gcc -O3 -march=native          82809us
>> gcc -O3                       114365us
>> gcc -O                        287786us
>> tcc                           757347us
> 
> You've omitted -O0 for gcc and clang. That timing probably won't be too 
> far from tcc, but compilation time for larger programs will be 
> significantly longer (eg. 10 times or more).
> 
> The trade-off then is not worth it unless you are running gcc for other 
> reasons (eg. for deeper analysis, or to compile less portable code that 
> has only been tested on or written for gcc/clang; or just an irrational 
> hatred of simple tools).

I have tried to use 'tcc' for one on the project that I mentioned
before.  It appears to work, real time for build is essentially
the same (actually some fraction of second longer, but that is
withing measurement noise), CPU time _may_ be shorter by 1.6%.
This confirms my earlier estimates that for that project C
compile time has very small impact on overall compile time
(most compilations are not C compilation).  In this project
I use '-O' which is likely to give better runtime speed
(I do not bother with '-O2' or '-O3').  Also, I use '-O' for
better diagnostics.

I a second project, '-O2' is used for image processing library,
this takes significant time to compile, but this library is
performance critical code.
 
>> There is some irregularity in timings, but this shows that
>> factor of order 9 is possible.
> 
> That's an extreme case, for one small program with one obvious 
> bottleneck where it spends 99% of its time, and with little use of 
> memory either.
> 
> For simply written programs, the difference is more like 2:1. For more 
> complicated C code that makes much use of macros that can expand to lots 
> of nested function calls, it might be 4:1, since it might rely on 
> optimisation to inline some of those calls.
> 
> Again, that would be code written to take advantage of specific compilers.
> 
> But that is still computationally intensive code working on small 
> amounts of memory.
> 
> I have a text editor written in my scripting language. I can translate 
> its interpreter to C and compile with both gcc-O3 and tcc.
> 
> Then, yes, you will notice twice as much latency with the tcc 
> interpreter compared with gcc-O3, when doing things like 
> deleting/inserting lines at the beginning of a 1000000-line text file.
> 
> But typically, the text files will be 1000 times smaller; you will 
> notice no difference at all.
> 
> 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.

And of course, there is a question why program with runtime that
does not matter is written in a low level language?  Experience
shows that using higher level language is easier, and higher
level language compiled to bytecode can give significantly smaler
code than gcc -Os from low-level code.  Several programs for
early micros used bytecode because this was the only way to
fit the program into available memory.

> Here are some timings for that interpreter, when used to run a script to 
> compute fib(38) the long way:
> 
> Interp   Built with       Timing
> 
> qc       tcc              9.0 secs    (qc is C transpiled version)
> qq       mm               5.0         (-fn; qq is original M version) 
> 
> qc       gcc-O3           4.0
> qq       mm               1.2         (-asm)
> 
> (My interpreter doesn't bother with faster switch-based or computed-goto 
> based dispatchers. The choice is between a slower function-table-based 
> one, and an accelerated threaded-code version using inline ASM.
> 
> These are selected with -fn/-asm options. The -asm version is not JIT; 
> it is still interpreting a bytecode at a time).
> 
> 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.

-- 
                              Waldek Hebisch