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 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: References: <20240624160941.0000646a@yahoo.com> <20240624181006.00003b94@yahoo.com> <20240625113616.000075e0@yahoo.com> <87ed8jnbmf.fsf@bsb.me.uk> 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: 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.)