Re: Computer architects leaving Intel...

On 09/09/2024 21:25, Brett wrote:

David Brown <david.brown@hesbynett.no> wrote:

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.

I would agree with you there.  For the same object code, newer CPUs (with the same ISA) are typically faster for a variety of reasons. There may be the odd regression, but it is hard to market a newer CPU if it is slower than the older ones!
However, my point was that "hand-optimised" source code can lead to poorer results on newer /compilers/ compared to simpler source code.  If you've googled for "bit twiddling hacks" for cool tricks, or written something like "(x << 4) + (x << 2) + x" instead of "x * 21", then the results will be slower with a modern compiler and modern cpu, even though the "hand-optimised" version might have been faster two decades ago.  You can expect the modern tool to convert the multiplication into shifts and adds if that is more efficient on the target, or a multiplication if that is best on the target.  But you can't expect the compiler to turn the shifts and adds into a multiplication.  (Sometimes it can, but you can't expect it to.)

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