You should never mention benchmarks basing on distant memories.
Yesterday I reran the byte benchmark using out of the box RedHat 6.2,
with egcs and the -O3 flag and varying the -m flag from -m386 to
-mpentiumpro. The box was a PII 400 with 64 Megs of Ram.
The difference between the slowest and fastest run was:
-Memory index: 3%
-Integer index: 15%
-Floating point index: 5%
So for software who is integer intensive it could make sense to
produce specific RPMs for PIIs. (Provided egcs does not generate
buggy code with -mpentiumpro).
Another interesting point is how the benchmarks ranked: PPro was the
fastest by a wide margin, then very close together 386, 486 and
pentium in that order. Yes optimizing for pentium when your box is a
pII not only gives no benefits but instead incurs a small slowdown.
Retrospectively this is logic since the plain pentium was a processor
who had plenty of optimizing gotchas who made it very sensitive to
instruction reordering or smart insertion of NOPs in the code. That
was the reason Pentiums were 50% slower on the bogomips loop than a
486 of the same clock speed. It also had one of its two excution
units who was not able to perform multiplications and divisions so in
occasions you had to insert useless NOPs in order to ensure a sum
would not go through the universal execution unit and have it let this
unit available for the multiplication who followed it. Since the
comparatively poor performance of the Pentium on old code was
exploited by Cyrix marketing it is probable that one of the design
goals of the PII was not needing unnatural code for getting optimal
or near optimal performance and thus the quirks you needed to
introduce in your code when writing for Pentium are only a waste of
time on PIIs.
--
Jean Francois Martinez
Project Independence: Linux for the Masses
http://www.independence.seul.org
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
