Advertisement
REGISTER | LOGIN
Breaking News
Blog

RISC vs CISC: What's the Difference?

Analysis of ARM, X86, MIPS designs shows no difference
NO RATINGS
View Comments: Oldest First | Newest First | Threaded View
Page 1 / 2   >   >>
Paul A. Clayton
User Rank
Author
Difficulties of comparison
Paul A. Clayton   7/1/2015 9:05:23 AM
NO RATINGS
A previous study ("Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures", Blem et al., 2013, PDF) came to basically the same conclusion.

Even though the researchers went to significant effort to limit confounding factors in that previous paper, one is inherently limited by the availability of hardware and software. For example, it is known that gcc has been improving its ARM support, so even using the same compiler version will not result in a perfectly fair comparison. The use of 32-bit x86 noticeably reduces performance compared to using 32-bit pointers with x86-64 (the extra registers have a significant impact on performance, perhaps c. 10%).

Aside from the process technology differences and higher-level core microarchitectural differences, there are also differences in non-core microarchitecture and in low-level optimization. ARM cores often pay an abstraction penalty both in the use of simple synthesis and in a more generic interface to the rest of the chip. The measurement of system power further complicates comparisons both from the variability of implementation quality and the diminished impact of the core. (The latter is a fact which inherently, and rightly, diminishes the effect of ISA.) The fact that ISA influences microarchitecture increases the difficulty of comparison.

While the conclusion that process technology and microarchitecture are the dominant factors in higher performance designs is firm, the implication some may take that ISA doesn't matter at all is problematic.

Such studies also do not fully address the effect of ISA on performance or energy efficiency since they are limited to specific architectures. What information should be communicated to the hardware and how to encode that information are still, I believe, open questions, in part because the answers vary with design targets (including time to market). For some targets a better answer is VLIW, not RISC or CISC.

The new paper presumably has significant refinements, but the measurement difficulties are likely to be persistent. In some sense, these questions do not matter since end-users choose existing hardware and most hardware developers either choose existing designs or work for a company with existing ISA commitments.

fab76
User Rank
Author
Re: Difficulties of comparison
fab76   7/1/2015 10:16:57 AM
NO RATINGS
This article is entirely wrong .... yes it is entirely wrong because you do not count the COST !!!

The functional verification of the mess the x86 has become is increadibly expensive.

Thus the ISA maybe doesn't matter that much as long you don't factor in the cost of design.

Anyway I still believe it matter in fact, but this point is less relevant that the one I raised:


For a given performance, the cost of design of a x86 is several times (if not tens of time) the cost of design of a RISC processor. Period.

Anyone thinking differently has no clue about functional verification. Keep in mind that you have to factor in all the accumulated crust.

For Intel this complexity is part of the game: that a deterrent to would be competitor (deside the legal aspects).

 

 

 

jeffreyrdiamond
User Rank
Author
Re: Difficulties of comparison
jeffreyrdiamond   7/1/2015 11:53:13 AM
I think the main take away was actually stated in the article:  The ISA *does* matter to performance, but other aspects of the design matter more, so you can compensate for a poorer ISA choice and end up with a decently performing product.  Comparisons were in the upper echelon of performance/power, while area and design cost were not factors in the study.

The primary way I see the article as potentially misleading is the study found chips made from both CISC and RISC vendors had comparable total performance, so you are safe using either.   It did not determine the performance impact of the ISA (other than on CPI), so it's hard to say which will scale farther in the future.

It's like the Porsche analogy:  Porsches are one of the best handling cars in the world, despite the common wisdom that you shouldn't put the engine in the rear.  The fact that Porsche is a master of engineering and compensated for this doesn't mean we should all go out and make rear engine sports cars. :)  But it also means that you shouldn't avoid buying a Porsche because it has uneven weight distribution, either.  Cost would be a bigger reason. :)

 

 

 

 

