The ARM, the PPC, the x86, and the iPad
neosmart.net
neosmart.net
In fact, it’s now a universally accepted truth that RISC
is better than CISC! Actually, because of how much more
efficient RISC machines are than their CISC counterparts,
most CISC CPUs convert their CISC instructions into RISC
instructions internally, then run them!
The truth is that instruction sets are always outdated compared to the number of transistors that Moore's law allow to put on a chip. At some time it seemed that 32 registers would make renaming unnecessary. At another it seemed VLIW would make possible a level of performance not allowed by older instruction sets. Ask Intel and HP how that transition worked out for them.
RISC principles are only superior in the sense that 70's crazy haircuts are superior to 60's crazy haircuts. They are dated too, just a little less so. And in these days of memory-bound computations, higher density in CISC instruction sets seems to give them a slight advantage, if anything.
A RISC processor is a processor with no microcode virtual machine level. These processors aren't RISC in anyone's view but marketing's. Likely, there are very few true RISC processors still being designed (for speed; processors for embedding are a different story.)
- Fixed-width instructions (generally 32 bits)
- Explicit load and store instructions with arithmetic being performed only between registers (hence RISC architectures sometimes being called load-store)
- Large register files with few or no special-purpose registers (MIPS HI/LO registers being an exception to this one, for example)
Other common (though perhaps less "defining") traits: three-operand instructions, relatively few/simple addressing modes, procedure calls often done via "branch-and-link" instructions, etc.
But...
> A RISC processor is a processor with no microcode virtual machine level.
Huh? I've certainly never heard that before. In fact, I'd say the RISC/CISC dichotomy is primarily (if not entirely) an attribute of the ISA, not the microarchitecture implementing it. It's generally pretty easy to look at e.g. a PPC or x86 instruction set and classify it one way or another; in terms of internal implementations though, the lines have gotten so blurred (in both directions) in modern machines that I don't think it's real meaningful to talk about RISC vs CISC anymore at the microarchitectural level, frankly.
It's because we've adopted (or rather, co-opted) the terms to refer to things that shared phenotypical traits with their progenitors, but no longer held true to the original definitions. In reality, RISC originally just meant "exposes its microarchitecture as its instruction-set architecture." All the other well-known properties of RISC machines were effects of this decision. But these days,
> the lines have gotten so blurred (in both directions) in modern machines
...that, like I said, there are very few RISC processors under the original, theoretical definition of the term (and it's probably alright to just use "RISC" under the new definition, since only the embedded programmers will complain.)
The article mentions CISC CPUs using RISC instructions internally, which isn't the whole story anymore.
Ars Technica did a classic article on this debate (in 1999!): http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html and a follow up here: http://arstechnica.com/hardware/news/2009/09/retrospect-and-...
A particularly interesting part of the follow up: "But a funny thing happened with the Pentium M: processor designers discovered that processors of all types are actually more power-efficient if their internal instruction format is more complex, compound, and varied than it is with simple, atomic RISC operations ... ... The end result is that even RISC processors needed to get more CISC-y on the inside if they wanted to juggle the largest number of in-flight instructions using the least amount of power."
The principle reason people use ARM is low power, part of it's low power comes from the RISC design but it's not as simple as that. To reach the same overall performance as an x86 the RISC may have to use more power, simply because power increases faster than clock frequency.
ARM ameliorates this by having multiple instruction sets. The Thumb instructions are a denser encoding, if somewhat slower. 90/10 rules apply.
I'm just thinking out loud... but what if instructions in memory were simply compressed, and the CU's decode step were a decompression algorithm, rather than lots of opcode-specific lookups? It would still be a RISC processor, basically, just with a decompression coprocessor.
The amount you'd need to increase the clock of a RISC CPU to get similar performance to desktop CISC CPUs is a lot less than the 2.4GHz your currently using.
The shorter pipelines and simpler cycles means that you don't need to make the CPU crazy-fast to boost performance as much as you would with CISC. Intel has improved that starting with the Core CPUs, but it's still not as good as RISC design. The really deep pipeline in the P4 series was a killer - the cores were churning 3.6GHz and still not getting much work done. The "density of work" in a RISC cycle is (was) much higher than in CISC, and that really does help keep the power consumption down to a minimum.
There's more than one way to skin a cat, and people can talk all day about what to call each one.
Transmeta had the right idea, they did the x86-to-VLIW dynamically at runtime and in software, coupled with proper code caches. But it seems they were to early -- the market wasn't ready for them.
99% of the time instructions come from the instruction cache, not from memory. And as jws said, it's not 10:1.
But the original RISC research was in a time when neither CPU clocks nor memory bandwidth was anywhere near physical limits.
It's not the RISC(Apple) is clever and CISC(intel) is a dumb dinosaur - message the article is aiming at.
http://queue.acm.org/detail.cfm?id=1039523
Just as an aside, to give you an interesting benchmark—on roughly the same system,
roughly optimized the same way,
a benchmark from 1979 at Xerox PARC runs only 50 times faster today.
Moore’s law has given us somewhere between
40,000 and 60,000 times improvement in that time.
So there’s approximately a factor of 1,000 in efficiency
that has been lost by bad CPU architectures.
The myth that it doesn’t matter what your processor architecture is —
that Moore’s law will take care of you—is totally false.
[1]http://lists.canonical.org/pipermail/kragen-tol/2007-March/0...
Not the microprocessor technology itself.
Competitive microprocessor designs (in terms of speed, power, cost, volume and particularly the applications the users care about) are feasible but are Not Cheap, and to get the costs down (and the revenues up means you need to build the production scale. And building scale means leapfrogging the existing players in one or more dimensions sufficiently to draw over applications that the end-users really care about.
You need to be significantly better here or sufficiently profligate with the application vendors and the resellers, or sufficiently compatible to overcome the inherent application inertia; you need to have enough "pull" (speed, power, cost, particularly applications) to build up a base. Without this, you're running a furnace with the contents of the corporate coffers.
You can't be a just little better with your processor designs, either. That won't draw enough folks over. Both the Alpha and MIPS microprocessors had Microsoft Windows NT, and that (and even with porting tools such as FX!32) wasn't enough to build up an installed base against the x86 designs.
Apple is playing the long game here.
However, with the average use of mobile devices, does the CPU architecture really matter that much?
As the focus of mobile devices is more the consumption of media (games, video, etc), isn't the GPU where the large differentiator in this space?
Does either RISC or CISC have a benefit in the GPU space? Or am I completely wrong with that previous statement?
Lots of GPUs tend to work on four pixel quads of RGBA data with very specialised instruction sets, which are not really CISC or RISC but are maybe more RISC like.
This is good for graphics rendering both 2D and 3D, video and audio encoders and decoders are trickier, some parts like motion estimation can be implemented on a GPUs SIMD architecture but the bitstream process is very serial by design so fits badly to a SIMD architecture and is not great on CPU either, having a custom piece of hardware or FPGA maybe a better solution.
Is that actually true? I'd like to see some actual numbers comparing RISC vs. CISC performance/power consumption.
You'd be comparing apples and oranges. CPUs are optimized for specific use cases. There's always a tradeoff between the performance of each component, and current x86 CPUs are designed/built-for the desktop while current ARM/MIPS/etc. are made for embedded and mobile devices.
Atom comes close to being comparable to certain embedded devices, but not really. Because it's actually a desktop architecture (resembles older in-order execution x86 desktop PCs) scaled down and simplified to reduce power.
Within the field though, it's taken for fact. To me though, nothing says it clearer than that Intel internally converts CISC instructions to a series of RISC instructions, then enters them into the pipeline. If it weren't for compatibility issues, Intel would be RISC today.
One problem with that argument is that RISC machines do the same thing.
Another problem is that there are different amounts of available/potential bandwidth at different points. For example, L2 accesses are far more expensive than what a decoder can produce.
There's always some benefit to reducing the number of control bits, but it is especially pronounced the further that you get from functional units.
BTW - "the pipeline" is misleading. Many implementations use multiple pipelines even for a single instruction stream.
> Within the field though, it's taken for fact.
There may be a theoretical advantage, but if so, it is small relative to many other factors.
I've actually helped define a commercial ISA (RISC FWIW).
Intel tried to move away from CISC with EPIC (Itanium), which could be considered a kind of RISC, but it obviously didn't work out.
All computer architecture PhDs I've spoken to have referred to the Itanium with an air of awe. It was built from the ground-up with all the optimizations and bottlenecks in mind, and can be statically optimized to do magic... except no one is ever going to use it since it requires all applications to be recompiled, and with x86_64 offering an easy way out, that's not going to happen.
The whole RISC vs. CISC is off the point, that was decided a long while ago. x86 "CISC" which is quite a bit more RISCy than say VAX or 370 happens to be a very compelling blend.
ARM does have an interesting position in the ultra lower power field though. I suspect that has more to do with ARM being designed for that from the start than the instruction set though.
My point was that if microcode were the same as simply expanding CISC instructions into multiple RISC instructions, Intel could have gotten away with designing a RISC chip that was performant on x86 by simply expanding each x86 instruction into the new architecture.
The performance of x86 on Itanium wasn't too great (and was one of the reasons it didn't do so well).
Really? I've had pretty much exactly the opposite experience. In computer architecture circles I find it's actually more often referred to as "Itanic" than "Itanium", if that's any indicator. I think what's probably most sad about the Itanium debacle is that it brought about the end of Alpha, PA-RISC, and (non-embedded) MIPS, and all apparently for naught.
A slight aside: it doesn't really say much about it's technical merits one way or another, but Wikipedia has a pretty amazing chart of predicted vs. actual sales figures for Itani{c,um} over time: http://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_ed... (you can just see it falling on its face over the course of a decade).
> Is that actually true? I'd like to see some actual numbers comparing RISC vs. CISC performance/power consumption.
While I realize you intended your question about the latter part ("that RISC is better than CISC"), I'd say the prior part ("universally accepted truth") is absolutely, unequivocally not true. Just last weekend [1] I heard Yale Patt (a relatively Big Name in computer architecture) refer to RISC as something like "a hiccup that lasted 20 years" -- a slightly less than flattering description. Not saying I necessarily agree with him, but agreement is far from universal. There are plenty of other examples as well; see http://portal.acm.org/citation.cfm?id=1506661.1506667 for one I came across recently.
[1] Incidentally, at the same event I also met an Intrinsity chip-design engineer who said his company was in the process of being acquired, though at the time he didn't mention it was by Apple...
It might be a slightly different answer at your web host!
AFAIK, x86 doesn't have 3 operand instructions yet.
Perhaps more importantly though, (again, AFAIK) x86 does not have any instructions that operate memory-to-memory in the way the article indicates. There are plenty of memory-to-register and register-to-memory (and register-to-register) ops, but the ALU ops generally don't combine a load and a store into a single instruction (some instructions like cmpxchg do for the purpose of providing atomicity, but those are a special case).