[MPlayer-dev-eng] Re: [SURVEY] change default CPU target when compiled with runtime CPU detection

Rich Felker dalias at aerifal.cx
Wed Nov 16 05:49:16 CET 2005


On Wed, Nov 16, 2005 at 11:04:27AM +0800, Zuxy wrote:
> 2005/11/16, Rich Felker <dalias at aerifal.cx>:
> > On Tue, Nov 15, 2005 at 02:09:33PM +0800, Zuxy wrote:
> > >
> > > Well I'd say that's a rumor. It's true that P4s are more sensitive to
> > > instruction selection, and imply stricter rules for compilers to do
> > > that. However, it's still far from so called 'anti-optimized', since
> > > these rules have minimal negative impact on earlier CPUs, i.e. they
> > > usually don't care. Besides, instruction selection is only a small
> >
> > False. Just look at bitshift optimizations for an example. foo<<3 may
> > be slower than ((foo+foo)+(foo+foo))+((foo+foo)+(foo+foo)) on a P4,
> > the latter is obviously stupid on any sane cpu!
> >
> 
> I guess you've looked up the latency table and forgot to check the
> throughput?:-) Intel recommends compilers to focus on maximum
> throughput first, then the minimum latency.

Because Intel is stupid. Latency is always the dominant factor in
anything but blind DSP operations.

> The case that you've
> pointed out does exist, but is extremely rare, and compilers always
> generate SAL instead of ADDs.

I have no idea what compilers generate but I am sure there are plenty
of other cases where the p4 optimization mode generates bade code.

> Besides, any CPU has some odd things. Athlon requires the compiler to
> insert a "rep" prefix before "ret" sometimes but I won't call it
> insane.

Requires? This is nonsense.

> > Making P4 the default is absolutely not acceptable. P4 is shit.
> 
> As I said Fedora already did this. Also, remember that during
> 2002~2003 P4 was the fastest CPU but nobody call Athlon "shit" then.

P4 has _never_ been the fastest cpu. Anyone who says otherwise is
lying. Our (mplayer-based) tests show that P4 at 1.8 ghz is about same
speed as athlon as 1.0-1.2 ghz, at best.

Get lost, Intel fanboy.

Rich




More information about the MPlayer-dev-eng mailing list