The RISC Advantage

[witeken]

The RISC Advanatage: RISC vs. CISC Revisited

You can debate until you drop, but there is no denying that the x86 ISA requires more pipeline stages and thus transistors to decode than any decent RISC ISA. As x86 instructions are variable length, fetching instructions is less efficient and requires more transistors. The instruction cache is also larger as you need to store pre-decode information. The back-end might deal with RISC-like micro-ops but as the end result must adhere to rules of the x86 ISA, thus transistors are spent on exception handling and condition codes.

It's true that the percentage of transistors spent on decoding has dwindled over the years. But the number of cores has increased significantly. As a result, the x86 tax is not imaginary.

I gotta disagree. Silvermont for example is a very small core and has a competitive die size, so the difference in transistor is negligible.

A research: Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures

 

[Phynaz]

There hasn't been a native x86 CPU is nearly two decades. Does ARM run native?

 

[jhu]

There hasn't been a native x86 CPU is nearly two decades. Does ARM run native?

Atom, prior to Silvermont, is native x86. Xeon Phi (Knights Corner) is native x86. Intel Quark is native x86.

 

[Exophase]

There hasn't been a native x86 CPU is nearly two decades. Does ARM run native?

This isn't a simple question. Do ARM CPUs convert instructions into some other representation as they pass through different stages of execution? Under a certain interpretation, all CPUs can be said to convert instructions. Somehow control signals need to be generated that don't match what's stored in these instructions. And if you go back to the original 8086, it was mostly microcoded. Does that count as not native?

These days, people often say that x86 CPUs are RISC CPUs outside of the decoder. But that misses a couple things. Other parts of the CPU design are still affected by accommodating some non-RISC-like behavior of the instruction set, even if they operate on fixed width load/store sort of instructions. And programs can still potentially lose something by targeting the ISA they do instead of whatever is stored internally.

Besides, all of the Atom processors, even Silvermont, keep a more "direct" representation of most instructions in the queues rather than splitting into uops for things like load + op.

 

[III-V]

There hasn't been a native x86 CPU is nearly two decades. Does ARM run native?

You've still got the x86 overhead, though. I think ARM runs native, unless you're counting its move to 64-bit and retaining compatibility as not being native.

ARM is objectively better than x86, all else being equal. RISC-V appears to be significantly better than ARM, let alone x86.

But compatibility is not something you can quantify. It's incredibly important of course, and if it weren't an issue, we'd all be using whatever new super-architecture was available on the market.

Atom, prior to Silvermont, is native x86. Xeon Phi (Knights Corner) is native x86. Intel Quark is native x86.

These cores in particular would benefit tremendously from using RISC.

 

[witeken]

ARM is objectively better than x86, all else being equal.

I think you mean that it's objectively just as -- for all intents and purposes -- good.

RISC-V appears to be significantly better than ARM, let alone x86.

Like Itanium appeared to be significantly better than x86? RISC-V is even worse because there are no products in the market that you can base any conclusions on.

These cores in particular would benefit tremendously from using RISC.

Source?

 

[dmens]

The instruction cache is also larger as you need to store pre-decode information

Aren't x86 binaries more compact?

Also microcode, simplified backends, etc. This debate is still a thing in the year 2014?

 

[III-V]

I think you mean that it's objectively just as -- for all intents and purposes -- good.

No, ARM's objectively better. You get more registers (which are critical for performance), you don't have to decode to micro ops, power's down, area's down, performance is up.

RISC-V is even better. Power's down, area's down, performance is up. UC-Berkley says ARM's gotten rather bloated, and strayed too far off from the philosophy of going RISC in the first place, which basically opened up the possibility of being easily able to make something even better than ARM. It's also open-source, and I think there's huge potential for its adoption, but it needs backing.

These superiorities only matter on paper, hence my statement of "all else being equal." In the real world, these aren't on a level playing field. Intel is able to mask their inefficiencies by being more efficient in other areas, like process. They also have a bigger R&D budget, and can simply build better designs with that budget. Finally, they hold the market, which means that any chance for takeover is going to only be possible with some serious resources being dumped into bridging compatibility between ARM and x86.

