I think the biggest factor is that supersparc can issue 3 instructions vs 2 for the hypersparc. Also the cache (I think) on the ross setup shares 1M for each module but at 2:1, where as supersparcs have a 1:1 cache ratio.
Probably on single threaded tasks like compiling or setting up a box for some paticular service (ftp/mail gateway/etc) the ROSS configuration makes sense. I use my SS20 more for just piddling around with the typical desktop setup, so X11, blackbox/CDE, xmms, a few glib programs (which really stress the platform), etc...so again, heavily threaded and lots of context switching.
I would really like to experiance a sparcserver 1000e with 8 SM8/91s
The quad 142s have 4x 1MB.
The numbers don't add up (i.e. an over simplified calculation like 3*85 vs 2*142), the HyperSparc should at least match the SS and usually well exceed it because the amount of ILP going on wont be 100%, especially on an in-order CPU.
I've been digging around the NetBSD code and it looks like the HS might dump all cache on context switches(?!) which would murder performance, but maybe I understood the code wrong or it's a NetBSD specific hack.
Another quite probable explanation is that the compiler optimizations in Solaris favored SS.
Not that SS isn't awesome, I just think something must be fundamentally wrong for what are essentially much newer hotrod/upgrade processors (142/1M, 180/512, 200/512) to be slower in common usage.
Fuel, Indy R5kIBM
RS/6000 7006-42T, 7011-250, 7012-397, 7012-G40 (upgraded to 4x 200MHz PPC), ThinkPad 710TE vintage tablet, ThinkPad T400, various System X, NetVista 2800Sun
Ultra 27 Xeon Quad Core 3.20GHz, Sunblade 2500 Silver, SunFire V445HP
- IBM Retrohttp://www.kev009.com/
- BlogFree Usenet access for comp.*
heirarchy. Send me a message for posting access.