Re: Computer architects leaving Intel...

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