AMD claims Arm ISA doesn't offer efficiency advantage over x86 • Hacker News Board

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

#221

Post by p_ing » Tue, Sep 09, 2025, 2:32 AM UTC

acdha wrote: post #180

Panzer04 wrote: post #132

Earlier quoted context omitted.

Eh, probably the biggest difference is in the OS. The amount of time Linux or Windows will spend using a processor while completely idle can be a bit offensive.

It’s all of the above. One thing Apple excels at is actually using their hardware and software together whereas the PC world has a long history of one of the companies like Intel, Microsoft, or the actual manufacturer trying to make things better but failing to get the others on-board. You can in 2025 find people who disable power management because they were burned (hopefully not literally) by some combination of ve…

Windows 10 introduced memory compression. Here's a discussion from 2015 [0]. And one on Linux by IBM from 2013 [1]. But the history goes way back [2].

I don't know why that '8GiB is great!' -- no, no it isn't. Your memory usage just spills over to swap faster. It isn't more efficient (not with those 16KiB pages).

[0] https://learn.microsoft.com/en-us/shows/Seth-Juarez/Memory-C...

[1] https://events.static.linuxfound.org/sites/events/files/slid...

[2] https://en.wikipedia.org/wiki/Virtual_memory_compression#Ori...

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

#222

Post by MindSpunk » Tue, Sep 09, 2025, 2:37 AM UTC

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…

Comparing the M1 Max to a Ryzen 7 8845HS is not a fair comparison because the M1 chip also includes a _massive_ GPU tile, unlike the 8845HS which has a comparatively tiny iGPU because most vendors taking that part are pairing them with a separate dGPU package.

A better comparison is to take the total package area of the AI Max+ 395 that includes a 16 core CPU + a massive GPU tile and you get ~448mm^2 across all 3 chiplets.

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

#223

Post by ajross » Tue, Sep 09, 2025, 2:44 AM UTC

GeekyBear wrote: post #195

ajross wrote: post #147

Earlier quoted context omitted.

