Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD claims Arm ISA doesn't offer efficiency advantage over x86

techpowerup.com

Post reply on HN
Print view View original

151–160 of 446 posts

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#151

Post by tyfighter »

DeepYogurt wrote: post #89
pavlov wrote: post #41

Earlier quoted context omitted.

And Transmeta…

Transmeta wasn't x86 internally but decoded x86 instructions. Retrobytes did a history of transmeta not too long ago and the idea was essentially to be able to be compatible with any cpu uarch. Alas by the time it shipped only x86 was relevant. https://www.youtube.com/watch?v=U2aQTJDJwd8

Actually, the reason Transmeta CPUs were so slow was that they didn't have an x86 instruction hardware decoder. Every code cache (IIRC it was only 32 MB) miss resulted in a micro-architectural trap which translated x86 instructions to the underlying uops in software.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#153

Post by mandevil »

jopsen wrote: post #73
FlyingAvatar wrote: post #52

Earlier quoted context omitted.

It's pretty difficult to imagine. Apple did a ton of work on the power efficiency of iOS on their own ARM chips for iPhone for a decade before introducing the M1. Since iOS and macOS share the same code base (even when they were on different architectures) it makes much more sense to simplify to a single chip architecture that they already had major expertise with and total control over. There would be little to no u…

Isn't it also easier to license ARM, because that's the whole point of the ARM Corporation. It's not like Intel or AMD are known for letting other customize their existing chip designs.

Intel and AMD both sell quite a lot of customized chips, at least in the server space. As one example, any EC2 R7i or R7a instance you have are not running on a Sapphire Rapids or EPYC processor that you could buy, but instead one customized for AWS. I would presume that other cloud providers have similar deals worked out.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#154

Post by wvenable »

happycube wrote: post #134
wvenable wrote: post #95

Earlier quoted context omitted.

By prioritizing efficiency, Apple also prioritizes integration. The PC ecosystem prefers less integration (separate RAM, GPU, OS, etc) even at the cost of efficiency.

There's a critical instruction for Objective C handling (I forget exactly what it is) but it's faster than intel's chips even in Rosetta 2's x86 emulation .

I believe it's the `lock xadd` instruction. It's faster when combined with x86 Total Store Ordering mode that the Rosetta emulation runs under.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#155

Post by tracker1 »

addaon wrote: post #125
Jensson wrote: post #96

Earlier quoted context omitted.

Basically yeah, if you compare CPU from same fab then its basically the same. Its just Apple buys next gen fabs while AMD and intel has to be on last gen, so the M computers people compare are always one fab gen ahead. It has very little to do with CPU architecture. They do have some cool stuff about their CPU, but the thing most laud them for has to do with fabs.

There's another difference -- willingness to actually pay for silicon. The M1 Max is a 432 mm^2 laptop chip built on a 5 nm process. Contrast that to AMD's "high end" Ryzen 7 8845HS at 178 mm^2 on a 4 nm process. Even the M1 Pro at 245 mm^2 is bigger than this. More area means not just more peak performance, but the ability to use wider paths at lower speeds to maintain performance at lower power. 432 mm^2 is friggin…

Apple's SOC does a bit more than AMD's, such as including the ssd controller. I don't know if Apple is grafting different nodes together for chiplets, etc compared to AMD on desktop.

The area has nothing to do with peak performance... based on the node, it has to do with the amount of components you can cram into a given space. The CRAY-1 cpu was massive compared to both of your examples, but doesn't come close to either in terms of performance.

Also, Ryzen AI Max+ 395 is top dog on the AMD mobile CPU front and is around 308mm^2 combined.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#156

Post by ryukoposting »

ZuLuuuuuu wrote: post #46

There are a lot of theoretical articles which claim similar things but on the other hand we have a lot of empirical evidence that ARM CPUs are significantly more power efficient. I used laptops with both Intel and AMD CPUs, and I read/watch a lot of reviews in thin and light laptop space. Although AMD became more power efficient compared to Intel in the last few years, AMD alternative is only marginally more efficien…

I think both can be true.

A client CPU spends most of its life idling. Thus, the key to good battery life in client computing is, generally, idle power consumption. That means low core power draw at idle, but it also means shutting off peripherals that aren't in use, turning off clock sources for said peripherals, etc.

ARM was built for low-power embedded applications from the start, and thus low-power idle states are integrated into the architecture quite elegantly. x86, on the other hand, has the SMM, which was an afterthought.

