Why Do We Use x86 CPUs?

bluefoxlucid asks: "With Apple having now switched to x86 CPUs, I've been wondering for a while why we use the x86 architecture at all. The Power architecture was known for its better performance per clock; and still other RISC architectures such as the various ARM models provide very high performance per clock as well as reduced power usage, opening some potential for low-power laptops. Compilers can also deal with optimization in RISC architectures more easily, since the instruction set is smaller and the possible scheduling arrangements are thus reduced greatly. With Just-in-Time compilation, legacy x86 programs could be painlessly run on ARM/PPC by translating them dynamically at run time, similar to how CIL and Java work. So really, what do you all think about our choice of primary CPU architecture? Are x86 and x86_64 a good choice; or should we have shot for PPC64 or a 64-bit ARM solution?" The problem right now is that if we were going to try to "vote with our wallets" for computing architecture, the only vote would be x86. How long do you see Intel maintaining its dominance in the home PC market?

Comments

Easy

[Short Circuit]

Until someone replaces the PC.

PC architecture sits in a local minima where the fastest route to greater profits lies in improving existing designs, rather than developing new approaches.

The reason "We" use x86 is because "we" use PCs, where x86 technology is dominant and obvious. However, "we" also use PDAs, cell phones, TiVos and even game console systems. As the functions of those devices melt into a new class of unified devices, other architectures will advance.

The real irony is that, for most of these other devices, the underlying architecture is invisible. Few know that Palm switched processors a few years back. Fewer still know what kind of cpu powers their cell phone.

Re:Easy

[SheeEttin]

Fewer still know what kind of cpu powers their cell phone.

I think mine is silicon-based.

Re:Easy

[HappySqurriel]

The reason "We" use x86 is because "we" use PCs, where x86 technology is dominant and obvious. However, "we" also use PDAs, cell phones, TiVos and even game console systems. As the functions of those devices melt into a new class of unified devices, other architectures will advance.

Honestly, I think it is much simpler than that ...

The problem has very little to do with the processors that are used and is entirely related to the software that we run. Even in the 80s/90s it would have been completely possible for Microsoft to support a wide range of processors ( if their OS was designed correctly ) and produce OS related libraries which abstracted software development from needing to directly access the underlying hardware; on install, necessary files would be re-compiled and all over the shelf software could run on any architecture that Windows/dos supported. In general, the concept is combining standard C/C++ with libraries (like OpenGL) and recompiling to ensure that no one was tied to a particular hardware architecture.

Just think of how many different architectures Linux has been ported to, if DOS/Windows was built in a similar way you'd be able to choose between any architecture you wanted and still be able to run any program you wanted.

Re:Easy

[Marillion]

Windows NT was designed to run on i386, MIPS, PPC and Alpha. Over the years, Microsoft discontinued support for the various platforms - IIRC MIPS and Alpha ended with NT3.51 - PPC ended with NT4. NT5 (aka - Windows 2000) was the first i386 only version of NT.

Re:Easy

[ergo98]

Windows NT was designed to run on i386, MIPS, PPC and Alpha. Over the years, Microsoft discontinued support for the various platforms

At the time Microsoft was hedging their bets as everyone ranted about the next generation of RISC chips storming the market. Endlessly we'd hear about how the x86 line was dead, and the only improvements would be to move to the next generation (Intel themselves was heavily focusing on RISC as well -- think of the i860).

We never did because those alternatives never delivered on their promise. Ever since 680x0 processors, the highest performance per dollar crown has been held, with only a couple of very short term or niche exceptions, by the x86 line. When given the option of running software on a variety of platforms, customers always ended up buying the x86.

Look at Linux -- so many platforms supported, yet on the desktop and up level, overwhelmingly it's run on x86. This has been the cast over its history.

Re:Easy

[king-manic]

At the time Microsoft was hedging their bets as everyone ranted about the next generation of RISC chips storming the market. Endlessly we'd hear about how the x86 line was dead, and the only improvements would be to move to the next generation (Intel themselves was heavily focusing on RISC as well -- think of the i860).

We never did because those alternatives never delivered on their promise. Ever since 680x0 processors, the highest performance per dollar crown has been held, with only a couple of very short term or niche exceptions, by the x86 line. When given the option of running software on a variety of platforms, customers always ended up buying the x86.

