Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview]

[Andrew Gabriel]

Joseph Kowalski wrote:
> John Plocher wrote:
>> [Roland and I are bouncing a proposal back and forth...]
>>
>> Garrett D'Amore wrote:
>>> 4) analysis of big-picture performance issues, if any (does 64-bit 
>>> run faster, or slower?  maybe run a some test of boot time analysis.)
>>
>> IIRC, the SPARC impact was "doesn't run faster" combined with
>> "takes more disk space", rather than "runs significantly slower".
> 
> +1
> 
> ARC review is only to cover speed and size issues when they are large 
> enough to have some architectual impact.  In my estimation, these don't 
> qualify.

Who decides what's an acceptable performance drop in Solaris sparc?
What would be your boundary at which speed becomes an issue?

When I first measured the hit on 64 bit sparc binaries for one of my own 
CPU intensive (integer) applications some years back, 64 bit was 14% 
slower than a 32 bit build. Having just repeated this test using Studio 
12 compilers, its down to 7% slower now. This isn't a scientific test, 
and needs measuring more accurately than I can at home on one system, 
and on different types of sparc we have around today.

When I asked (again, many years ago) why we ship a 64 bit ls(1) but 
don't use it (i.e. it's not isaexec'ed), the answer I got was that this 
did nasty things to one of our performance metrics. (Not clear to me if 
that was due to the 64 bit ls(1), or the isaexec indirection).

So I think ARC needs to know that the performance hit is below whatever 
level it (or someone) decides is the largest acceptable hit. Some of 
that sounds like a decision that needs Marketing input.

-- 
Andrew