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?
I think it's a chicken and egg proposition. We use x86, because we use it. Historically, this is because of the popularity of the PC. A lot of people bought them. A lot of software was written for them. Other architectures did not succeed to displace the PC, because of the reluctance of people to abandon their software. Now, with years and years of this happening, the PC has actually become the most performant platform in its price class, while simultaneously becoming powerful enough that it could rival Real computers.
Slowly, other architectures became more like PCs: Alpha's got PCI buses, Power Macs got PCI buses, Sun workstations got PCI buses, etc. Eventually, the same happened to the CPUs: the Alpha line was discontinued, Sun started shipping x86-64 systems, and Apple started shipping x86 systems. The reason this happened is that most of the action was in the PC world; other platforms just couldn't keep up, in price and performance.
Please correct me if I got my facts wrong.
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.
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.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
``Performance per watt.''
Not as I remember. As I remember, the PPW of PowerPC CPUs was pretty good, and getting better thanks to Freescale, but the problem was that Freescale's CPUs didn't have enough raw performance, and IBM's didn't have low enough power consumption. Freescale was committed to the mobile platform and thus was only focusing on PPW, whereas IBM was focusing on the server market, and thus favored performance over low power consumption. Seeing that the situation wasn't likely to improve anytime soon, Apple switched to Intel.
Please correct me if I got my facts wrong.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
I can see where you're going with this... But... Well, not so much.
RISC CPUs with 4-byte instructions that don't do very much require lots of memory bandwidth to execute.
Well, I'm currently working on ARM, and stuff almost always ends up smaller than x86 code. Those 4-byte instructions actually do quite a lot. Oh, and that's with straight ARM code, not Thumb or Thumb-2.
The x86 instruction set has lots of 1-byte instructions
Not so many actually, and the ones it does have are mostly totally useless these days!
and multi-byte instructions that do a lot.
Well, you get to do fancy addressing modes on the rare occasions that you need them... But not too fancy, no pre/post increment/decrement etc.
In other words, x86 is really just a compression scheme for instruction sets.
Sort of, except that it was never designed to be one, and it's not very good at it at all.
Well, you could say that it was an OK (but not great) encoding for 8086, but it's totally unsuited to encoding the instructions that modern software actually uses.
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.
The enemies of Democracy are
You're right about the advantages of the CISC ISA vs. a RISC ISA, but I wanted to throw a few more points out.
Originally, going to RAM was cheap (in terms of cycles), going to disk was slow, so we loaded what we could in RAM and processed it. However, RAM was VERY expensive, until very recently, having "enough RAM" was rarely affordable. NT took so long to mass market (Win2K sort of, XP did it, almost 10 years), because when NT 3.1 shipped, it wanted 16 MB of RAM on the x86, and 32MB of RAM on the other systems, but going above 8 MB required specialized RAM because the RAM Chips (you plugged chips into sockets then, not chips on cards with standardized interfaces) were mass produced for 1 MB, 4 MB, and 8 MB, but going to 16 MB required using VERY expensive (relative to normal RAM) chips. So upgrading from 4 to 8 was normally doable (usually, they used the same chips, and you filled half the slots for 4MB, I think, it's been a long time since I had a 486 computer), but going to 16MB would often cost $2000 for the new RAM, when computers sold for $2000.
In the days of expensive RAM, the tighter ISA of x86 (more instructions per megabyte) gave them a major advantage in the real world. Sure, the ISA was crap, and the chips were crap, but when the most expensive component was RAM, the x86 used on average half the memory as the RISC competitors, which gave Intel a HUGE advantage in the cost-conscious desktop fight. It wasn't until the last 5 years, when Microsoft stagnated in their quest to use up more and more memory with each release (largely by failing to release OS updates), that the continual growth of RAM outpaced the computers. WinXP will run in 256MB, and run decently on 512MB, but 1GB or 2GB of RAM is reasonable for a decent system, and 512MB is not reasonable for a budget system. However, when we were struggling cost wise with 4MB and 8MB, the larger size of RISC programs was a problem.
Up until this point, it wasn't clear that x86 was the winner, it was the release of Windows 95 on the Pentium chips when Microsoft "won" the market, up until then, Windows was niche, OS/2 looked promising, Apple was a contender, and everyone just ran DOS/WP5.1 and NetWare 2.0. Up until 1995, it was anybody's game.
The biggest hit to the x86 was the lack of registers. In the 8088 and 8086 days, going to RAM wasn't too expensive, and the chip couldn't do much in the mean time, so we didn't care so much that it was the most register starved system. However, as chips got faster, going to RAM got expensive, and we didn't have registers, which is why the x86 GOT SMOKED in tightly run loops, because it couldn't keep enough data in there. The original cache banks (these were high tech, the chips were on a little card you plugged into your motherboard, you could even upgrade them for more) were to run faster than RAM, and created a third tier. Originally, this seemed like a hack because of the lack of registers.
However, our chips have massively increased in speed in the past 10 years (we were running at ~75-200 MHz in 1996) which meant that flooding the processor with data is the problem. The clock cycles are VERY short (we run ~ 2 Ghz, I remember the excitement at AMD making a 12 MHz 286, the 8088 started at 1 or 2 MHz), which means that carrying the signal over the wires is now an issue, so our motherboards are tighter, we keep cache ON THE CHIP, etc.
One reason that the x86 always outperformed was that once going to RAM became expensive, the smaller instruction size (and at the time, having 16-bit integers instead of 32 or 64) meant that if Intel provided 128 KB cache, then the other players needed 256 KB or even 512 KB to have the same caching advantage. This means, all things being equal, RISC was the better architecture, but IN REALITY, x86 could do the same amount of work with half or less resources. This allowed the computers to price cheaper, AND it meant that Intel could make HUGE profits.
For example, if RISC Vendor A sold a solution for $2500, assuming $2000 in parts