Look at Linux -- so many platforms supported, yet on the desktop and up level, overwhelmingly it's run on x86. This has been the cast over its history. Part of the problem is the consumer thinks "I've spent X$ on software. If I move to platform B I would have wasted X$." so on of the primary reasons we're still with x86 is investment in software.

As for linux. choice isn't good. People get overwhelmed easily. So anythign more then 2 or 3 choices makes them go cross eyed and buy windows. I myself operate mostly on windows occasionally on red hat/mandrake and very rarely mac OSX.

Re:Easy

[Pollardito]

Fewer still know what kind of cpu powers their cell phone.

I think mine is silicon-based. trust me, it's real and it's fantastic

easy

[exspecto]

because they don't cost an ARM and a leg and they don't pose as much of a RISC

momentum

[nuggz]

Change is expensive.
So don't change unless there is a compelling reason.

Hard to optimize? You only have to optimize the compiler once, over the millions of devices this cost is small.

Runtime interpreter/compilers, you lose the speed advantage.

Volume and competition makes x86 series products cheap

Re:momentum

[Frumious Wombat]

If you're dead-set on using GCC, yes. Alternately, if you use the native compilers which only have to support a fairly narrow architecture, you can get much higher performance. XLF on RS/6K and Macs was one example (capable of halving your run-time in some cases), IFORT/ICC on x86 and up, or FORT/CCC on DEC/Compaq/HP Alpha-Unix and Alpha-Linux were others. Currently GCC is not bad on almost everything, but native-mode compilers will still tend to dust it, especially for numeric work.

Which brings back the other problem; not only are x86 chips cheap to make, but we have 30 years of practice optimizing for them. Their replacement is going to have to be enough better to overcome those two factors.

Re:momentum

[Chris Burke]

You're absolutely right, it's all about momentum.

Hard to optimize? You only have to optimize the compiler once, over the millions of devices this cost is small.

This is a red herring anyway. RISC being simpler has nothing to do with it being easier to optimize. If it is easier for a compiler to optimize simple RISC-like instructions, then the compiler can use RISC-like instructions that are present in x86. This has been the situation for years and years. Compilers use a basic subset of x86 that looks a lot like RISC (minus variable instruction lengths), but also with some of the decent syntactic sugar of x86 like push/pop and load-ops (you know: add eax, [esp + 12] to do a load and add in one inst).

The only real obstacle for compilers optimizing x86 is the dearth of registers. With fast l1 caches and stack engine tricks like in Core Duo the performance hit for stack spillover isn't big, and x86-64 basically solves the problem by doubling the register space. Less than a RISC machine, but enough for what research has shown is typically needed. Maybe still a little too few, but combined with the first point enough to make this a wash.

These arguments are as old as RISC itself, but the basis behind them has changed as the technology has changed. All of the performance, efficiency, and other technical arguments have been put to pasture in terms of actual implementations. In the end, it comes down to this:

The only reason not to use x86 is because it is an ugly mess that makes engineers who like elegance cry at night.
The only reason to use x86 is because it runs the vast majority of software on commodity chips.

Which of these factors dominates is not an open question; it has already been decided. It's just those engineers who like elegance can't accept it, and thus keep bringing it up. Believe me, I don't like it either, but I don't see the point at screaming at reality and demanding that it change to suit my aesthetics.

Why Apple moved to x86

[plambert]

The reason given, which people seem to keep forgetting, was pretty simple and believable:

Performance per watt.

The PPC architecture was not improving _at all_ in performance per watt. Apple's market was growing fastest in the portable space, but it was becoming impossible to keep temperatures and power consumption down with PPC processors.

And IBM's future plans for the product line were focusing on the Power series (for high-end servers) and the Core processors (for Xbox 360's) and not on the PowerPCs themselves.

While I've never had any particular love for the x86 instruction sets, I, for one, enjoy the performance of my Macbook Pro Core 2 Duo, and the fact that it doesn't burn my lap off, like a PowerPC G5-based laptop would.

Re:Why Apple moved to x86

[Wdomburg]

Dual core 2GHz PPC below 25W isn't an improvement I guess? Look at PA-Semi...

You mean a processor from a fabless company announced six months after Apple announced the switch to Intel, and wasn't expected to sample until nearly a year after the first Intel Macintosh shipped? It's an interesting product, particularly if the performance of the cores is any good (hard to say, since there seems to be much in the way of benchmarks), but it didn't exist as a product until recently. Even if it had, there's the significant question of whether they could secure the fab capacity to supply a major customer like Apple.