AFAICT case for x86 ~ ARM perf equivalence is based on the argument that instruction decode, while empirically less efficient on x86, is such a small portion of a modern, high-performance pipeline that it doesn't matter. This reasoning checks out IMO. But, this effect would only be visible while the CPU is under load.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#157

Post by astrange »

AnotherGoodName wrote: post #77
torginus wrote: post #18

Earlier quoted context omitted.

I remember reading this Jim Keller interview: https://web.archive.org/web/20210622080634/https://www.anand... Basically the gist of it is that the difference between ARM/x86 mostly boils down to instruction decode, and: - Most instructions end up being simple load/store/conditional branch etc. on both architectures, where there's literally no difference in encoding efficiency - Variable length instruction has pretty…

For variable vs fixed width i have heard that fixed width is part of apple silicons performance. There’s literally gains to be had here for sure imho.

It's easier but it's not that important. It's more important for security - you can reinterpret variable length instructions by jumping inside them.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#158

Post by AnotherGoodName »

somanyphotons wrote: post #90
exmadscientist wrote: post #2

This is an entirely uncontroversial take among experts in the space. x86 is an old CISC-y hot mess. RISC-V is a new-school hyper-academic hot mess. Recent ARM is actually pretty good. And none of it matters, because the uncore and the fabrication details (in particular, whether things have been tuned to run full speed demon or full power sipper) completely dominate the ISA. In the past x86 didn't dominate in low powe…

I'd love to see what would happen if AMD put out a chip with the instruction decoders swapped out for risc-v instruction decoders

Fwiw the https://en.wikipedia.org/wiki/AMD_Am29000 RISC CPU and the https://en.wikipedia.org/wiki/AMD_K5 are a good example of this. As in AMD took their existing RISC CPU to make the K5 x86 CPU.

Almost the same in die shots except the K5 had more transistors for the x86 decoding. The AM29000's instruction set is actually very close to RISC-V too!

Very hard to find benchmarks comparing the two directly though.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#159

Post by addaon »

tracker1 wrote: post #155
addaon wrote: post #125

Earlier quoted context omitted.

There's another difference -- willingness to actually pay for silicon. The M1 Max is a 432 mm^2 laptop chip built on a 5 nm process. Contrast that to AMD's "high end" Ryzen 7 8845HS at 178 mm^2 on a 4 nm process. Even the M1 Pro at 245 mm^2 is bigger than this. More area means not just more peak performance, but the ability to use wider paths at lower speeds to maintain performance at lower power. 432 mm^2 is friggin…

Apple's SOC does a bit more than AMD's, such as including the ssd controller. I don't know if Apple is grafting different nodes together for chiplets, etc compared to AMD on desktop. The area has nothing to do with peak performance... based on the node, it has to do with the amount of components you can cram into a given space. The CRAY-1 cpu was massive compared to both of your examples, but doesn't come close to ei…

> The area has nothing to do with peak performance... based on the node, it has to do with the amount of components you can cram into a given space.

Of course it does. For single-threaded performance, the knobs I can turn are clockspeed (minimal area impact for higher speed standard cells, large power impact), core width (significant area impact for decoder, execution resources, etc, smaller power impact), and cache (huge area impact, smaller power impact). So if I want higher single-threaded performance on a power budget, area helps. And of course for multi-threaded performance the knobs I have are number of cores, number of memory controllers, and last-level cache size, all of which drive area. There's a reason Moore's law was so often interpreted as talking about performance and not transistor count -- transistor count gives you performance. If you're willing to build a 432 mm^2 chip instead of a 308 mm^2 chip iso-process, you're basically gaining a half-node of performance right there.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#160

Post by mixmastamyk »

newpavlov wrote: post #131
codedokode wrote: post #126

Earlier quoted context omitted.

What choices? The main thing that comes to mind is lack of exceptions on integer overflow but you are unlikely meaning this.

- Handling of misaligned loads/stores: RISC-V got itself into a weird middle ground, ops on misaligned pointers may work fine, may work "extremely slow", or cause fatal exceptions (yes, I know about Zicclsm, it's extremely new and only helps with the latter, also see https://github.com/llvm/llvm-project/issues/110454 ). Other platforms either guarantee "reasonable" performance for such operations, or forbid misaligne…

Sounds like a job for RISC-6, or VI.
Post reply on HN