Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Fri, 28 Jun 2024 11:05:39 +0100
Organization: A noiseless patient Spider
Lines: 141
Message-ID: <v5m1ti$39qob$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v53i4s$33k73$2@dont-email.me>
 <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me>
 <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com>
 <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com>
 <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad>
 <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad>
 <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad>
 <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad>
 <v5empd$1jndv$2@dont-email.me> <v5eph4$1k6a9$1@dont-email.me>
 <87ed8jnbmf.fsf@bsb.me.uk> <v5jhls$2m7np$1@dont-email.me>
 <v5jm32$2nqvp$1@dont-email.me> <v5k3v2$2qllm$1@dont-email.me>
 <v5kfst$2svt3$1@dont-email.me> <v5kmlm$2u918$1@dont-email.me>
 <v5lfq9$35vli$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Jun 2024 12:05:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e7f1b554b99247d34cf39342a3f15f64";
	logging-data="3468043"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+0dMdxLD80FFfaumZg/287"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JptscbT/0e4itw+gXF92+R+Ni6c=
Content-Language: en-GB
In-Reply-To: <v5lfq9$35vli$1@dont-email.me>
Bytes: 7972

On 28/06/2024 05:56, David Brown wrote:
> On 27/06/2024 23:47, bart wrote:
>> On 27/06/2024 20:51, David Brown wrote:
>>> On 27/06/2024 18:28, bart wrote:
>>>> On 27/06/2024 13:31, David Brown wrote:
>>>>> On 27/06/2024 13:16, bart wrote:
>>>>
>>>
> 
>>> No one doubts that gcc is slower than tcc.  That is primarily because 
>>> it does vastly more, and is a vastly more useful tool.  And for most 
>>> C compiles, gcc (even gcc -O2) is more than fast enough.
>>
>> And for most of /my/ compiles, the code produced by gcc-O0 is fast 
>> enough. It also about the same speed as code produced by one of my 
>> compilers.
>>
> 
> With most of your compiles, is "gcc -O2" too slow to compile?  If not, 
> then why would you or anyone else actively /choose/ to have a poorer 
> quality output and poorer quality warnings?  I appreciate that fast 
> enough output is fast enough (just as I say the same for compilation 
> speed) - but choosing a slower output when a faster one is just as easy 
> makes little sense.  The only reason I can think of why "gcc -O2 -Wall" 
> is not the starting point for compiler flags is because you write poor C 
> code and don't want your compiler to tell you so!

I might very occasionally use gcc -O2/-O3 when I want a fast product, 
(this is mostly with generated C) most often when I'm benchmarking and 
what to report a higher lines/second figure or some such measure. Since 
that would be a fairer comparison with other products which almost 
certainly will be using an optimised build.

But usually I never bother. The 40% boost that gcc-O3 gives me, makes 
most runtimes of my language tools 10-20ms faster (so 0.07 seconds 
instead of 0.09 seconds; I can live with that).

The cost of the speedup is not just having to hang about for gcc-O3 
(it's like doing 80mph on the M6 and having to stop for a red light). 
It's keeping my non-C source code conservative - avoiding features that 
are troublesome to transpile to C.

(One feature is a special looping switch that I implemented as a fast 
computed-goto. It is transpiled into a regular C switch, but it means 
gcc-O3 can't generate code faster than mine. Only if I were to use C 
extensions.)

My other language product that could be speeded up is a bytecode 
interpreter, which has two dispatch modes. One HLL-only dispatch mode 
can have that 40-50% speed-up via C and gcc-O3.

But I normally use the ASM-accelerated mode, which is about 150-200% 
faster even than the interpreter using transpiled C + gcc-O3.

Note that all these examples benefit from whole-program optimisation of 
C. If written directly in C, while programs like interpreters can 
benefit from all sorts of tricks like inlining everything, they would 
lose that whole-program analysis.



>> So I tend to use it when I want the extra speed, or other compilers 
>> don't work, or when a particular app only builds with that compiler.
>>
>> Otherwise the extra overheads are not worth the bother.
>>
>>
>>
>>> And it is free, and easily available on common systems.  Therefore 
>>> there is no benefit to using tcc except in very niche cases.
>>
>> And my argument would be the opposite. The use of gcc would be the 
>> exception. (Long before I used gcc or tcc, I used lccwin32.)
> 
> On Linux, almost everyone uses gcc, except for a proportion who actively 
> choose to use clang or icc.  The same applies to other many other *nix 
> systems, though some people will use their system compiler on commercial 
> Unixes.  For Macs, it is clang disguised as gcc that dominates.  On 
> Windows, few people use C for native code (C++, C# and other languages 
> dominate).  I expect the majority use MSVC for C, and there will be 
> people using a variety of other tools including lcc-win and Borland, as 
> well as gcc in various packagings.  (And embedded developers use 
> whatever cross-compile tools are appropriate for their target, 
> regardless of the host - the great majority use gcc now.)
> 
> I don't believe that in any graph of compiler usage on any platform, tcc 
> would show up as anything more than a tiny sliver under "others".
> 
>>
>> Here's the result of an experiment I did. gcc 14 is about 800MB and 
>> over 10,000 files. I wanted to see the minimal set of files that would 
>> compile one of my generated C files.
> 
> Why?  800 MB is a few pence worth of disk space.  For almost all uses, 
> it simply doesn't matter.

It's sloppy.

If I transpile code to C via my one-file 0.3MB compiler, I'd have to 
tell people they need also this 800MB/10000-file dependency, of which 
they only need 45MB/15 files (or more with linking), but, sorry, I have 
no idea which bits are actually essential!


>>
>> I can't explain to somebody who doesn't get it why a small, simple 
>> tool is desirable.
>>
> 
> If you were trying to say that tcc is simpler to /use/ than gcc, that 
> would be a different matter entirely.  That would be a relevant factor. 
> The size of the gcc installation, is all hidden behind the scenes.  Few 
> people know how big it is on their system, fewer still care.
> 
> (And I am not sure I agree with such a claim - certainly you /can/ have 
> very advanced and complicated use of gcc.  But in comparison to learning 
> C itself, running "gcc -Wall -O2 -o hello hello.c" is hardly rocket 
> science.  But I would certainly be much more open to a "simpler to use" 
> argument.)

Actually, on Windows, tcc is harder to use than gcc for my generated C. 
Most of that is due to needing the -fdollars-in-identifiers option 
because my C uses '$'.

It probably takes longer to type that, if you compile half a dozen 
times, than it would take to fix tcc to allow '$' /unless/ such an 
option was used.

(I just tried it; what tool longer was finding the write source file. 
The fix was to change:

     set_idnum('$', s1->dollars_in_identifiers ? IS_ID : 0);

to:

     set_idnum('$', s1->dollars_in_identifiers ? 0 : IS_ID);

But that only fixes one copy of it. It doesn't fix the versions that 
other people use.)