Chris's Wiki :: blog/tech/Whyx86WonVsRISC

My view on why CISC (well, x86) won over RISC in the end

April 15, 2012

One of Tanebaum's now-famous three predictions in the Tanenbaum/Torvalds debate was that x86 would die out and be replaced by RISC architectures. Some of you may be tempted to immediately laugh at this prediction, but before you do that you should remember the historical context; specifically, that this prediction was made in 1992. Back then this looked like a very good bet, one so good that Intel made it itself with the Itanium. RISC was everywhere, the x86 architecture was low end and not very well performing, and so on. So what happened on the way between 1992 and now?

In my view, there are two major reasons and one moderate reason why the x86 architecture has proven to be evergreen and why RISC never overtook it, especially traditional 1992-style RISC (note that ARM is not a 1992 style RISC).

The first reason is that people (vastly) underestimated how far x86 performance could be pushed with enough effort. I'm not sure if specialists in 1992 could have made a good prediction of future x86 performance, but certainly the general computing perception was that x86 performance and CISC performance in general were fundamentally limited by the complexity (and limitations) of the architecture. RISC was designed to go real fast, and CISC just wasn't.

The second reason is that people vastly underestimated how much money there would be in increasing x86 performance. Pushing x86 performance to its current heights has required absurdly large amounts of money; back in 1992 you had to be at least somewhat contrarian and open-minded to see that for various reasons x86 was going to have this huge amount available to improve it. I think it might have been possible to see the wave coming but it certainly was far from obvious or easy.

(Once again, note that even Intel missed this as late as 1994, when it started the whole Itanium dead end.)

The moderate reason is the issue of memory bandwidth and latency. Traditional RISC designs have larger instructions than x86 and need more of them to get the same amount of work done; this puts more pressure on caches and demands more memory bandwidth. Memory access speed was not seen as a big concern back in 1992, but it has become an increasingly important one since then and this favours architectures with compact instruction encodings (even if this results in them being far from regular and easy to decode).

(There is a more general argument that RISC was always a larger bet than it appeared, but that will take another entry.)

Comments on this page:

From 94.194.182.118 at 2012-04-15 14:06:07:

It's my understanding that modern CPUs don't execute the x86 machine code directly, they're actually RISC processors that execute a program that can run and optimise x86 instructions.

I'm not sure where I heard this from (at best it's a simplification of the truth), but it's not unprecedented. Take PyPy for example, it's written with a subset of python that runs and optimises standard Python, yet it outperforms CPython. It might sound like witchcraft, but it's easier to optimise this way, rather than dealing with (relatively) low level code.

--M

By nothings at 2012-04-18 17:28:01:

I see your two reasons really being linked in another (debatably) "simpler" reason:

Intel had deep pockets and a massive x86 userbase. That means they were able to outspend everyone else in terms of chip process; Intel chips were generally always a generation (or two?) ahead of the RISC processors, which means they had many more transistors for the same sized chip (and costing about the same in cost of goods).

That meant Intel could burn transitors on the CISC-to-RISC translation without having to make any visible sacrifices, and still have more transistors. (It did cost them extra cycles to perform that translation, but because it's hardware, those cycles could execute in parallel most of the time.) This made it easy to compete with the fastest RISC chips (the DEC Alpha, I guess.) And it's not like CISC-to-RISC was unknown in 1992; the first pipelined implementation of the VAX was the MicroVAX Rigel chip released in 1989 http://en.wikipedia.org/wiki/Rigel_%28microprocessor%29 , which was essentially doing the same CISC-to-RISC that Intel would undertake with the Pentium Pro.

Over time, as CPUs spent more and more transistors on making single-threaded code fast (e.g. with out-of-order execution), the CISC-to-RISC translation unit also became a tiny, nearly invisible part of the chip (in terms of transistors), and yet Intel still had a process advantage. (Now that we are going multicore, that's not true; the amount of chip resources spent on CISC-to-RISC grow with the number of cores.)

Of course, it's true Intel also had a process advantage for Itanium, so the story is a little more complex, and probably biased towards 'desire for x86 compatibility' (although the Mac certainly was able to switch processors, so I'm not sure it would have been impossible for Windows to have, so I think it may also just have been just a bad design in Itanium--something Intel was certainly capable of, witness the Pentium 4).

By cks at 2012-05-21 00:05:25:

Department of belated replies: I put my commentary into an entry, Whyx86WonVsRISCII.

Written on 15 April 2012.

«	The wiki trap (that we've fallen into)

What you need for migrating web content