[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: i486 base architecture



Pekka Pietikainen wrote:

On Sun, Nov 28, 2004 at 05:54:43PM -0500, Jeff Spaleta wrote:


On Sun, 28 Nov 2004 17:47:35 -0500, William M. Quarles

What kind of pain are we talking about here?


just as importantly... what kind of gain do you expect to see?
Since the issue raised was gain to pain.... is there really any useful
gain in moving to i486 as the base arch?


Indeed:

http://www.ee.oulu.fi/~pp/faqentry

(submitted to the fedora faq some time ago, didn't hear anything back and it's
potentially a bit too complex for that context).

For the instruction set bits, Chapter 17 of http://www.intel.com/design/pentiumii/manuals/243192.htm
has details on the instruction set differences between the different x86
iterations.


Just some ballpark figures on how often gcc gets to use these instructions, and this is glibc which might have used these in handcoded assembly:
(objdump --disassemble /lib/i686/libc.so.6 | grep <instruction> |wc -l )


cpmxchg:7
xadd: 8
bswap: 136
cmov: 1099 (and this already limits us to non-VIA C3 i686)
Total lines: 297992



Interesting.


However, grep does not take into account which code paths do what, I'm sure
that run time statistics would be more revealing. Perhaps there might be some way
to trick oprofile into revealing how often the instructions are actuall used, dunno.


Doesn't take into account how often this code is called and how much slower the i386 instruction set alternative is in reality. My guess is
"unmeasurable".


What you said ;-)

Perhaps, only objective tests can reveal all.

Someone feel like doing an experiment on some real code, glibc isn't really
representative of typical code? Just compile some large package
with different -march= options (keeping mtune at pentium4) and see what
non-i386 instructions it actually generates. Bonus points for listing the functions and showing whether they are in the oprofile/gprof top #10
or not.





All that being said, just about the only remaining impediment to claiming that FC4
is "Only i486 and above." is the "i386" string in the package file names and directory
structures. Most, if not all, of the packages in RH distros have been compiled with
tunings more appropriate for i486 and above for years. Which shouldn't surprise,
because that's what most users are using. And it also shouldn't surprise that there
are indeed instructions that have crept into various packages that preven execution
on i386, rdtsc in rpm (so I don't have to stare at gettimeofday in straces) comes to mind,
as there are very very few operational i386 boxen within RH these days, and hence no
explicit QA checks for only i386 appropriate instructions.


Changing "i386" in package file names everywhere is a great deal of pain for
almost no gain imho.

73 de Jeff


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]