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