What home user really cares if their PC takes 150W or 180W ? Nobody...

Desktops aren't the dealbreaker here. Try asking "who cares if their laptop runs for 5 hours or 3 hours?" or maybe "who cares if their laptop can be used comfortably in their lap?" or perhaps "who cares if they can get reasonable performance for photo-editing, video-editing and what not in a portable form factor?".

Cast an eye toward the business market and performance per watt on the desktop is important. You may not care about a 30W savings but an a company with 500 seats may well care about 28800kWh in savings per year (assuming 240 work eight hour work days a year after factoring out weekends holidays and vacation).

Good question...

[kotj.mf]

I just got done reading about the PWRficient (via Ars):

• Two 64-bit, superscalar, out-of-order PowerPC processor cores with Altivec/VMX
• Two DDR2 memory controllers (one per core!)
• 2MB shared L2 cache
• I/O unit that has support for: eight PCIe controllers, two 10 Gigabit Ethernet controllers, four Gigabit Ethernet controllers
• 65nm process
• 5-13 watts typical @ 2GHz, depending on the application

Now I have to wait for the boner this gave me to go away before I can get up and walk around the office.

Maybe Apple could have put off the Switch after all...

Why do we ...

[jbeaupre]

Why do we drive on the right side of the road in some places, left in others?
Why do most screws tighten clockwise?
Why do we use a 7 day calender, 60 second minutes, 60 minute hours, and a 24 hour clock like the Sumerians instead of base 10?
Why do we count in base 10 instead of binary, hex, base 12?
Why don't we all switch to Esperanto or some other idealized language?
Or if you're familiar with the story: Why are the Space Shuttle boosters the size they are?

Because sometimes it's easier to stick with a standard.

There. Question answered. Next article please.

Not a technical reason

[ivan256]

The reason is that intel provides better infrastructure and services that any other high performance microprocessor vendor in the industry. When Motorola or IBM tried to make a sale, intel would swoop in and offer to develop the customer's entire board for them. The variety of intel reference designs is unmatched. Intel not only provides every chip you need for a full solution, but they do it for more possible solution sets than you can imagine. Intel will manufacture your entire product including chassis and bezel. Nobody even comes close to intel's infrastructure services. That is why even when other vendors have had superior processors for periods of time over the years, intel has held on to market leadership. There may be other reasons too, but there don't have to be. That one alone is sufficient.

The other answer, of course, is that we don't always... ARM/xScale has become *very* widely used, but that is still coming from intel. There are also probably more MIPS processors in people's homes than x86 processors since the cores are embedded in everything.

Where The Money Is

[spoonboy42]

There's no doubt that x86 is an ugly, hacked-together architecture whose life has been extended far beyond reason by various extensions which were hobbled by having to maintain backwards compatibility. x86 was designed nearly 30 years ago as an entry level processor for the technology of the day. It was originally built as a 16-bit architecture, then extended to 32-bit, and recently 64-bit (compare to PowerPC, designed for 64-bit and, for the earlier models, scaled back to 32-bit with forward-looking design features). Even the major x86 hardware vendors, Intel and AMD, have long since stopped implementing x86 in hardware, choosing instead to design decoders which rapidly translate x86 instructions to the native RISC instruction set used by the cores.

So why the hell do we use x86? A major reason is inertia. The PC is centered around the x86, and there are mountains and mountains of legacy software in use that depend on it. For those of us in the open-source world, it's not to difficult to recompile and maintain a new binary architecture, but for all of the software out there that's only available in binary form, emulation remains the only option. And although binary emulation of x86 is always improving, it remains much slower than native code, even with translation caches. Emulation is, at this point, fine for applications that aren't computationally intensive, but the overhead is such that the clocks-per-instruction and performance-per-watt advantages of better-designed architectures disappears.

A side effect of the enormous inertia behind x86 is that a vast volume of sales goes to Intel and AMD, which in turn funds massive engineering projects to improve x86. All things being equal, the same investment of engineer man-hours would bear more performance fruit on MIPS, SPARC, POWER, ARM, Alpha, or any of a number of other more modern architectures, but because of the huge volumes the x86 manufacturers deal in, they can afford to spend the extra effort improving the x86. Nowadays, x86 has gotten fast enough that there are basically only 2 competing architectures left for general-purpose computing (the embedded space is another matter, though): SPARC and POWER. SPARC, in the form of the Niagra, has a very high-throughput multithreaded processor design great for server work, but it's very lackluster for low-latency and floating-point workloads. POWER has some extremely nice designs powering next-generation consoles (Xenon and the even more impressive Cell), but the Cell in particular is so radically different from a standard processor design that it requires changes in coding practice to really take advantage of it. So, even though the Cell can mop the floor with a Core 2 or an Opteron when fully optimized code is used, it's easier (right now at least) to develop code that uses an x86 well than code which fully utilizes the Cell.

