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

[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

[samkass]

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.

And I think this will be increasingly true of the desktop. And since all the best desktop CPUs are x86, it'll probably stay x86.

From an engineering design point of view, it's possible some of these other architectures are cleaner or easier to design or code to, but from a desktop chip and compiler point of view, x86 is the best. It has the best codegen compilers, despite the fact that it may have taken more effort to get to that state, and the CPUs are damn fast at reasonable (although perhaps not optimal) power consumption levels. Talk of theoretical alternate options are academic. Unless one of those other options can produce a chip and compiler that's so much better than x86 that it would be worth moving to, emulation overhead during transition and all, it's not a practical discussion.

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

[epine]

I agree that the alternatives never delivered on their promises. That, more than anything else, is why we still use x86. The problem for the alternatives has always been that the liabilities of the x86 design were never as bad as people made them out to be. Certainly the x86 went sideways with the 286, but it returned to sanity again with the 386 and most of those worthless 286 protection modes are just a bit of wasted die area in the microcode array which gets smaller and smaller with each new shrink.

The old story "make is easy for the compilers" is vastly overstated. Modern compilers schedule non-orthogonal register sets extremely well. What is hard for the compilers is crazy amounts of loop unrolling involving asynchronous memory access patterns. Out-of-order execution actually makes life a lot *easier* for the compilers than more rigid approaches such as Itanium or Cell at the cost of extra heat production. Now that we are hitting the thermal wall, maybe it's time for the compilers to finally earn their keep. I've never understood the sentiment of making it easy for the compiler as opposed to, say, writing a very good compiler that implements the best algorithm available.

The key is to choose an aggressive target for what the compiler can reasonably contribute, and then ensure that the compiler achieves that target in a good way. Some of the VLIW efforts stand out in my mind as shining examples of asking the compiler to do a little more than could reasonably be expected. OTOH, I see no reason to simplify an instruction set to the point where a college student could implement the register scheduling algorithm over a long weekend.

Yes, a few things could have been done far better from the outset, such as a more uniform instruction length (though not necessarily as regimented as ARM), a register based floating point unit, and a treatment of the flag register with fewer partial updates. But really, how much else of what was conceived in the early eighties doesn't have greater flaws? We still use email, barely.

The time for debate over instruction sets has long passed. The future debate concerns the integration of heterogenous cores such as the IBM Cell and the future spawn of the AMD/ATI assimilation. I have no doubt someone is out there right now inventing an interconnect everyone will be wistfully lamenting twenty years from now. If only we had known and done something about it (other than this).

After twenty years, it's time to face the music: x86 is more ugly than bad.

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.

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.

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.

We don't

[BenjyD]

We don't really use x86 CPUs, they're all RISC with an x86->RISC decode stage at the front of the pipeline. As far as I understand it, we use the x86 ISA because there has always been too much x86 specific code around for people to switch easily, which gave Intel huge amounts of money to spend on research and fabs.

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)

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).

Because ISA doesn't matter

[Erich]

It's because if you're willing to throw some effort at the problem, the instruction set doesn't matter.

Intel chips haven't really executed x86 since the original Pentium. They translate the instructions into a more convienient form and execute those. They do analysis in hardware and find all sorts of opportunities to make code run faster.

As it turns out, you have to do most of the same analysis to get good performance on a RISC too. So you have a bit of extra decoding work, which you might not have to do on a MIPS or something, but you gain some flexibility in what lies underneath. And if you're producing 10x the amount of processors as Freescale, you're going to be able to make up for any marginal increase in cost the extra complexity costs you.

Also, don't buy into the hype. You can't buy that much from a good ISA on high-end processors. Look at the SPEC numbers for the Core 2 duo vs. anyone else if you don't believe me. IA64 was supposed to be the greatest thing ever because compilers could do all the work at compile time. There's almost every instruction set hook imaginable in IA64. And look how that architecture has turned out.

We use x86 because instruction translation is pretty easy and very effective... the same reason why Java algorithms perform pretty well, Transmeta had a halfway decent chip, Alpha could execute x86 code pretty well, and Apple can run PPC apps pretty well on x86. It's not bad enough to be completely broken, and we can engineer our way out of the problems in the architecture.

Of course, if you're counting transistors and joules, some of this breaks down... that's why ARM and DSPs have been effective at the low end.

Re:Why Apple moved to x86

[Tim Browse]

Not as I remember.

I'm confused - didn't you just then go on to confirm that Apple switched to Intel because they got better performance per watt, as the original poster said?

Or do you mean IBM's performance per watt was really good, but had a lower bound on power consumption that was too much for Apple's laptops/iMacs/Mac minis?

I was certainly under the impression that Apple were very frustrated with not being able to produce a 'state of the art' laptop with the G5 chipset (hence this famous image), and saw the Pentium M and what else Intel had coming, and decided the world of x86 was good. Performance per watt was definitely the reason Jobs gave when he announced the Intel switch.

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?