Kevin Krewell
User Rank
Author
Re: Difficulties of comparison
Kevin Krewell   7/1/2015 12:51:32 PM
NO RATINGS
Nice analogy! But by Porsches, you really mean 911s. Porsche made and continues to make cars with engines in the front (928/924/SUVs) and middle (914/Boxster/Cayman) of the vehicle.

jeffreyrdiamond
User Rank
Author
Re: Difficulties of comparison
jeffreyrdiamond   7/1/2015 12:56:41 PM
NO RATINGS
Yes, absolutely.  :)

perl_geek
User Rank
Author
Irrelevance
perl_geek   7/1/2015 1:27:18 PM
NO RATINGS
Could the subtitle be "Yet another religious war in computing considered irrelevant"?

Lewis.Sternberg
User Rank
Author
Re: Difficulties of comparison
Lewis.Sternberg   7/1/2015 1:42:58 PM
NO RATINGS
fab76:  I agree that functional verification is hugely expensive.  From my experience over many different large ASICs, it pretty much matches the design costs.  That is about a 1:1 ratio of design-to-verification engineers where the division of labor is clearly on the design/verification interface.  This seems to apply whether it's CISC, RISC, or router, etc.

All that said, these are NREs.  In a large production run, the cost-per-chip is still less than the package and, if managed well, the effort can be amortized over several projects.

Paul A. Clayton
User Rank
Author
x86 sunk costs
Paul A. Clayton   7/1/2015 1:43:29 PM
NO RATINGS
For x86, validation is largely a sunk cost (for existing x86 implementers). In addition, one can design a much cleaner CISC (variable length instructions, 16 GPRs, memory+op instructions, memcopy, et al.) than x86. ISAs tend to accumulate cruft, so it should not be surprising that x86 is on the crufty side. (I will not claim that the ISA was well managed, but some degree of cruft would have been difficult to avoid given the different tradeoffs in different markets with different manufacturing technologies.)

In addition, once one gets to the high end of performance, the complexity is substantially contained within the front-end and other complexity factors tend to dominate. It should also be recognized that only certain features need to be made performant, which allows significant simplification of design. This is a similar issue of previously paid costs; the techniques to make a high performance x86 had significant research and development costs but can be reused wihtout additional cost.

x86 is not a great example of a modern CISC (Renesas RX is much cleaner, though the design is more focused on code density for microcontrollers), but the costs for Intel et al. are not that extreme.

Lewis.Sternberg
User Rank
Author
Does not apply to mobile !?
Lewis.Sternberg   7/1/2015 1:55:37 PM
NO RATINGS
There seems to be an important blind-spot to the study:

"There is no way to do that below the A9, in terms of competitive architectures." In the Cortex-M0 environment, where ARM is competing with 8-bit MCUs over the 1-20 MHz and 2-50 mWatts range, the operating overheads of the X86 instruction set makes that untenable.

So the study defines "comparable" as "undifferentiated with respect to certain parameters" and then concludes that the subjects are, well, undifferentiated with respect to those parameters?

Tell me:  am I correct in interpreting this as saying that in order to make an apples-to-apples comparison, they left out low-power/mobile because ... what? x86 isn't a "competitive architecture" there?  

 

I must be missing something.

Jason Whitehorn
User Rank
Author
What is a RISC processor?
Jason Whitehorn   7/1/2015 3:04:18 PM
NO RATINGS
I never understood the RISC zealots.  For all their fervor, you would have expected 'RISC' ISAs to have had a significant commercial advantage, but of course, they didn't.  I never really understood how the PowerPC's rich and expressive assembly language was RISC, and ARM with predicated instructions, then Thumb and NEON was RISC, but the original 8086 was CISC.  Doesn't a _reduced_ instruction set imply fewer instructions?

The best definition I heard for RISC was:

Any processor or ISA produced or defined after 1989. [When RISC architectures captured the imagination of many]

In my view, this definition accurately captures the absurdity of the debate - which this report hopefully puts to rest.  Processors should be measured and characterized by their actual performance.

Page 1 / 2   >   >>
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed