Path: ...!feed.opticnetworks.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: Tue, 18 Jun 2024 19:22:46 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <v4sj9l$1facl$2@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: Tue, 18 Jun 2024 20:22:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="53025cad3a0039377ef43824bbd67ea2";
	logging-data="1550741"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+xFwOZD3dWSRqGneN3Q874"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ivRpzUyEkew/sNwviibPDQlTR9M=
Content-Language: en-GB
In-Reply-To: <v4pei3$m5th$2@dont-email.me>
Bytes: 4351

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" ?

Going to considerable lengths to avoid actually doing any compilation, 
or to somehow cache previous results (I mean things like .pch files 
rather than .o files).

Have a look at any makefile.

If compilation was instant, half the reasons for a makefile and its 
dependency graphs would disappear.

For the scale of programs I write, with the tools I use, compilation 
*is* more or less instant.

(Roughly 0.1 seconds; faster than it takes to press and release the 
Enter key, for my main compiler. My C compiler takes a bit longer, as it 
has been accelerated, but it tends to be used for smaller projects if it 
is something I've written.)

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

Yes, that's one reason why you can get away without an optimiser, for 
sensibly written source code. But it also makes reasoning about optimal 
code much harder: removing superfluous instructions often makes code slower!