Re: Baby X is bor nagain

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.