Hacker News Reader

Comment by valarauca1 | Hacker News Reader

>Now Intel tries to get a cut of the market, but they are too late.

It's really more complex then that.

x86_64 has a lot of backwards compatibility. Even low power chips made by Intel typically consume 2-5x the wattage of ARM counter parts. Intel's very low power line (matches ARM) doesn't actually have the 64bit extension and is functionally a i586 chip from circa 1999-2003. Modern x86_64 chips have a whole section of die space dedicated to emulation, re-ordering, re-naming, and caching for us to pretend x86 is fast.

Then you have monopoly. Intel is the only company making x86_64 chips (Yes VIA/AMD exist, but collectively they have <10% of the market). They are the only show in town, it's their prices. While ARM simply licenses it's IP to other companies, who then compete with one another and drive prices even lower.

View on HN

I don't know why the argument that x86_64 has some affect on efficiency keeps coming up. All modern OoO chips microarch is decoupled from the instruction decoders. All the "strange" x86 instructions are effectively microcoded, which doesn't affect the execution performance of the instructions actually contained in high performance code. In many ways the ability to easily spill/operate against memory/stack provides instruction density advantages, and simplifies certain dependency calculations.

So, whether ARM64 has an power efficiency advantage isn't clear at all when one tries to actually compare them fairly. I frequently see people linearly scaling power/performance curves, or comparing cores that contain ECC, significantly more IO, etc against cores that don't and claiming that the core with 10x the IO bandwidth is somehow less efficient computationally because it consumes 5 watts more to power a PCIe bus.

So, lets get this out of the way, performance is not linear to power. Simply having a clock rate 50% faster has a large impact on power given the rough P=CV^2f equation because often the voltage goes up to support the higher frequencies. Worse designing for a target top end frequency of 4Ghz may entail extra pipeline stages/etc than one targeting 2Ghz in the same process. The result is significantly higher power draw at the same frequency due to the fact that higher frequencies are supported. Then there is leakage current/etc, which will be proportional to the number of transistors, so a design with 15MB of cache is going to waste more on leakage than one with 1MB. The extra 14MB of cache may only contribute another percent or two to the bottom line in many workloads, but frequently the difference between a processors at X performance and one at 1.5X is not due to a single factor but dozens of design tradeoffs that individually only net small percentage gains.

Bottom line, its better to compare implementations, and when ARM vs x86 chips are compared on similar grounds, they are a lot closer than you hear in glib remarks on forums like this. Intel's handicap in mobile (lack of native x86 android apps) and ARM's handicap in desktop/server all really come down to the software (and maybe in the case of some ARM products what one might consider alpha/immature products).

None of Intel's or ARM's very low power chips for IoT applications are OoO - uses too much power. Intel have actually resorted to using subsets of x86 on some of them, and even then they're mysteriously unwilling to release proper power usage information.

>for us to pretend x86 is fast.

"Instruction sets" are not fast, the implementations are. Also AMD has a nice chunk of marketshare which will only get bigger once Zen is out.

Instruction sets can affect the speed of the decoder hardware, and how many instructions fit in the L1 cache, to speed up jumping around reading them from memory.

Getting more register names in x86-64 was a huge boost too.

>Modern x86_64 chips have a whole section of die space dedicated to emulation, re-ordering, re-naming, and caching for us to pretend x86 is fast.

"to pretend x86 is fast" is a terrible choice of words. The fundamental problem is the memory wall. There are only two ways to solve it. Either put the processor directly onto the memory or add complex circuitry to mitigate it's effects. The former is difficult because DRAM and CPUs use different manufacturing processes. Thus neither x86 or ARM can avoid the latter if they want to maximise performance and in turn they become less power inefficient.

What you should have said is "to pretend DRAM is fast". It's not.

Actually AMD has around 20-30% marketshare...

I think you're right that it's more than 10, but I don't think it's much more than 20%. Q4 last year it was almost exactly 20% as part of a downward trend. There's a good chance it's somewhat below 20% right now.

Reply on news.ycombinator.com