Path: ...!npeer.as286.net!dummy01.as286.net!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feeder2.feed.ams11.usenet.farm!feed.usenet.farm!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 19:25:51 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <vbni3u$2h7pp$1@dont-email.me>
References: <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at>
 <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me>
 <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@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>
 <vbd174$eulp$1@dont-email.me>
 <vbm67e$2apse$1@dont-email.me>
 <vbmkln$2cmfo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 09 Sep 2024 21:25:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="85bb6b4226d8f4467c835a59dfed7392";
	logging-data="2662201"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ObtXu1zmjxn4vp5v3It6V"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:+ehT0mwUr4QrowDxc2DzPSQtqwA=
	sha1:1RaIC+2BX3XygHIE4cOWnoRLsmw=
X-Received-Bytes: 6304
Bytes: 6429

David Brown <david.brown@hesbynett.no> wrote:
> On 09/09/2024 08:56, Terje Mathisen wrote:
>> David Brown wrote:
>>> On 05/09/2024 19:04, Terje Mathisen wrote:
>>>> David Brown wrote:
>>>>> On 05/09/2024 11:12, Terje Mathisen wrote:
>>>>>> David Brown wrote:
>>>>>>> Unsigned types are ideal for "raw" memory access or external data, 
>>>>>>> for anything involving bit manipulation (use of &, |, ^, << and >> 
>>>>>>> on signed types is usually wrong, IMHO), as building blocks in 
>>>>>>> extended arithmetic types, for the few occasions when you want 
>>>>>>> two's complement wrapping, and for the even fewer occasions when 
>>>>>>> you actually need that last bit of range.
>>>>>> 
>>>>>> That last paragraph enumerates pretty much all the uses I have for 
>>>>>> integer-type variables, with (like Mitch) a few apis that use (-1) 
>>>>>> as an error signal that has to be handled with special code.
>>>>>> 
>>>>> 
>>>>> You don't have loop counters, array indices, or integer arithmetic?
>>>> 
>>>> Loop counters of the for (i= 0; i < LIMIT; i++) type are of course 
>>>> fine with unsigned i, arrays always use a zero base so in Rust the 
>>>> only array index type is usize, i.e the largest supported unsigned 
>>>> type in the system, typically the same as u64.
>>> 
>>> Loop counters can usually be signed or unsigned, and it usually makes 
>>> no difference.  Array indices are also usually much the same signed or 
>>> unsigned, and it can feel more natural to use size_t here (an unsigned 
>>> type).  It can make a difference to efficiency, however.  On x86-64, 
>>> this code is 3 instructions with T as "unsigned long int" or "long 
>>> int", 4 with "int", and 5 with "unsigned int".
>>> 
>>> int foo(int * p, T x) {
>>>      int a = p[x++];
>>>      int b = p[x++];
>>>      return a + b;
>>> }
>> 
>> ;;  assume *p in rdi, x in rsi
>> 
>>   mov rax,[rdi+rsi]
>>   add rax,[rdi+rsi+8]
>>   ret
> 
> Yes - that's three instructions for 64-bit type T.  (To be clear, I had 
> counted the "ret" here.)
> 
> With 32-bit int for T, you need a "movsx rsi, esi" first to sign-extend 
> the 32-bit int parameter "x" to 64 bits.  (That could be different for 
> different ABI's.)  With 32-bit unsigned int for T you need an additional 
> instruction to make sure the result of the first "x++" is wrapped as 
> 32-bit unsigned.
> 
>>> 
>>> Or you could just write sane code that matches what you want to say.
>>> 
>> :-)
>> 
> 
> Of course the fine line between "smart code" and "smart-arse code" is 
> somewhat subjective!
> 
> It also varies over time, and depends on the needs of the code. 
> Sometimes it makes sense to prioritise efficiency over readability - but 
> that is rare, and has been getting steadily rarer over the decades as 
> processors have been getting faster (disproportionally so for 
> inefficient code) and compilers have been getting better.
> 
> Often you get the most efficient results by writing code clearly and 
> simply so that the compiler can understand it better and good object 
> code.  This is particularly true if you want the same source to be used 
> on different targets or different variants of a target - few people can 
> track the instruction scheduling and timings on multiple processors 
> better than a good compiler.  (And the few people who /can/ do that 
> spend their time chatting in comp.arch instead of writing code...)  When 
> you do hand-made micro-optimisations, these can work against the 
> compiler and give poorer results overall.  

I know of no example where hand optimized code does worse on a newer CPU.
A newer CPU with bigger OoOe will effectively unroll your code and schedule
it even better.

It’s older lesser CPU’s where your hand optimized code might fail hard, and
I know of few examples of that. None actually.

> This is especially the case 
> when code is moved around with inlining, constant propagation, 
> unrolling, link-time optimisation, etc.
> 
> Long ago, it was a different matter - then compilers needed more help to 
> get good results.  And compilers are far from perfect - there are still 
> times when "smart" code or assembly-like C is needed (such as when 
> taking advantage of some vector and SIMD facilities).