Re: Computer architects leaving Intel...

Brett wrote:

Terje Mathisen <terje.mathisen@tmsw.no> wrote:

Brett wrote:

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

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.

>
Not true:
>
My favorite benchmark program for 20+ years was Word Count, I
re-optimized that for every new x86 generation, and on the Pentium I got
it to run at 1.5 clock cycles per character (40 MB/s on a 60 MHz Pentium).
>
When the PentiumPro came out, it did a 10-20 cycle stall for every pair
of characters, so about an order of magnitude slower in cycle count.
(But only about 3X clock time due to being 200 instead of 60 MHz.)

 But how big a slowdown did the unoptimized code get?

The gcc-optimized unix wc was probably still a slower than my glass jaw-hitting asm code: The issue was partial register stalls, where I had been using the relatively tricky concept of interleaving updates to the BL and BH halfs of BX, then using BX to index into a table of combined word and line increments:
   add dx,ax
   mov ax,incr_table[bx]
   mov bl,extra_segment[di]
   mov di,[si+offset]
followed by
   add dx,ax
   mov ax,incr_table[bx+16] ;; Transposed table interleaved at +16
   mov bh,extra_segment[di]
   mov di,[si+offset+2]
All of the above unrolled 64 times so that the code would load & count 256 characters with zero branches.

 Are you describing a glass jaw handling unpredictable branches on a CPU
with a much longer pipeline?

PRS stalls was the single largest glass jaw on the PentiumPro, but it was very rare in compiled code.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"