Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: int a = a (Was: Bart's Language)
Date: Wed, 19 Mar 2025 11:40:32 +0100
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <vre6v0$lb74$1@dont-email.me>
References: <vracit$178ka$1@dont-email.me> <vrc2d5$1jjrf$1@paganini.bofh.team>
 <vrc4eb$2p28t$1@dont-email.me> <vrc75b$2r4lt$1@dont-email.me>
 <vrccjb$b3m6$1@news.xmission.com> <vrcisg$35ffo$1@dont-email.me>
 <vrcs09$3ejvg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 Mar 2025 11:40:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ea1b0970b8bf0b1e1c0e9bf265f385ce";
	logging-data="699620"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19o4WFvw+Xc/61Rgcl1oww/5LfpdnRkxRk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:MUQ8glvFJNWLu2rJDbUCM2nuudk=
In-Reply-To: <vrcs09$3ejvg$1@dont-email.me>
Content-Language: en-GB
Bytes: 3402

On 18/03/2025 23:27, Janis Papanagnou wrote:
> On 18.03.2025 20:51, David Brown wrote:
>> [...]  A brief check suggests that gcc will generate code as it
>> would for "int a = 0;", but it is certainly possible for a compiler to
>> avoid any kind of initialisation here and let the register or stack slot
>> used for "a" stay as it was.  That would be a pretty minor efficiency
>> improvement,
> 
>> but optimised code is mostly the sum of lots of tiny improvements.
> 
> Interesting view. I've learned that such Peephole Optimizations were
> not what contribute to optimizations most. It's rather transformations
> of structure of various forms that is what "mostly" matters. - That's
> what I've learned many decades ago, of course. - So I'm curious where
> you've got that view from. (Some reference, maybe? Or was that just a
> personal opinion?)
> 

Some optimisations have big effects, certainly - good register 
allocation and lifetime analysis, and optimisations that move code 
around (loop transformations, inlining, etc.) are the big factors. 
However, in modern compilers there are lots of minor optimisations that 
only apply in a few cases and only help a few percent in those cases. 
Each does little on its own, but in sum the results can be significant.

But you are right that it is not really fair to say that optimisation is 
"mostly" the sum of tiny improvements - it's a small number of big and 
important transforms, and /then/ the sum of a large number of small ones.

One complicating factor about these small optimisations is that the 
observable effect on code speed is highly dependent on the rest of the 
code and the type of processor involved.  A peephole optimisation that 
removes an extra register-to-register move will save a cycle on a 
microcontroller, but on an x86 system such a move might be merged in the 
register renaming hardware of the cpu's prefetch queues and thus 
disappear entirely.  Reducing instruction cycles matters a lot on 
microcontrollers, while on a big processor they might not make any 
difference if the cpu is waiting for memory.