Like Itanium appeared to be significantly better than x86? RISC-V is even worse because there are no products in the market that you can base any conclusions on.

Well, that's the thing. Compatibility is a huge dealbreaker, and really is the biggest factor in determining the success of a product. Apple, for example, would have had tremendous issues moving to Intel from PowerPC with their Macs, had they not provided a fairly seamless translation software in their OS at the time.

I think Itanium had some other issues, besides compatibility, but I don't really know too much about it other than AMD64 winning out simply due to compatibility.

And AMD64 beating out IA64 is perhaps the perfect example of why people shouldn't underestimate the importance of compatibility -- it's an AMD product that won, and it's not debatable, so it should be an easy pill for both camps to swallow.

Source?

Source: common sense, given the above.

I meant in the event that compatibility weren't an issue. They'd all benefit a lot from the reduced core area, power draw, and performance such a move would bring, and they're small enough designs that the impact would be more meaningful -- and in the case of the Phi, it's a manycore design, so the benefits would be scaled across many cores.

 

[witeken]

You can say that it's better, but no one would care if it was 1%. So what do the numbers look like? And FYI, when Intel was asked this question at an Investor Meeting, BK simply said no. ARM does not have something special that makes it superior. Performance and power depends on the microarchitecture.

 

[WhoBeDaPlaya]

What is this, 1990?

 

[Phynaz]

Atom, prior to Silvermont, is native x86. Xeon Phi (Knights Corner) is native x86. Intel Quark is native x86.

I stand corrected. In my defense I was thinking the big core PC line.

 

[Phynaz]

Circuit Design Monkey/RTL Janitor @ Intel. Nehalem, Westmere, Haswell, Knight's X.

Take a new position?

 

[witeken]

Take a new position?

Is that 7nm Xeon Phi?

 

[videogames101]

I have no idea why this keeps coming up. You can say over and over again that ARM or RISC-V or x86 are better or worse than one another, but the fact is the the REAL WORLD no one gives a damn about whether your CPU's are risc or risc-like or cisc or whatever you want to call it. Power consumption, performance, and cost are what sell products, not ISA. (Unless you're looking for compatibility, then ISA sells) Whether or not the ARM ISA is "superior" to x86 is totally, completely, and ABSOLUTELY moot.

Also, I hate to break it to you gents but the "decode stage" is not the bottleneck in a modern CPU.

 

[III-V]

You can say that it's better, but no one would care if it was 1%. So what do the numbers look like? And FYI, when Intel was asked this question at an Investor Meeting, BK simply said no. ARM does not have something special that makes it superior. Performance and power depends on the microarchitecture.

Yes, and ARM is better on this front -- these are microarchitectural-level details we're talking about. It's also not 1%. I am unsure what the performance difference is between ARM and x64, in the "all else being equal" vacuum, but it's not insignificant.

RISC-V gets very hefty improvements over ARM, essentially a full node's worth:

I'd imagine ARMv8's gain over x64 is smaller, but still significant.

In regards to BK, I am confident he is wrong. I am not sure if he's misinformed, flat out lying, or oversimplifying things to the point of being incorrect. When we leave the special vacuum-equalizer that I mentioned, things get really hairy, and his statement benefits from the noise:signal ratio. Compilers become a factor, operating systems become a factor... but inside that vacuum, where we're only comparing the architecture, ARM will always beat out x86.

What is this, 1990?

Are you still living in the 2000s? This subject is becoming increasingly relevant, and honestly much more so than it was back then.

Also, I hate to break it to you gents but the "decode stage" is not the bottleneck in a modern CPU.

This is false. Hard bottlenecks rarely exist, given that workloads almost always have some mix of code and are not the same set of operations over and over. You are likely to be decode-bound in certain situations, and even if that number were something like 1% of the time, it is still non-zero.

Regardless, this subject has much more to do than just decoding performance. It also extends to decode area, along with register size, instruction size, and many other places.

 

[videogames101]

Yes, and ARM is better on this front -- these are microarchitectural-level details we're talking about. It's also not 1%. I am unsure what the performance difference is between ARM and x64, in the "all else being equal" vacuum, but it's not insignificant.

RISC-V gets very hefty improvements over ARM, essentially a full node's worth:

