Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.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: Mon, 17 Jun 2024 20:24:07 +0100
Organization: A noiseless patient Spider
Lines: 127
Message-ID: <v4q2gm$sib9$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <v4p37r$k32n$1@dont-email.me>
 <v4pei3$m5th$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jun 2024 21:24:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="10d436d755e4bfde8066d45503d65232";
	logging-data="936297"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19oZOOL2Ha8E1rT+wxR8MxD"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hUSFGNo/z4wl43wN3incMMo8hG0=
Content-Language: en-GB
In-Reply-To: <v4pei3$m5th$2@dont-email.me>
Bytes: 6977

On 17/06/2024 14:43, David Brown wrote:
> On 17/06/2024 12:30, bart wrote:
>> On 17/06/2024 07:22, James Kuyper wrote:
>>> On 6/13/24 10:43, Michael S wrote:
>>>> On Thu, 13 Jun 2024 13:53:54 +0200
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>> ...
>>>>> I know more than most C programmers about how certain C compilers
>>>>> work, and what works well with them, and what is relevant for them -
>>>>> though I certainly don't claim to know everything. Obviously Bart
>>>>> knows vastly more about how /his/ compiler works. He also tends to
>>>>> do testing with several small and odd C compilers, which can give
>>>>> interesting results even though they are of little practical
>>>>> relevance for real-world C development work.
>>>>>
>>>>
>>>> Since he do compilers himself, he has much better feeling [that you
>>>> or me] of what is hard and what is easy, what is small and what is big,
>>>> what is fast and what is slow. That applies to all compilers except
>>>> those that are very unusual. "Major" compiler are not unusual at all.
>>>
>>> The problem is that Bart's compiler is VERY unusual. It's customized for
>>> his use, and he has lots of quirks in the way he thinks compilers should
>>> work, which are very different from those of most other programmers.
>>
>>
>>> In
>>> particular, compilation speed is very important to him, while execution
>>> speed is almost completely unimportant, which is pretty much the
>>> opposite of the way most programmers prioritize those things.
>>
>> Compilation speed is important to everyone. That's why so many tricks 
>> are used to get around the lack of speed in a big compiler, or so many 
>> extra resources are thrown at the problem.
> 
> What "tricks" ?
> 
>>
>> Runtime performance is important too, but at this level of language, 
>> the difference between optimised and unoptimised code is narrow. 
>> Unoptimised may be between 1x and 2x slower, typically.
> 
> That depends on the language, type of code, and target platform. Typical 
> C code on an x86_64 platform might be two or three times slower when 
> using a poorly optimising compiler.  After all, the designers of x86 
> cpus put a great deal of effort into making shitty code run fast. For 
> high-performance code written with care and requiring fast results, the 
> performance difference will be bigger.  For C++, especially code that 
> makes good use of abstractions, the difference can be very much bigger.  
> For C code on an embedded ARM device or other microcontroller, it's not 
> unusual to see a 5x speed improvement on optimised code.
> 
> Speed is not the only good reason for picking C as the language for a 
> task, but it is often a relevant factor.  And if it is a factor, then 
> you will usually prefer faster speeds.
> 
>>
>> Perhaps slower on benchmarks, or code written in C++ style that 
>> generates lots of redundances that relies on optimisation to make it 
>> fast.
>>
>> But, during developement, you probably wouldn't use optimisation anyway.
>>
> 
> I virtually always have optimisation enabled during development.  I 
> might, when trying to chase down a specific bug, reduce some specific 
> optimisations, but I have never seen the point of crippling a 
> development tool when doing development work - it makes no sense at all.
> 
>> In that case, you're still suffering slow build times with a big 
>> compiler, but you don't get any faster code at the end of it.
>>
>> I sometimes suggest to people to use Tiny C most of the time, and run 
>> gcc from time to time for extra analysis and extra checks, and use 
>> gcc-O3 for production builds.
>>
> 
> I cannot imagine any situation where I would think that might be a good 
> idea.
> 
> But then, I see development tools as tools to help my work as a 
> developer, while you seem to consider tools (other than your own) as 
> objects of hatred to be avoided whenever possible or dismissed as 
> "tricks".  I don't expect we will ever agree there.

Here's one use-case of a C compiler, to process the output of my 
whole-program non-C compiler. The 'mc' transpiler first converts to C 
then invokes a C compiler according to options:

   C:\qx52>tm mc -mcc qc
   W:Invoking C compiler: mcc  -out:qc.exe qc.c
   Compiling qc.c to qc.exe
   TM: 0.31

   C:\qx52>tm mc -tcc qc
   W:Invoking C compiler: tcc  -oqc.exe qc.c 
c:\windows\system32\user32.dll -luser32 c:\windows\system32\kernel32.dll 
-fdollars-in-identifiers
   TM: 0.27

   C:\qx52>tm mc -gcc qc
   W:Invoking C compiler: gcc -m64   -oqc.exe qc.c -s
   TM: 2.44

   C:\qx52>tm mc -gcc -opt qc
   W:Invoking C compiler: gcc -m64  -O3 -oqc.exe qc.c -s
   TM: 14.47

The actual translation to C take 0.1 seconds, so tcc is 13 times faster 
at producing optimised code than gcc-O0, and about 80 times faster than 
gcc-O3 (67 times faster than -O2).

If you don't need optimised code right now, why would you invoke gcc 
rather than tcc? It's a no-brainer.

My C compiler is in there as well, and it's also quite fast, but if I 
can run it, it means I'm running on Windows and can also directly use my 
main compiler, which completes the job in 0.1 seconds:

   C:\qx52>tm mm qc
   TM: 0.09

But if running on Linux for example, I need to use intermediate C, and 
tcc makes more sense as a default than gcc.

With tcc, I also only need two files totalling 230KB (I don't need std 
headers); I can bundle it with the compiler.