The Ugly Architecture Runs Well

[forkazoo]

One perspective on the question:

Non x86 architectures are certainly not inherently better clock for clock. That's a matter of specific chip designs more than anything else. The P4 was a fairly fast chip, but miserable clock for clock against a G4. An Athlon however, was much closer to a G4. (Remember kids, not all code takes advantage of SIMD like AltiVec!) And, the G4 wasn't very easy get bring to super high clock rates. The whole argument of architectural elegance no longer applies.

The RISC Revolution started at a time when decoding an ugly architecture like VAX or x86 would require a significant portion of the available chip area. The legacy modes of x86 significantly held back performance because the 8086 and 80286 compatibility areas took up space that could have been used for cache or floating point hardware, or whatever. Then, transistor budgets grew. People stopped manually placing individual transistors, and then they stopped manually fiddling with individual gates for the most part. Chips grew in transistor count to the point where basically, nobody knew what to do with all the extra space. When that happened, x86 instruction decoding became a tiny area of the chip. Removing legacy cruft from x86 really wouldn't have been a significant design win after about P6/K7.

Instead of being a design win, the fixed instruction length of the RISc architectures no longer meant improved performance through simple decoding. They meant that even simple instructions took as much space as average instructions. Really complex instructions weren't allowed, so they had to be implimented as multiple instructions. Something that was one byte on x86 was always exactly 4 bytes on MIPS. Something that was 12 bytes on x86 might be done as four instruction on MIPS, and thus take 16 bytes. So, effective instruction cache sizes and effective instruction fetch bandwidth grew on X86 compared to purer RISC architectures.

At the same time, the gap between compute performance and memory bandwidth on all architectures was widening. Instruction fetch badwidth was irrelevent in the time of the PC XT, because RAM fetches could actually be done in like a single cycle. Less that it takes to get to SRAM on-chip caches today. But, as time went on, memory accesses became more and more costly. So, if a MIPS machine was in a super tight loop that ran in L1 cache, it might be okay. But, it it was just going balls to the wall through sequential instructions, or a loop that was much larger than cache, then it didn't matter how fast it could compute the instructions if it couldn't fetch them quick enough to keep the processor fed. but, X86 absurdly ugly instruction encoding acted like a sort of compression, meaning that a loop was more likely to fit in a particularly sized cache, and that better use of instruction fetch bandwidth was made.

Also, people had software that ran on X86, so they bought 9000 bazillion chips to run it all. The money spent on those 9000 bazillion chips got invested in building better chips. If somebody had the sort of financial resources that Intel had to build a better chip, and they shipped it in that sort of volume, we might well se an extremely competetive desktop SPARC or ARM chip.

What are you on?

[Chibi Merrow]

With Just-in-Time compilation, legacy x86 programs could be painlessly run on ARM/PPC by translating them dynamically at run time, similar to how CIL and Java work.

Do you really believe that? If so, how does one get to this fantasy land you live in? This may be true sometime in the future, but that day is not today.

I happen to own a PowerBook G4. I like it very much. I love nice little purpose-designed chips based on POWER like the Gekko in the GameCube and it's successor in the Wii. But until we're at a point where you can effortlessly and flawlessly run everything from fifteen year old accounting packages to the latest thing to come off the shelf WITHOUT some PHB type knowing any funny business is going on behind the scenes, x86 is here to stay.

Plus, RISC has its own problems. It's not the second coming. It's nice, but not for everyone.

One reason..

[MartinG]

tIs' ebacsue ilttel neidna si ebttre.

Like it or not, x86 is the portable ISA

[swillden]

The x86 ISA hasn't been bound to Intel for some time now. There are currently at least three manufacturers making processors that implement the ISA, and of course there is a vast number of companies making software that runs on that ISA. Not only that, Intel isn't even the source of all of the changes/enhancements in their own ISA -- see AMD64.

With all of that momentum, it's hard to see how any other ISA could make as much practical sense.

