This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: The new scheduler and x86 CPUs


Bernd Schmidt wrote:
> 
> On Tue, 28 Aug 2001, Vladimir Makarov wrote:
> 
> >   Actually I don't like out-of-order/speculative processors.  It is
> > solution for pure people which can not afford to write a good compiler
> > requiring huge investments.  It is a dead end approach.  The more
> > registers and issue rate, the more percent of logic is needed for
> > control of out-of-order, speculative execution.  Intel understood
> > this.  They have a decent compiler and gcc is far behind it.  We
> > should worry about this.
> 
> Look at the published SPEC numbers - even when using Intel's compiler,
> Itanium is far away from being a top performer for integer programs.  I
> don't think that's an accident; you have a lot more information available
> at run-time than at compile-time.  One of the reasons that optimizing for
> ia64 is so difficult is that you don't know enough about e.g. memory
> aliasing.
> 
> 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.  SPECfp is 2 times better,  Unlike UltraSparcII, Itanium
is only the first implementation of IA64, I would say a test
implementation.  E.g. Itanium does not support multiple
branches/prefetch although IA64 does.

  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. 
Therefore their development is now concentrated on multi-threaded
support (exposing coarse grain parallelism).  EPIC and VLIW is more
scalable architecture for fine grain parallelism and has the same
potential as OOO for coarse grain parallelism (by the way Intel bought
Alpha developers which are the most experienced now in multithreaded
architectures).  There is no other way to achieve potential (fine grain)
parallelism which even for SPECint achieve 30-40 insns per cycle.  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.

  The compilers for IA64 is in a research stage and I think have a
potential for improving.  Therefore I worry about gcc which is far
behind the Intel compiler.  Intel is not going to give up IA64 (although
their insn packing is weird).  On my opinion, it is matter of time that
EPIC and new generation of VLIW win in high end (desktop and embedded)
computing.

Vlad


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]