Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Mon, 17 Jun 2024 15:43:31 +0200
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <v4pei3$m5th$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Jun 2024 15:43:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6eee6dfb82180fb756db1a7758fc4b5a";
	logging-data="726961"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18h7fD9vR2wp4orOYPCionu6G+rLTRoVwo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:+WpyscExtsbNhIY5ORZ1PO9l2e8=
In-Reply-To: <v4p37r$k32n$1@dont-email.me>
Content-Language: en-GB
Bytes: 5496

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.

> (I have also suggested that gcc should incorporate a -O-1 option that 
> runs a secretly bundled of Tiny C.)