And it's not like the ISA actually constrains the processor design much, either. NONE of the current x86 implementations actually execute the x86 instructions directly. x86 is basically a portable bytecode which gets translated by the processor into the RISC-like instruction set that *really* gets executed. You can almost think of x86 as a macro language.

For very small processors, perhaps the additional overhead of translating the x86 instructions into whatever internal microcode will actually be executed isn't acceptable. But in the desktop and even laptop space, modern CPUs pack so many millions of transistors that the cost of the additional translation is trivial, at least in terms of silicon real estate.

From the perspective of performance, that same overhead is a long term advantage because it allows generations of processors from different vendors to decouple the internal architecture from the external instruction set. Since it's not feasible, at least in the closed source world, for every processor generation from every vendor to use a different ISA, coupling the ISA to the internal architecture would constrain the performance improvements that CPU designers could make. Taking a 1% performance hit from the translation (and it's probably not that large) enables chipmakers to stay close to the performance improvement curve suggested by Moore's law[*], without requiring software vendors to support a half dozen ISAs.

In short, x86 may not be the best ISA ever designed from a theoretical standpoint, but it does the job and it provides a well-known standard around which both the software and hardware worlds can build and compete.

It's not going anywhere anytime soon.

[*] Yes, I know Moore's law is about transistor counts, not performance.

But we did

[teflaime]

vote with our wallets. The x86 architecture was cheaper than ppc, so that's what consumers chose. It is still consistently cheaper than other architectures. That's ultimately why Apple is moving to it too; they weren't selling enough product (yes, not being able to put their best chip in their laptops hurt, but most people were saying why am I paying $1000 more for a Mac when I can get almost everything I want from a PC)?

performance isn't the only factor

[briancnorton]

Why don't we all drive Formula 1 Cars? Why not hybrids? Why not motorcycles or electric scooters? The reason is that there is an infrastructure built around supporting a platform that is reliable, robust, and surprisingly extensible. (MMX, SSE, 64bit, etc) Intel asked the same question and came up with the Itanium. It is fast, efficient, and well understood. This is the same big reason that people don't use Linux, it's hard to switch for minimal tangible benefits. (not a flame, just an observation)

Silly rabits, x86 has been RISC core since PPro

[gmezero]

x86 only refers to a set of API interfaces with the CPU architecture. As of the launch of the Pentium, the modern "x86" processor is a RISC based CPU with an internal x86 translation layer. Start you learning here. x86 is also refered to as x86-32 or IA-32. And with the current generation of processors, we are leaving that behind for "x64" also known as EM64T, IA-32e or IA-64 in its various iterations. Many of the "x64" series generally maintian "x86" interface compatibility in order to allow legacy operation. For instance you can run Warp Server on a dual Opteron server just fine.

Re:But you do use the metric system

[Tim C]

I've never understood the attitude that "metric is too hard". It's all powers of ten and standard prefixes. How many millimetres in a metre? 1000. How many millilitres in a litre? 1000. How many metres in a kilometre? 1000. How many ounces in a pound? 16 (I think!) How many pounds in a stone? 14. What's the name of the next unit up? I had to google for it - apparently it's a quarter, which is 28lb (2 stones). Same with distance; 12 inches in a foot, 3 feet in a yard, 1760 yards in a mile (skipping over chains, poles and furlongs).

I know that a lot of it is simply what you're used to, but Imperial units are nonsensical to me after a science-heavy education using only SI units.

THESE are the reasons we use x86

[default luser]

1. Development of efficient compilers and high-end IDEs. Without having to see the mess that is x86 machine code, you can usually ignore it. People made a clamour for clean RISC machine code in the 80s, but within a decade very few people really cared anymore.

2. Total backward-compatibility of the API for the last 20+ years. Even Windows doesn't offer such amazing compatibility modes.

3. Every fundamental architectural improvement in CPU design has been integrated into the x86 family. Academics and designers alike said it was impossible, but x86 today enjoys all the benefits of RISC, pipelining, superscalar design, branch prediction, out-of-order execution, register renaming, symmetric multi-threading and multi-processing, real-time voltage and frequency adjustment...you name it, it has been implemented on an x68 processor.

These reasons are why everyone still uses x86. These reasons are why x86-64 is the predominant 64-bit architecture, and will be for some time. The die overhead for the compatibility and translation layers on modern processes is tiny, so why the hell not keep using it?