“The older I get, the faster I was.” – popular racing driver’s adage
Some engineering designs, like some felons, are just born bad. Others start out bad but eventually turn themselves around and come out fine. And some become spectacular successes, despite their inauspicious beginnings.
Take the Porsche 911. It is perhaps the world’s most iconic sports car, immediately recognizable all over the world. After more than 50 years, the 911 retains its odd egg-shaped body style and peculiar rear-engined architecture. It started out as a terrible idea, really, probably fueled by too many Hefeweizen. “Hey, Ferdinand, instead of mounting the engine in the front, let’s hang it way out in the back behind the rear axle! Then we’ll put the trunk in the front! It will confuse mechanics and gas station attendants for years!”
Not to mention killing drivers. Early 911s were so imbalanced that it was difficult – not to say dangerous – to drive one with any alacrity. Their tail-happy nature made them challenging pieces of equipment to master. An overconfident and/or under-talented 911 driver could easily find himself watching the scenery get blurry before making expensive acquaintance with a roadside tree, stone wall, or neighbor’s hedge. No less an authority than Hunter S. Thompson called it an “ass-engined Nazi slot car.” Oversteer, thy name is Porsche.
But if you could master the 911’s idiosyncratic handling, it was a very fast car, indeed. The company built a reputation for bulletproof reliability (when their cars weren’t wrapped around trees), combined with nimble cornering and fantastic brakes. The company has won more championships than any carmaker in the world, even Ferrari. (Fun fact: The name Porsche is pronounced with two syllables, not one. There are no silent letters in German.)
Fifty years of tweaking has made today’s 911 far different from that original design. The engine still weighs down the back – and it’s still a terrible idea – but Porsche’s engineers have managed to wrestle, cajole, and finesse that initial design debacle into a contemporary classic. They’ve turned a sow’s ear into a silk purse.
I’ll bet Larry Ellison has at least one 911.
The Executive Chairman of the Board and Chief Technology Officer at Oracle made the decision back in 2009 to acquire Sun Microsystems. That move catapulted Oracle into the hardware business, whereas before it had been just a software company. Sort of like Microsoft acquiring Nokia. (On second thought, no – that’s an unflattering comparison.)
For its $5 billion outlay, Oracle got all of Sun’s workstation hardware, as well as Java and some other interesting technologies. Oracle could now sell “engineered systems” (its term) that combined hardware and software all bundled together. The good news is, Oracle got all of Sun’s hardware business. The bad news is, Oracle got all of Sun’s hardware business.
You see, Sun’s workstations were based on Sun’s own microprocessor architecture, called SPARC (for Scalable Processor ARChitecture). Back in the heyday of interesting and unusual CPU architectures, SPARC looked like it was going to be one of the big winners. It was even licensed to other chip companies, just like ARM and PowerPC, and before MIPS started doing so. SPARC was an A-Lister.
Now, not so much. SPARC has become an Oracle-only thing. One by one, the SPARC licensees have backed away from the CPU family, citing performance and cost reasons. Even long-time SPARC stalwart Fujitsu appears to be having second thoughts, announcing that it will base its next supercomputer on ARM – of all things! – instead of SPARC. When your ultra-high-end system doesn’t use your own high-end processor, it doesn’t look good.
So what is SPARC’s problem? It started with a great idea, then a bad idea, then was (almost) rescued with great engineering. SPARC’s foremost architectural conceit is the idea of “register windows.” It’s a slick idea that leverages the fact that software subroutines are constantly passing parameters back and forth. We’re all familiar with parameter passing, and most CPU chips do that either by passing a single pointer to a memory array, or, for smaller arrays, by passing values through a set of registers.
In an x86 processor, for example, you might pass parameters through the AX and BX registers. Or in a MIPS processor, the compiler probably uses a0–a3. Whatever the CPU, parameter passing is a major portion of what every compiler or assembly-language programmer does. So it’s important to do this quickly and efficiently.
SPARC’s registers are organized in a circular queue instead of the usual “flat” register file. It has 32 general-purpose registers like most modern CPUs, but they’re arranged in a loop, so the last register is logically (and sometimes physically) adjacent to the first register. Only some of those registers are visible to software at any one time, however, and the “window” of visible registers shifts slightly with every subroutine call or return. It’s wonderfully clever and efficient: Instead of pushing, popping, storing, and restoring parameters with every function call, SPARC simply leaves the data where it is and shifts the view into the register file. A calling routine can stuff a value in R5 (for instance) and it will magically appear to the called routine in R12. Results are passed back to the caller in the reverse manner, when the register window is “unwound” in the other direction.
You can tell that this mechanism was designed by software people. And that’s partly the problem. It turns out that SPARC’s register windowing feature is fiendishly difficult to implement in hardware. It creates a nightmare tangle of multiplexers and datapaths that, ironically, become the critical timing path for real-world SPARC implementations. So the very feature that was designed to speed up frequent parameter passing turns out to be its Achilles Heel.
At relatively low clock speeds, like those prevalent at SPARC’s inception, this wasn’t a problem. Or at least, it wasn’t apparent. But as CPU clock frequencies rose, SPARC chips became more and more difficult to design, test, and fabricate. Even Intel’s byzantine x86 architecture could outpace SPARC, and x86 is arguably the most fiercely complex CPU in captivity. Intel’s chips were also a lot cheaper – something you don’t hear very often.
SPARC was getting spanked. Apart from Oracle itself, SPARC processors weren’t all that interesting to other hardware designers. Which means that there were no more SPARC licensees to help to defray the cost of new SPARC development, leaving Oracle to eat all of that R&D expense itself. Worse, Oracle’s systems were starting to look a little expensive compared to the price/performance ratio of other vendors’ systems. “So what, exactly, am I paying a premium for, again?”
The price differential was particularly stark at the (relatively) low end of Oracle’s system business. It’s hard to compare the prices of exotic supercomputers, but cross-shopping standard enterprise web servers is no big deal, and that’s where generic x86-based systems were starting to look pretty attractive compared to Oracle’s offerings.
The solution was to create a simpler, more cost-effective SPARC processor and wrap some new systems around it. Say hello to S7, Oracle’s version of Celeron, Sempron, or Aptiv. It’s an eight-core processor, implemented as two clusters of four CPU cores each. (This arrangement suggests that there might be an even cheaper four-core version of S7 in the future.) For SPARC aficionados, S7 is essentially a stripped-down version of the existing M7 chip, with one-quarter the number of processor cores. Both chips share the same internal CPU microarchitecture, 20nm fabrication technology, cache organization, encryption accelerators, and other features. Unique to the S7 are its on-chip memory controller and its 4.27-GHz clock rate.
The S7 was supposed to have InfiniBand interfaces on-chip. And, technically, it does. They’re just not bonded out, so they’re totally unusable. Oracle admits that testing and certifying the complex InfiniBand interface would have taken more time than they wanted to spend, so they punted and went with Ethernet instead. If you’ve really got your heart set on InfiniBand, Oracle can presumably make it a priority for you.
The new S7 processor certainly seems like a move in the right direction. Eventually, customers always figure out when they’re overpaying for hardware that’s not significantly different from everyone else’s hardware. (Some smartphone suppliers excepted – cough.) So in order to forestall defections to Dell or HP, Oracle needed a value-priced alternative, while still preserving its customers’ investment in SPARC software and infrastructure. Scaling back the existing M7 design was an easy way to do that without funding an entirely new CPU-design project.
The first SPARC processor debuted in the late 1980s, so it’s about half the age of Porsche’s earliest 911. Both were saddled with hideous birthmarks, but both seem to have (mostly) overcome it. Maybe after another 25 years of tweaking, Oracle will be able to fine-tune its machines to be as desirable as those from Zuffenhausen.
10 thoughts on “POS: Porsche, Oracle, and SPARC”