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: Fri, 21 Jun 2024 11:46:04 +0200
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <v53i4s$33k73$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> <v4plsk$nn9o$2@dont-email.me>
 <v4pnq6$o4fs$1@dont-email.me> <v4q245$si2n$1@dont-email.me>
 <v4q2rl$sqk3$1@dont-email.me> <v52308$2nli8$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 21 Jun 2024 11:46:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="017bd53d5809bfe07afbcdbc63488ddf";
	logging-data="3264739"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18XMvTGaM/Vbb1bFFN+EwFKGvjKzn8ZcdE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:VeHvUAJp+E/Jp4X7iABycmiLtO4=
In-Reply-To: <v52308$2nli8$3@dont-email.me>
Content-Language: en-GB
Bytes: 6093

On 20/06/2024 22:21, Vir Campestris wrote:
> On 17/06/2024 20:29, David Brown wrote:
>> 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.
> 
> To me disabling optimisations does one slightly useful thing (compiles a 
> little quicker) and one really useful one. It makes the interactive 
> debugger work. Optimised code confuses the debugger, especially when it 
> does things like reorder code, unroll loops, or merge equivalent functions.
> 
> Of course I then test with the optimised version.
> 
> Andy


I understand your viewpoint and motivation.  But my own experience is 
mostly different.

First, to get it out of the way, there's the speed of compilation. 
While heavy optimisation (-O3) can take noticeably longer, I never see 
-O0 as being in any noticeable way faster for compilation than -O1 or 
even -O2.  (I'm implicitly using gcc options here, but it's mostly 
applicable to any serious compiler I have used.)  Frankly, if your 
individual C compiles during development are taking too long, you are 
doing something wrong.  Maybe you are using far too big files, or trying 
to do too much in one part - split the code into manageable sections and 
possibly into libraries, and it will be far easier to understand, write 
and test.  Maybe you are not using appropriate build tools.  Maybe you 
are using a host computer that is long outdated or grossly underpowered.

There are exceptions.  Clearly some languages - like C++ - are more 
demanding of compilers than others.  And if you are using whole-program 
or link-time optimisation, compilation and build time is more of an 
issue - but of course these only make sense with strong optimisation.


Secondly, there is the static error analysis.  While it is possible to 
do this using additional tools, your first friend is your compiler and 
its warnings.  (Even with additional tools, you'll want compiler 
warnings enabled.)  You always want to find your errors as early as 
possible - from your editor/IDE, your compiler, your linker, your 
additional linters, your automatic tests, your manual tests, your beta 
tests, your end user complaints.  The earlier in this chain you find the 
issue, the faster, easier and cheaper it is to fix things.  And 
compilers do a better job at static error checking with strong 
optimisations enabled, because they do more code analysis.


Thirdly, optimisation allows you to write your code with more focus on 
clarity, flexibility and maintainability, relying on the compiler for 
the donkey work of efficiency details.  If you want efficient results 
(and that doesn't always matter - but if it doesn't, then C is probably 
not the best choice of language in the first place) and you also want to 
write good quality source code, optimisation is a must.


Now to your point about debugging.  It is not uncommon for me to use 
debuggers, including single-stepping, breakpoints, monitoring variables, 
modifying data via the debugger, and so on.  It is common practice in 
embedded development.  I also regularly examine the generated assembly, 
and debug at that level.  If I am doing a lot of debugging on a section 
of code, I generally use -O1 rather than -O0 - precisely because it is 
far /easier/ to understand the generated code.  Typically it is hard to 
see what is going on in the assembly because it is swamped by stack 
accesses or code that would be far simpler when optimised.  (That goes 
back to the focus on source code clarity and flexibility rather than 
micro-managing for run-time efficiency without optimisation.)

Some specific optimisation options can make a big difference to 
debugging, and can be worth disabling, such as "-fno-inline" or 
"-fno-top-reorder", and heavily optimised code can be hard to follow in 
a debugger.  But disabling optimisation entirely can often, IME, make 
things harder.

Temporarily changing optimisation flags for all or part of the code 
while chasing particular bugs is a useful tool, however.