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

[Zuxy]

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. The case that you've
pointed out does exist, but is extremely rare, and compilers always
generate SAL instead of ADDs.

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.

> 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.

Well, just leave it "i686" does no harm.

--
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6