Path: ...!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: Tue, 18 Jun 2024 08:44:32 +0200
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <v4racg$17j40$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> <v4plsk$nn9o$2@dont-email.me>
 <v4pnq6$o4fs$1@dont-email.me> <v4q245$si2n$1@dont-email.me>
 <v4q2rl$sqk3$1@dont-email.me> <v4q8gr$u2fb$1@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 08:44:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="000ac22a82b477e7b73d30c4bbbc814d";
	logging-data="1297536"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX198LB90MIuXXnJ8rdw+eHgTDEXU6kWt1RE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:6MpQ9Bq9BEQ6HpfyOLRLH8T1ShQ=
Content-Language: en-GB
In-Reply-To: <v4q8gr$u2fb$1@dont-email.me>
Bytes: 4773

On 17/06/2024 23:06, Malcolm McLean wrote:
> On 17/06/2024 20:29, David Brown wrote:
>> On 17/06/2024 21:17, Malcolm McLean wrote:
>>> On 17/06/2024 17:21, David Brown wrote:
>>>> On 17/06/2024 17:48, Malcolm McLean wrote:
>>>>>
>>>> Using C without optimisation is like driving a car but refusing to 
>>>> go out of first gear.  You would probably have been better off with 
>>>> a bicycle or driving a tank, according to the task at hand.
>>>>
>>> I drive C in first gear when I'm developing, which means that the car 
>>> is given instructions to go to the right place and obey all, the 
>>> rules of the road.
>>
>> I do my C development with optimisations enabled, which means that the 
>> C compiler will obey all the rules and requirements of C.  
>> Optimisations don't change the meaning of correct code - they only 
>> have an effect on the results of your code if you have written 
>> incorrect code.  I don't know about you, but my aim in development is 
>> to write /correct/ code. If disabling optimisations helped in some 
>> way, it would be due to bugs and luck.
>>
>>> But it never gets out of frst gear when I'm driving it. However 
>>> because of the nature of what we do, which is interactivce 
>>> programming mostly, usually "just noticeable" time is sufficient. 
>>> It's a bit like driving in London - a top of the range sports car is 
>>> no better than a beat up old mini, they travel at the same speed 
>>> because of all the interactions.
>>>
>>
>> If I am writing PC code where the timing is determined by user 
>> interaction, I would not be writing in C - it is almost certainly a 
>> poor choice of language for the task.
>>
>>> They I had it over to the deployment team, and they take the 
>>> restraints off, and allow it to go up to top gear, and it is compiled 
>>> with full optimisation. 
>>
>> That is insane development practice, if I understand you correctly.  
>> For some kinds of development work, it can make sense to have one 
>> person (or team) make prototypes or proofs-of-concept, and then have 
>> another person (or team) use that as a guide, specification and test 
>> comparison when writing a fast implementation for the real product.  
>> But the prototype should be in a high-level language, written in the 
>> clearest and simplest manner - not crappy code in a low-level language 
>> that works by luck when it is not optimised!
>>
>>> And I don't actually have a computer with one of the most important 
>>> hardware targets, but it's all written in C++, a bit in C, and none 
>>> in assembler. So I can't profile it, and I have to rely on insight 
>>> into where the inner loop will be, and how to avoid expensive 
>>> operations in the inner loop.
>>
>> If you are writing C++ and are not happy about using optimisation, you 
>> are in the wrong job.
>>
> You know what hardware your code will run on. I don't.
> 

That is absolutely true, and it gives me certain advantages.  It is also 
the case that high-quality optimisation is vital to my work.

But it is also absolutely irrelevant to the point I was making.