I'd imagine ARMv8's gain over x64 is smaller, but still significant.

In regards to BK, I am confident he is wrong. I am not sure if he's misinformed, flat out lying, or oversimplifying things to the point of being incorrect. When we leave the special vacuum-equalizer that I mentioned, things get really hairy, and his statement benefits from the noise:signal ratio. Compilers become a factor, operating systems become a factor... but inside that vacuum, where we're only comparing the architecture, ARM will always beat out x86.


Are you still living in the 2000s? This subject is becoming increasingly relevant, and honestly much more so than it was back then.

This is false. Hard bottlenecks rarely exist, given that workloads almost always have some mix of code and are not the same set of operations over and over. You are likely to be decode-bound in certain situations, and even if that number were something like 1% of the time, it is still non-zero.

Regardless, this subject has much more to do than just decoding performance. It also extends to decode area, along with register size, instruction size, and many other places.

False? Should I make it more clear? In a modern pipeline, the decode "stage" is not determining the maximum clock frequency of the CPU.

I wouldn't argue with your area statement, clearly ARM/RISC-V will have much smaller decode logic, but Intel always has Moore's law to make up for it.

 

[dmens]

Take a new position?

Not Ex-Knights.

 

[ThatBuzzkiller]

The whole RISC vs CISC debate has little relevance anymore ...

There is little differentiation between the two terms. One cannot simply categorize an implementation of an ISA by the two design philosophy's ...

 

[III-V]

False? Should I make it more clear? In a modern pipeline, the decode "stage" is not determining the clock frequency of the CPU.

Yes, that's helpful. I didn't know you were talking in terms of frequency.

I wouldn't argue with your area statement, clearly ARM/RISC-V will have much smaller decode logic, but Intel always has Moore's law to make up for it.

Right, and that is why I am restricting my claims of ARM being architecturally superior to the academic vacuum of all else being equal.

 

[witeken]

I'd imagine ARMv8's gain over x64 is smaller, but still significant.

In regards to BK, I am confident he is wrong. I am not sure if he's misinformed, flat out lying, or oversimplifying things to the point of being incorrect.

http://www.anandtech.com/show/6529/busting-the-x86-power-myth-indepth-clover-trail-power-analysis

The 5% advantage get easily lost in the noise of all other factors that make up a CPU's speed and power. He is not lying because it simply isn't a big deal: it would be different if the difference were 2X. BTW, the specific question was if there's anything with ARM that makes it do so well in the mobile space.

All this ISA talk stands in contrast to the architectural decisions, which do significantly impact performance, and process technology, which impacts power consumption dramatically, more than any ISA ever could.

 

[Phynaz]

Not Ex-Knights.

I don't think I ever knew you were on Knights. But then my memory isn't great, so you may have mentioned it.

 

[dmens]

This is false. Hard bottlenecks rarely exist, given that workloads almost always have some mix of code and are not the same set of operations over and over.

Unless your code is just meandering around and not doing anything meaningful, yes there is a bottleneck somewhere for every workload. Doesn't have to be on the CPU either.

You are likely to be decode-bound in certain situations, and even if that number were something like 1% of the time, it is still non-zero.

AFAIK that can result from two things: a bad compiler, or uncommon user code that relies heavily on microcode flows that nobody cares about optimizing for. The decode stage is mostly a fixed pipeline, it is very hard for it to be a bottleneck. Unless you consider the decode width to be a bottleneck, in which case the entire machine must grow to accommodate decode width growth.

Regardless, this subject has much more to do than just decoding performance. It also extends to decode area, along with register size, instruction size, and many other places.

Heavily interpreted code can result in a simpler (and hence smaller) back-end implementation. Of course it's not a rule and I have no absolutely data to quote. It is just a personal observation.

 

[III-V]

The whole RISC vs CISC debate has little relevance anymore ...

There is little differentiation between the two terms. One cannot simply categorize an implementation of an ISA by the two design philosophy's ...

Then call it ARMv8 vs. x86-64, which is extremely relevant. Don't dismiss the subject entirely over a semantic issue.

 

[witeken]

Not Ex-Knights.

What does that mean?

 

[dmens]

What does that mean?

I'm still in the Knights program.