Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 07 Sep 2024 09:33:22 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <86cylfmnjh.fsf@linuxsc.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb00c2$150ia$1@dont-email.me> <505954890d8461c1f4082b1beecd453c@www.novabbs.org> <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me> <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me> <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me> <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me> <vb9l7k$3r2c6$2@dont-email.me> <vba26l$3te44$1@dont-email.me> <vbag2s$3vhih$1@dont-email.me> <vbbnf9$8j04$1@dont-email.me> <vbbsl4$9hdg$1@dont-email.me> <vbcbob$bd22$3@dont-email.me> <vbcob9$dvp4$1@dont-email.me> <86h6atoizl.fsf@linuxsc.com> <vbdaq8$gdvk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 07 Sep 2024 18:33:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="15cdd4985ebd3d04d209b9ff3a6e4cfe";
	logging-data="1516293"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1//LHqwst8mlQuD/Gx3AlhGJV5K955e7qw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:fibLRBVkgSzO6C7aDndhozSvJfg=
	sha1:WDZ/EkbkhNNymBe00+D3rzGJBhI=
Bytes: 3810

Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> writes:

> On 06.09.24 00:04, Tim Rentsch wrote:
>
>> If START is signed (presumably of type int), so the loop might run
>> zero times, but never more than INT_MAX times, then
>>
>>      for(  unsigned u = START < 0 ? 0 : START + 1u;  u > 0 && u--;  ){
>>        // Do something with data[i]
>>      }
>>
>> If START is unsigned, so in all cases the loop must run at
>> least once, then
>>
>>      unsigned u = START;
>>      do {
>>        // Do something with data[i]
>>      } while(  u > 0  &&  u--  );
>>
>> (Yes I know the 'u > 0' expressions can be replaced by just 'u'.)
>>
>> The optimizer should be smart enough to realize that if 'u > 0'
>> is true then the test 'u--' will also be true.  The same should
>> hold if 'u > 0' is replaced by just 'u'.
>>
>> (Disclaimer:  code not compiled.)
>
> Both yield not very elegant code:
>
> https://godbolt.org/z/M4Y5PYP3v

The problem being solved is not typical.  In most cases
downward-counting loops start at one past the end of the
values, not at the last value.  I didn't choose the problem.

Any "inelegancy" might just as well as come from how the
optimizer was written as from the code.  Clearly optimizers
do better on some patterns than others.  (For that matter,
the earlier code shown may have resulted in generated code
that is just as unappealing.)

The generated code being not very elegant doesn't necessarily
imply poor performance.

In almost all cases the performance implications don't matter.
Premature optimization is the root of all evil.  The first
reaction should never be to look at what code is generated.

The purpose of the example (besides fixing a bug in the original,
which was removed) is, one, to illustrate an idea, and two, to
show an alternate example pattern that may help in unrelated
cases.  It helps to be familiar with different approaches to
common situations.  For this particular problem, probably it's
better to revise code outside the loop so the loop would be
done differently.  The point here is not this code specifically
but a pattern and a principle that might be applicable in a
range of coding circumstances.