i486 base architecture

[Jeff Johnson]

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