Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Vir Campestris <vir.campestris@invalid.invalid>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Wed, 26 Jun 2024 11:31:07 +0100
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <v5gqld$23d7q$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> <v52308$2nli8$3@dont-email.me>
 <v53i4s$33k73$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Jun 2024 12:31:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="33717825154947d0235c868c3b1181dd";
	logging-data="2209018"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/OFO1GYsZuoWEEXKmpFafQ9P3M/prvfzE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bPi6IapZjD8b0Hq74IJrXq5Z2h4=
In-Reply-To: <v53i4s$33k73$2@dont-email.me>
Content-Language: en-GB
Bytes: 5977

On 21/06/2024 10:46, David Brown wrote:
> 
> 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.
> 
Or maybe I have a really big code base. (My last project at work was 
using a distributed compilation system across all our workstations)

I must admit I haven't tried O1 or O2. I'll give it a go.

> 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.
> 
In recent years most of my code has ben C++.

Now I'm retired I'm not writing much serious code anyway - for some 
reason I don't seem to have the time for any voluntary projects, and all 
I do is a little hackery. If it's really small I'll do it in a spreadsheet.
> 
> 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.
> 
Agreed. The cost of maintenance is often overlooked, and correct code is 
more useful than faster code.
> 
> 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.

I'll play with the settings.

Andy