Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Mon, 17 Jun 2024 16:48:36 +0100
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <v4plsk$nn9o$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: Mon, 17 Jun 2024 17:48:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f27d645ef399f596eab7376e05efef48";
	logging-data="777528"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/5m6BFZt1wrzH0H7A8jDtFZ3hkJSEP6+U="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/d7zCwxgdcf+ySswnnwbrJucuhA=
In-Reply-To: <v4pei3$m5th$2@dont-email.me>
Content-Language: en-GB
Bytes: 5497

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.
> 
I never do.
Until I had to give up work, I was making real time tools for artists. 
And if it didn't work in under just noticeable time on the debug build, 
it wouldn't be working in under just noticeable time on the release 
build, you could be pretty sure. So I never turned the release build on, 
but of course the downstream deployment team built it as release for 
delivery to customers. And that might mean that they could do 2000 paths 
instead of 1000 before the tool slowed to the point that it became 
unusable. So not a game changer. But not something to deprive a customer 
of either.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc