What I see as RISC's big bets

May 4, 2013

At the time, performance oriented RISC was presented as the obviously correct next step for systems to take. Even today I can casually say that x86 won against RISC mostly because Intel spent more money and have people nod along with it. But I'm not sure that this is really the case, because I think you can make an argument that the whole idea behind (performance) RISC rested on some big bets.

As I see them, the main big bets were:

  1. CPU speeds would continue to be the constraint on system performance. This one is obvious; the only part of the system that a fast RISC improved was the CPU itself and that only mattered if the CPU was the limiting factor.

  2. Compilers could statically extract a lot of parallelism and scheduling opportunities, because this is what lets classic RISC designs omit the complex circuitry for out of order dynamic instruction scheduling.

    (Itanium is an extreme example of this assumption, if you consider it a RISC.)

  3. People would recompile their programs frequently for new generations of CPU chips, because this is a consequence of static scheduling and newer CPUs have different scheduling opportunities from older ones. If you can't make this assumption, new CPUs either run old code unimpressively or need to do dynamic instruction scheduling for old code. Running old code unimpressively (if people care about old code) does not sell new CPUs.

The third bet proved false in practice for all sorts of pragmatic reasons. My impression is that the second bet also wound up being false, with dynamic out of order instruction scheduling able to extract significantly more parallelism than static compiler analysis could. My memory is that together these two factors pushed later generation RISC CPU designs to include more and more complex instruction scheduling, diluting their advantages over (theoretically) more complex CISC designs.

(I'm honestly not sure how the first bet turned out for fast RISC over its era (up to the early 2000s, say). CPUs weren't anywhere near fast enough in those days but my impression is that as the CPU speed ramped up, memory bandwidth and latency issues increasingly became a constraint as well. This limited the payoff from pure CPU improvements.)

I don't see the RISC emphasis on 64 bit support as being a bet so much as an attempt to create a competitive advantage. (I may be underestimating how much work it took AMD to add 64 bit support to the x86 architecture.)

Update: I'm wrong about some of this. See the first comment for a discussion, especially about the out-of-order issue.

Comments on this page:

From at 2013-05-04 08:47:32:

I'm afraid I think you are skewing history a bit.

Point 1 is fair enough (although many RISC machines were expensive, with high-end memory and storage subsystems in order to compliment the high-performance CPUs).

Point 2 is revisionist. Back in the early 90s, there was a debate within the RISC world about the relative merits of the Speed-demon designs (in-order with high clock rates) versus Brainiac designs (lower clock rate, but wider issue and OoO). The early Alphas (21064, 21164) were the epitome of the speed demon design. POWER was the most Brainiac. So it's hard to agree that RISC was betting on a statically-scheduled in-order approach, when RISC microprocessors were pioneering OoO a few years before the Pentium Pro came along. And the classic RISC families all went to OoO at some point (e.g. the Alpha 21264).

Of course, the Pentium Pro did come along, and showed that an x86 could borrow all the best tricks from the RISC brainiacs, and get a respectable clock speed too. Furthermore, Intel was able to aggressively ramp that clock speed, and achieve low costs through high volumes. The rest is history.

(As for Itanium, I think its craziness overwhelms any categorization. It did make big bets, but it was clear that those bets had lost even before the first models were released. It has been suggested that Itanium would have gone OoO if it had actually succeeded, rather than merely lingering for the sake of contractual obligations.)

Point 3 has some truth to it, but I would disagree that it was a big bet of RISC. Rather, it was a function of the market niche that classic RISC was confined to: Customers that paid tens or hundreds of thousands of dollars for a high-performance RISC machine would be willing to recompile their code to eke out the best possible performance. x86 has had its performance blunders too (the PPro didn't run win95 well due to slow handling of segmentation; the Pentium 4 had serious performance wrinkles despite being OoO; and the less said about Atom the better). But performance on existing software is critical for x86. So the market issued its verdicts in those cases, and Intel obeyed (still waiting for that part with Atom...).

The term RISC has to be understood in the context of its age (i.e. the late 80s and early 90s). It's hard to come up with a definition of RISC that works well much beyond that time frame. But the microarchitectural techniques pioneered in those years in the RISC world still define computer architecture today.

By cks at 2013-05-05 00:47:59:

My RISC education is very much MIPS/Alpha and only vaguely Power, so I seem to have soaked up a bunch of speed-demon propaganda by osmosis (even if I laughed sadly at some early speed-demon bits as terrible ideas in practice, as indeed they turned out to be). My mythology of the Alpha evolution in particular is one where the Alpha designers had to give up more and more of their (speed-demon) ideas and complicate their CPU designs to deal with the failure of those ideas in practice.

I disagree with your view on my third point. The long version of why is in PervasiveRISC; the short version is that RISC was originally aimed much more broadly than just narrow high performance computing applications where you could easily make that assumption.

(I'm not even sure it's true in practice for a lot of real HPC, especially in academia, but that's another large can of worms and I'm probably biased by being exposed to the academic side instead of the commercial side.)

From at 2013-05-07 20:58:11:

I remember the initial Alpha article in CACM explicitly mentioned the lack of branch delay slots was because they weren't assuming #3, so at least by then (1992-ish?) this was not universally true.

-- nothings

From at 2013-05-31 02:53:07:

The real idea of RISC was: spend your transistors wisely. Make design decisions with support from measurements.

RISC could get more capabilities on-chip than CISC. Think (at various times): 32-bit ALU, 64-bit ALU, reasonable cache, MMU, large register files, wide memory busses.

Eventually, the transistor budgets were so high that instruction set architectures didn't matter. And the CISC processor designers learned how to spend their transistors wisely.

On the low end (ARM territory) RISC still has a significant advantage. But Intel keeps trying to move down to squash it (Atom variants). Since a good Atom would also cannibalize Intel's mainstream processor market, they are fighting with self-imposed limitations (Innovator's Dilemma).

I guess that the budget in question now is thermal, not transistor.

Written on 04 May 2013.
« Virtual disks should be treated as 4k 'Advanced Format' drives
The original vision of RISC was that it would be pervasive »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat May 4 03:02:46 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.