Re: Baby X is bor nagain

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.)