not so random musings and mutterings about high performance computing, business, entrepreneurship, and the economy

HPC in the first decade of a new millenium: a perspective, part 2

The death of RISC …

obligatory Monty Python Holy Grail quote:
old man: I’m not dead yet, I think I’ll go for a walk
John Cleese: Look, you are not fooling anyone …

The RISC vendors (SGI, HP, IBM, …) realized that RISC was dead, and that EPIC would be the technology that killed it. I was at SGI at the time, and disagreed that EPIC (Itanium) was going to be the killer. I thought it was going to be x86.

My rationale for this were benchmarks that I had been running on systems around that time. Some basic testing I did for some projects I was working on at the time, from an email in 2001 (found it recently cleaning out an old/dying machine)

I remember arguing that I couldn’t see a customer spending 20x more for less than a 2x performance delta over the commodity platform. This was around 1999-2000 time frame.

I looked at the data, and I could see RISC was doomed, but tests on EPIC yielded not significantly better than RISC performance, rather, often substantially worse.

And this gets into one of the failure modes I have observed for us in HPC. We have a tendency to sometimes believe our own marketing. Make the underlying silicon less smart, and its a SMOP to build smart compilers that will handle all the heavy lifting to make the silicon roar.

A simple matter of programming.

I used a Multiflow. I remember the day long compilation cycle. No, I am not kidding. A make operation took 1+ days. And often the code would bomb due to bugs in the compiler.

How can we work on systems like that?

In short, you can’t. Its hard to put real smarts into compilers. Most of them are highly focused on not violating language semantics, so much so that the willingly trade potentially beneficial performance optimizations for a more provably correct execution. This is due in part to the mismatch between the languages and the architecture.

A compiler is a transliteration device. Between expression media that don’t completely overlap … there aren’t necessary provable one-to-one and onto mappings between the expression of an algorithm in a particular high level language, and the transliteration of that high level language into low level assembler language for the platform. Making it “smart” should mean that it can “learn” how to do a better job, as well as do a better job of inferring meaning.

I will touch on this later. This is a very important topic. And this is why VLIW systems for HPC are pretty much doomed from inception. But that is for later.

So to recap, at the end of 1999, RISC is generally acknowledged by all but Sun, and a few RISC bigots in high places at companies like SGI, as losing out to a new architecture. Unfortunately for all who put all their eggs in that one basket, Itanium wasn’t to be. But we didn’t know this yet, though a few of us had guessed it. Looking over some of the sent emails in that erased box, it is scary how good those guesses were.