Slashdot Mirror
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?
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.
tasks(723) drafts(105) languages(484) examples(29106)
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.
The world is made by those who show up for the job.
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.
Anonymous Luddite: "What do you think of the dehumanizing effects of the Internet?"
Andy Grove: "Not Much."
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.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
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.
> 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.
Dual core 2GHz PPC below 25W isn't an improvement I guess? Look at PA-Semi...
Seriously, this has nothing at all to do with it.. What home user really cares if their PC takes 150W or 180W ? Nobody...
Peter.
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)?
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)
People who think they know everything really piss off those of us that actually do.
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).
OK, parent is the first post I've seen that explains the real reason why the x86 has become basically the only instruction set in mainstream computing.
There's no technical advantage to x86. In fact, IBM picked it specifically because it sucked--they didn't want the PC to compete with their professional workstations. Grafted on sets of extensions (SSE, MMX etc) have just made x86 more baroque over the years, and backward compatibility requirements have prevented cleaning away crap like segmented memory.
However, once a big enough chunk of the market got behind x86, it became impossible for any other design to keep up in R&D across all segments (mobile, desktop, server etc). Intel collects truckloads of cash, so they can spend more on engineering and make up for x86's deficiencies. IBM can compete with Intel, but even IBM decided it wasn't financially viable to be competitive in all segments, and basically dropped desktop PowerPC to focus on embedded (game consoles) and servers, hence Apple's switch to Intel. Similarly, AMD can compete, but only in desktop and servers. VIA compete, but only in embedded and low-end desktop.
The interesting question is whether the same thing will happen with operating systems. We're now basically down to Windows and Unix, plus a few niche OSs for embedded systems and high end servers. Microsoft finds itself in the awkward position of having to compete against most of the rest of the computing industry, including Sun, IBM, Apple, HP... At the same time they have certainly the biggest--and likely the cruftiest--codebase in the history of computing.
Ten years ago they were able to deliver technology before the competition, albeit not original technology--DDE and OLE shipped in usable form before the Publish-and-subscribe and OpenDoc they were copied from. Now things are different, Microsoft is struggling to keep up with Apple. It seems they can't copy Apple's new technology as fast as Apple can invent more new stuff. And at the same time, they're trying to fight two more wars in the embedded space with Xbox and Windows CE. Hence 5 years between desktop OS releases, while Apple has a release every 18 months.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
-- Erich
Slashdot reader since 1997
Architecture is meaningless for the end user and almost meaningless for the application developer. The preferences of OS designers and compiler writers are meaningless unless it can somehow Make Things Better for the end user.
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.
Binary, hex, and base 12 aren't "natural" since we have 10 fingers to count.
That being said, if our ancesters don't use thumbs or used them as carry bits or used them to extend our counting range to 32 we would all be using octal.
Seriously, the reason for Apple to switch to x86 was due to the fact that Intel has focused their business around creating the best possible chips for laptop computers. Laptops are now more than 50% of Macintoshes sold (and probably more than 50% of personal computers in general).
More money is being spent on R&D for the x86 architecture than anything else and this R&D is focused like a laser on the PC laptop/desktop use case.
There was a time when the best chip available for a laptop was a PowerPC G3. It was fast and it used really low power. And maybe PPC had a better more elegant architecture. But the fact is that more money has been poured into the x86 architecture so that TODAY and looking at the published roadmaps for the next few years, x86 looks like the clear winner in the PC market.
Avoid Missing Ball for High Score
For all the academic arguments about what architecture is better (CISC versus RISC, pipelined versus superscalar, etc.) what's difficult to deny is that the Intel/AMD (and the x86 architecture in general) have continued to meet or exceed Moore's law. Despite Apple's insistence that PowerPC was a better and faster path forward, the facts are that Intel outran them. This doesn't necessarily mean it's a better architecture, but rather the engineering resources (perhaps due to AMD/Intel competition) managed to do more with what they had. Maybe x86 is performing at 95% of its potential, and PPC at 50%. Who knows. Who actually cares, except for an academic discussion.
SPARC may well be the same way -- the main issue there is that Sun doesn't have the resources to both build CPU architectures, computer architectures, and OS and application software, and be competitive in all markets.
There are other instances of something similar. Take the Porsche 911. A rear-engined setup (with the majority of the weight of the car *behind* the rear axle) is inherently inferior to a mid-engine design. The car should handle like crap. And early versions, for the most part, did (oversteer was a very real and common issue). Take 40 years of incremental advances in body and suspension design, and the 911 is one of the best handling cars there is. The design is not the best -- it never WILL be the best -- but it is a very, very competent performer. Few things are better.
Modern CPUs have sufficiently complex decoder units at the front of sufficiently deep pipelines that the programmer-visible ISA has very little impact on the performance-critical aspects of the architecture. You need look no further than the vast architectural difference between AMD and Intel, or even Intel and Intel (P4 vs. Core) for the proof.
So, we'll keep using x86 in this market because it's what we've been using. We need *some* ISA, and now that the ISA itself is largely decoupled from the underlying implementation, there's very little incentive to change it.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Really? That hasn't been my experience.
Yes, really. But there are many variables, of course.
Increment/decrement of a register is one of those 1-byte instructions.
Yes, and push/pop. Note that I said 'mostly', and that my general point is that such instructions take up too much opcode space for their relative usefulness.
And don't underestimate those fancy instructions. It's very nice to be able to do things like a nondestructive multiply by 5 without using up the ALU.
It's nice, occasionally, but you don't need it so often in practice and you can do even more fancy stuff with ARM.
Well... it's not ideal for code compression, but I wouldn't call it "totally unsuited".
I think you're stretching my words a bit too far, we're talking about code compression so I didn't feel the need to qualify further.
Isn't it because all of the alleged advantages of other architectures just weren't compelling enough? And because unless you've got a rare sense of aesthetics for processor architecture design, nobody really cares what kind of chip is in the machine?
To elaoborate: I used to have and Amiga with an '040, and I remember then the arguments about how it was a "better" processor. But when the Commodore died I got a Cyrix Pentium-class PC and it seemed faster rendering in Lightwave, and that was all I really cared about at the time. Years later I switched to the Mac because I liked OSX. I ran it on a G4, and everyone said the G4 was "better" than the x86 of the day. I'm on a MacBook Pro now, with a Core Duo, and it seems faster. At least as fast, if not faster, than my wife's G5. Battery life is about as good as my G4 was. Maybe it gets a little hotter, but I don't really notice.
So in the end, regardless of any aesthetic concerns about the architecture or theories about what is "right", "clean" or "better", x86 seems to have been good enough all along the way to make switching a waste of time. So if it's not pragmatically better, why all the sorrow?
Cheers.
OK, everybody, let's switch to Windows. "Because sometimes it's easier to stick with a standard". But nevertheless the easy way should not be always chosen.
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.
It's official. Most of you are morons.
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?
Man is the animal that laughs.
And occasionally whores for Karma.
The fast "actual implementations" of x86 are done by translating x86 to RISC /in hardware/ as dynamically translating x86 instructions to RISC was the only way Intel could continue to achieve decent performance after the advent of pipelining.
Yes I'm well aware, ever since the Pentium Pro (worst name for a completely new architecture ever). I usually start my "CISC/RISC is an irrelevent argument" rants with that fact. That is exactly why the predictions of the RISC crowd that RISC would blow CISC out of the water in performance never materialized. The RISC crowd simply underestimated the ingenuity of the CISC crowd.
You can talk about the hypothetical failings of x86 all day long if you'd like. In actual implementation, aka reality, aka the only thing that matters, x86 chips have had rough performance parity -- sometimes slower, sometimes faster, but never a significant difference that could be attributed to the ISA -- with chips in similar market segments.
However, doing this lengthens the processor pipeline and makes things like branch mispredictions even more costly than they need to be. This is why x86 processors are still outperformed by RISC architectures in high-end servers and why Intel attempted, unsuccessfully, to remove the x86 albatross from its neck with the introduction of the Itanium.
The performance of high-end servers has nothing to do with ISA, little to do with branch mispredict penalty, and everything to do with caches, memory, and system architecture. x86 has approached this space from the bottom, with 4-way Intel servers being their "high-end" for a long time while IBM had been calling machines with only 20 processors in them "mid-range" for years. IBM has a good server system architecture, Intel's system architecture sucks. The design of x86 has nothing to do with it. Opteron has a good system architecture, and if AMD could afford the gigantic caches of IBM then they'd be sitting pretty in the high-end space.
Intel attempted to get rid of x86 because they have cross-licensing agreements with AMD on x86 which IA-64 is not subject to. It failed because the implementations were late and relatively poor -- you might notice a theme of hypothetical ISA superiority not materializing in practice -- and more importantly AMD gave people what they really wanted: 64-bit but with backward compatability.
The x86 ISA forces engineers to spend time working around its defects rather than improving performance or reducing power consumption.
I think you're both over and under estimating the engineering effort it takes to work around x86's complexities. On the one hand, producing super-scalar decoders for a variable length instruction set is an extremely difficult problem. On the other hand, it has been solved, and relatively little effort is needed to update the design for new processes. The same goes for other problems in x86. The actual effort spent on x86-isms for any particular project is relatively small and their ceasing to exist would not result in huge performance features since those features usually live or die by their own complexity/cost/performance tradeoffs, not lack of manpower.
Dismissing the issues with it as "engineers who like elegance" crying will not make its technical problems go away. Our personal computers are not as fast as they would be if x86 had not become the standard ISA for them, and it is worth asking when we will be able to get this lost performance back.
Sure, but the better question would be is it worth the cost to get that lost performance back. The cost is losing compatability with existing software. The benefit is in practice at best a percent of performance. I've been able to measure what happens when you get rid of x86's technical problems, and it isn't much. Programmers/compilers have learned to avoid the worst features of x86 (which are comensurately de-prioritized by the chip designers), and the rest are problems that have been basic
The enemies of Democracy are