UltraSPARC Sucks.

February 13, 2004 - Reading time: 3 minutes

I have officially decided that Sun's computing platform, and in particular the UltraSPARC processor, suck. Also, there is no good OS to run on it. Solaris is one of the worst operating systems I've ever tried to use, and Linux has horrible SPARC support.

But back to the UltraSPARC, Sun's flagship pile of ass. Here's a chip that has changed minimally, architecturewise, since its introduction. To push the chip's clock speed past 1GHz (when Intel and AMD were tossing out 2GHz+ chips as fast as people would buy them), TI had to use a six-layer copper interconnect process -- the Pentium 4 and Athlon chips only use 4 layers. The fact is, for the last 10 years or so, the UltraSPARC has been the slowest RISC chip out there. Sun has relied on anti-Microsoft and anti-PC sentiment to sell computers, not technical features or performance.

And the UltraSPARC-III? It's just a mildly-tweaked UltraSPARC-II, with slightly more more cache, and slightly faster clocks (though still not up to par with any competition). And don't get me started on the circular register file. Too late, I'm started:

SPARC chips expose 32 registers to each program, but the registers are actually a window into the larger set of registers -- the rest are hidden from view until you call a different subroutine, function, or program. The idea was that where other processors would push parameters onto a stack and let the called subroutine pop them off, here the SPARC processor will slide (rotate) the window to give the new subroutine a fresh set of registers. The old and new windows overlap, so some registers are shared. Neat in concept, but not so neat when you actually implement it. For one thing, it's still a finite number of registers, so when you run out it's back to pushing and popping like normal processors. And since you don't have a full view of the register, you can't predict when the register will underflow or overflow, so performance can be unpredictable, especially under heavy loads. Oh, yea, the processor doesn't handle under/overflow in hardware; it generates a software fault instead, so the OS has to handle it (using lots more cycles). Yay! The window sliding method also requires hugely complex multiplexers and register ports so that any physical register looks like any logical register.

Not to mention that the physical register layout is stupid, and requires a huge amount of extra wiring because it forms a ring around a large chunk, but not all, of the rest of the processor, so you've got to run interconnects over, around, and through the register file.

Anyway, the point is that the UltraSPARC sucks. I'll get into this a bit more later tonight, but first I'm going to eat.