> Why can't they decode 100 instructions per cycle? Well, obviously because there aren't 100 individual parallel execution units to which those instructions could be issued. And lower down the stack because a 3000 bit[1] wide cache would be extremely difficult to manage. An instruction fetch would be six (!) cache lines wide, causing clear latency and bottleneck problems (or conversely would demand your icache be 6x…

Wasn't the point of SMT that a single instruction decoder had difficulty keeping the core's existing execution units busy?

No, it's about instruction latency. Some instructions (cache misses that need to hit DRAM) will stall the pipeline and prevent execution of following instructions that depend on the result. So the idea is to keep two streams going at all times so that the other side can continue to fill the units. SMT can be (and was, on some Atom variants) a win even with an in-order architecture with only one pipeline.

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

#224

Post by jorvi » Tue, Sep 09, 2025, 2:50 AM UTC

torginus wrote: post #18

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 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…

Nice followup to your link: https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter.

Personally I do not entirely buy it. Intel and AMD have had plenty of years to catch up to Apple's M-architecture and they still aren't able to touch it in efficiency. The PC Snapdragon chips AFAIK also offer better performance-per-watt than AMD or Intel, with laptops offering them often having 10-30% longer battery life at similar performance.

The same goes for GPUs, where Apple's M1 GPU completely smoked an RTX3090 in performance-per-watt, offering 320W of RTX 3090 performance in a 110W envelope: https://images.macrumors.com/t/xuN87vnxzdp_FJWcAwqFhl4IOXs=/...

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

#225

Post by nerpderp82 » Tue, Sep 09, 2025, 2:55 AM UTC

wallopinski wrote: post #188

codedokode wrote: post #124

Earlier quoted context omitted.

x86 decoding must be a pain - I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy. Also, more complicated decoding and extra caches means longer pipeline, which means more price to pay when a branch is mispredicted (binary search is a festival of branch misprediction for example, and I got 3x acc…

I was an instruction fetch unit (IFU) architect on P6 from 1992-1995. And yes, it was a pain, and we had close to 100x the test vectors of all the other units, going back to the mid 1980's. Once we started going bonkers with the prefixes, we just left the pre-Pentium decoder alone and added new functional blocks to handle those. And it wasn't just branch prediction that sucked, like you called out! Filling the instru…

https://en.wikipedia.org/wiki/P6_(microarchitecture)

The P6 is arguably the most important x86 microarch ever, it put Intel on top over the RISC workstations.

What was your favorite subsystem in the P6 arch?

Was it designed in Verilog? What languages and tools were used to design P6 and the PPro?

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

#226

Post by Rohansi » Tue, Sep 09, 2025, 2:56 AM UTC

kragen wrote: post #137

Rohansi wrote: post #129

Earlier quoted context omitted.

Sounds great for performance.

Would this be more or less costly than a page fault? It seems like it would be easy to arrange for it to happen very rarely unless none of your cores support all the instructions.

Most likely similar. What would the correct behavior be for the scheduler to avoid hitting it in the future? Flag the process as needing X instruction set extension so they only run on the high performance cores?

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

#227

Post by monocasa » Tue, Sep 09, 2025, 2:57 AM UTC

codedokode wrote: post #124

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…

x86 decoding must be a pain - I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy. Also, more complicated decoding and extra caches means longer pipeline, which means more price to pay when a branch is mispredicted (binary search is a festival of branch misprediction for example, and I got 3x acc…

> x86 decoding must be a pain - I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy.

To be fair, a lot of modern ARM cores also have uop caches. There's a lot to decide even without the variable length component, to the point that keeping a cache of uops and temporarily turning pieces of the IFU off can be a win.

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

#228

Post by nerpderp82 » Tue, Sep 09, 2025, 2:59 AM UTC

wallopinski wrote: post #189

ahartmetz wrote: post #86

Earlier quoted context omitted.

Variable length decoding is more or less figured out, but it takes more design effort, transistors and energy. They cost, but not a lot, relatively, in a current state of the art super wide out-of-order CPU.

"Transistors are free." That was pretty much the uArch/design mantra at intel.

Isn't that still true for high perf chips? We don't have ways to use all those transistors so we make larger and larger caches.

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

#229

Post by monocasa » Tue, Sep 09, 2025, 3:01 AM UTC

adgjlsfhk1 wrote: post #127

fanf2 wrote: post #70

Earlier quoted context omitted.

Apple’s ARM cores have wider decode than x86 M1 - 8 wide M4 - 10 wide Zen 4 - 4 wide Zen 5 - 8 wide

pure decoder width isn't enough to tell you everything. X86 has some commonly used ridiculously compact instructions (e.g. lea) that would turn into 2-3 instructions on most other architectures.

Additionally, stuff llike rmw instructions are really like at least three, maybe four or five risc instructions.

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

#230

Post by monocasa » Tue, Sep 09, 2025, 3:03 AM UTC

jcranmer wrote: post #146

codedokode wrote: post #124

Earlier quoted context omitted.

x86 decoding must be a pain - I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy. Also, more complicated decoding and extra caches means longer pipeline, which means more price to pay when a branch is mispredicted (binary search is a festival of branch misprediction for example, and I got 3x acc…

> x86 decoding must be a pain So one of the projects I've been working on and off again is the World's Worst x86 Decoder, which takes a principled approach to x86 decoding by throwing out most of the manual and instead reverse-engineering semantics based on running the instructions themselves to figure out what they do. It's still far from finished, but I've gotten it to the point that I can spit out decoder rules. A…

> While I'm not a hardware designer, my gut says that you can probably do x86 instruction length-decoding in one cycle

That's been my understanding as well. X86 style length decoding is about one pipeline stage if done dynamically.

The simpler riscv length decoding ends up being about a half pipeline stage on the wider decoders.