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.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 13:03:19 +0200
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vbmkln$2cmfo$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 09 Sep 2024 13:03:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="245842e44c78e95d3bc5cb773286c128";
	logging-data="2513400"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Nu8C7U0vBtlk7goySvwIVGSe5qaMjTiA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:We1uRzM1R6xr4yktZE19nOphTBM=
In-Reply-To: <vbm67e$2apse$1@dont-email.me>
Content-Language: en-GB
Bytes: 5840

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.  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).