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: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Mon, 17 Jun 2024 21:29:57 +0200
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <v4q2rl$sqk3$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jun 2024 21:29:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c4e4b5756e2db6b50d94114c01c52c76";
	logging-data="944771"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/OhzKIh1yWGinuZ1TQIG75tvoOCgl1fBQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:oHCQVDl2a6BMD3ROeR0rz6DfrHs=
In-Reply-To: <v4q245$si2n$1@dont-email.me>
Content-Language: en-GB
Bytes: 4748

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.

> 
> And hopefully those subroutines will be called for many years to come, 
> or hardware as yet un-designed.
> 
> With Baby X, I did have severe problems with the rendering speed on an 
> old Windows machine. But I haven;t noticed them now its runnng on the 
> Apple Mac. However as the name suggests, Baby X was first designed for X 
> lib. I only added Windows support later, and all the rgba buffers were 
> in the wrong format. But faster processors cover a multitude of sins, if 
> you keep things lean.
>