Re: The new scheduler and x86 CPUs

[Bernd Schmidt <bernds at redhat dot com>]

On Tue, 28 Aug 2001, Vladimir Makarov wrote:
> > Why is OOO a dead-end approach?  If there's parallelism to extract
> > in a program, then if a compiler can find it, an OOO core can find it
> > just as well.
>
>   I see
> (http://www.intel.com/eBusiness/products/ia64/overview/bm012101.htm#5)
> that Itanium has the same SPECint as UltrasparcIII practically on the
> same frequency.

Is Ultrasparc III out-of-order?  I thought it was in-order too.  There's
nothing in
  http://www.sun.com/sparc/UltraSPARC-III/USIIITech.html
that suggests it's OOO.  So it isn't all that surprising to me that it's
slow as well.

>   OOO has constraints on speculation (branches to look through, look
> ahead buffer).  Of course you could increase this characteristics, but
> in this case the penalty of mispredictions is bigger.  The control logic
> to implement OOO is very big (even now as I remember it achieves 1/3-1/2
> of all control logic).  Therefore maximal issue rate for them is 6-8.

How much parallelism are you likely to extract out of a typical integer
program, anyway?  IMO, 6-8 is quite near or possibly over the limit for
typical programs.

> There is no other way to achieve potential (fine grain)
> parallelism which even for SPECint achieve 30-40 insns per cycle.

I don't believe this.  Can you back up this number?  Even if it were
realistic, is there any known strategy for a compiler to get anywhere
close?  And, is it feasible that actual hardware could be built to make
use of it?

> Also
> this approach is simpler with hardware point of view (the logic were
> used for OOO control could be used for more useful functional units as
> ALUs), the typical example of this for embedded systems (with low power
> consumption) could be Transmeta processors.

Current ia64 systems don't seem to be very low power designs.


Bernd