[Top] [All Lists]

Re: Benchmark performance

To: "Kevin D. Kissell" <>
Subject: Re: Benchmark performance
From: Ralf Baechle <>
Date: Thu, 16 Aug 2001 13:06:56 +0200
Cc:, Atsushi Nemoto <>,
In-reply-to: <005b01c12633$813c8820$0deca8c0@Ulysses>; from on Thu, Aug 16, 2001 at 11:11:56AM +0200
References: <><> <> <005b01c12633$813c8820$0deca8c0@Ulysses>
User-agent: Mutt/1.2.5i
On Thu, Aug 16, 2001 at 11:11:56AM +0200, Kevin D. Kissell wrote:

> > Current CVS kernel uses FPU emulator unconditionally.  If one floating
> > point intruction causes a 'Unimplemented' exception (denormalized
> > result, etc.) following floating point instructions are also handle by
> > FPU emulator (not only the instruction which raise the exception).
> > 
> > I do not know this is really desired behavior, but here is a patch to
> > change this.  If Unimplemented exception had been occured during the
> > benchmark, aplying this patch may result better performance.
> Not desired behavior, just an artifact.  However, I agree with Carsten
> that changing the API to the emulator for this and using a counter
> as you have done is not appropriate, and that the existing CPU
> configuration flag is a more appriate mechanism.  It's possible
> that Wayne's baseline numbers came from a pre-Algor-emulator
> kernel, and that this "feature" accounts for some of his degraded
> performance.  But I'd be surprised if it accounted for all of it,
> unless his FP test does 10% of its calculations on denormalized
> numbers or something.

As I don't know the exact nature of the calculations involved it may well
be that the broken behaviour of a pre-fpuemu kernel did completly break
the algorithem involved.

As for the hard-fp case I agree with you.  It would be interesting to
know if fp instructions that need emulation appear in groups.  Then it's
the (hopefully) rare case which we don't really care about.


<Prev in Thread] Current Thread [Next in Thread>