Re: gcc300 benchmarks slower than gcc295.3?

[Gareth Hughes <gareth dot hughes at acm dot org>]

Linus Torvalds wrote:
> 
> There's no read-modify-write interlock on any modern CPU (ie PPro+) that
> does out-of-order execution with the instructions already split up into
> simpler parts. So using the memory operand form gives you:
> 
>  - better decoding throughput (fewer instructions)
>  - better code density
>  - less register pressure
> 
> with basically no downsides.  This is true both for source and
> destination: write a small benchmark if you like.

The Intel Architecture Optimization Manual (at least the version for the
PIII, I'm not familiar with the P4 one) stresses using RISC-like
instructions rather than ones with memory operands to get better
decoding throughput.  Their motivation is that ops with register
operands generally turn into single uops, while memory operands
generally result in at least 4 uops.  As the decoders handle 4-1-1 uops,
this seems to make sense.  Lots of instructions with more than 1 uop
mean that only 1 instruction can be decoded per cycle.

However, AMD's latest Optimization Manual states memory operands should
be used where possible as the Athlon can decode 3 DirectPath
instructions per cycle, period (DirectPath == most of the common x86
instructions).  That's the point of out-of-order execution -- the chip
does all the scheduling for you, so you want to get as many uops into
the reorder buffer as possible.  I can add two more points to the list
above:

  - better use of execution resources (only one reservation station is
    used)
  - fewer address computations

In general, especially for modern x86 processors, memory operands make
sense.  I have certainly found this to be true, particularly with the
PIII and Athlon.

-- Gareth