Bug 124008

Created attachment 100462 [details]
Pentium II separation patch

The 2.6 kernel includes optimization for the Pentium II processor
separate from the the Pentium Pro.  This patch does the same thing for
the 2.4 kernel (it also corrects the gcc -march flag for the Pentium
w/MMX processor, although I doubt that it would make any difference in
the resulting kernel).	It is to be applied inside the kernel source directory
(patch -p1 <pentium2.patch).

As far as I know the flag doesn't actually do anything differently in
nowadays gcc though. (Not surprising since a pII is basically the
exact same core as the Pentium PRO, with the exception that the pII
has MMX added to it)

There obviously is an open matter about which one of the tuning flags
is best for a generic distribution; we're leaning towards optimising
for a pentium 4. The pentium 4 has some instruction sequences it
really doesn't want, and optimising for p4 will avoid those. Yet code
optimized that way will run fast on pII/PIII as well...

There is one instruction/feature that is non-MMX that is different
between the Pentium II and the Pentium Pro.  What it is, I cannot
recall, I'll have to look through my mail archives.  I figure that the
kernel team wouldn't have bothered separating the two processors

In regards future release tuning flags... I'm going to go on a
tangent, since you did, too.  It would be nice if RPM was finally
updated to support the other P6 and post-P6 processors, as well as
i586-MMX.  I know that back in 1999 the gcc team was working to
include MMX and SIMD instructions.  I assume that they are done by
now.  Something that I would suggest for future releases of Fedora
Core is that programs that could obviously benefit from the newer
multimedia enhancements (let's say Xine, FLAC, XMMS, and Vorbis for
example) have RPMs built for them that make use of the new instruction
sets.  For example:
xmms-1.3.x-1.i386.rpm
xmms-1.3.x-1.pentium2.rpm

would be a good choice, because that gives people their MMX
instructions, and most people using MMX probably have a Pentium 2 or
later.  Or, if you decide to get really generous:
xmms-1.3.x-1.i386.rpm
xmms-1.3.x-1.pentium-mmx.rpm
xmms-1.3.x-1.pentium2.rpm
xmms-1.3.x-1.pentium3.rpm
xmms-1.3.x-1.pentium4.rpm
xmms-1.3.x-1.athlon.rpm

I know that this looks like a lot of extra packages to have to include
on an installation disc, but there are only a few programs in Fedora
Core that would need this, and I think that it might be worth it. 
Even just including an i386 and a pentium2-optimized version of each
multimedia rpm would make a big difference for people.  This would
also give a good punch-in-the-nose to people who say that Linux is not
good for multimedia stuff.  I know that many of the projects are
behind on including instructions that are more up-to-date, but maybe
you can give them a kick in the right direction.

CORRECTION:

would be a good choice, because that gives people their MMX
instructions, and most people using **XMMS** probably have a Pentium 2
or later.

media players and the like usually detect the cpu and runtime and
adapt accordingly. Compiling it for a specific CPU probably wouldn't
buy you much given they typically have hand-written assembly for each
CPU for the important time-critical functions.

Additionally, I'd be _very_ surprised if you could find a
benchmarkable difference between a generic 686 kernel, and a
pentium-II targetted kernel.  The overhead of having to distribute
extra kernel images (given that we've gone through a lot of effort to
actually ship _less_ images in recent times) makes it very doubtful
that fedora core will ship a pentium ii kernel.

again, for a lot of speed critical stuff, the kernel will adapt
accordingly. If a CPU is capable of using SSE, it will use it for
example.  The RAID5 routines are a good example of this, it benchmarks
several routines during boot up and chooses the fastest.

I wasn't suggesting that you distribute a Pentium II optimized kernel.
 Far from it.  I was only talking about alternate versions of media
players on the like.

As for the kernel, I was just suggesting that you add the patch for
those interested in building one from the kernel-source package.

I'm surprised that this report has gotten so much attention,
especially on a weekend, for a mere enhancement priority, when several
other higher priority bugs that I have reported or have contributed to
haven't received any response at all.  One of them is approaching its
first birthday.