Date:	Fri, 26 Feb 1999 20:33:47 +0100
To:	pgcc AT delorie DOT com
Subject:	Re: loop unrolling
Message-ID:	<19990226203347.E4813@cerebro.laendle>
Mail-Followup-To:	pgcc AT delorie DOT com
References:	<199902241423 DOT JAA29290 AT envy DOT delorie DOT com> <19990225235232 DOT C20417 AT cerebro DOT laendle> <19990226143506 DOT 26990 AT atrey DOT karlin DOT mff DOT cuni DOT cz>
Mime-Version:	1.0
In-Reply-To:	<19990226143506.26990@atrey.karlin.mff.cuni.cz>; from Jan Hubicka on Fri, Feb 26, 1999 at 02:35:06PM +0100
X-Operating-System:	Linux version 2.2.2 (marc AT cerebro) (gcc driver version pgcc-2.93.04 19990131 (gcc2 ss-980929 experimental) executing gcc version 2.7.2.3)
From:	Marc Lehmann <pcg AT goof DOT com>
Reply-To:	pgcc AT delorie DOT com

On Fri, Feb 26, 1999 at 02:35:06PM +0100, Jan Hubicka wrote:
> > for some cases. One of the problms is that the normal list scheduler
> > isn't up to scheduling for superscalar architectures (pentiumpro), while
> > the scheduling parameters aren't tuned for the haifa scheduler.

> Just curious:  I still hear, that haifa scheduler is ready for
> superscalar CPUs and normal not.  Why? The definitions are same, only
> haifa can do scheduling more agresivly.  Or I am wrong? (except the
> MD_SCHED hacks. Is that the superscalar feature?)

Since the machine description is only declarative you are partly right. But
that doesn't mean that the normal scheduler schedules correctly according to
these declarations.

It seems that, yes, the haifa scheduler seems just to perform more correct.
You can regard it as an "improved" sched.c.

I have not looked into what the MD_SCHED changes actually do, but they
are only declarative as well (and the old scheduler cannot use this
information).

--  
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg AT goof DOT com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

- Raw text -