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

#411

Post by astrange » Tue, Sep 09, 2025, 6:20 PM 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…

> Apple Silicon got some huge wins from lower latency and massive bandwidth, but that came at the cost of making RAM fixed and more expensive.

The memory latency actually isn't good, only bandwidth is good really. But there is a lot of cache to hide that. (The latency from fetching between CPU clusters is actually kind of bad too, so it's important not to contend on those cache lines.)

> A lot of PC users scoffed at the default RAM sizes until they actually used one and realized it was great at ~8GB less than the equivalent PC.

Less than that. Unified memory means that the SSD controller, display, etc subtract from that 8GB, whereas on a PC they have some of their own RAM on the side.

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

#412

Post by bee_rider » Tue, Sep 09, 2025, 6:29 PM UTC

mojuba wrote: post #295

exmadscientist wrote: post #247

Earlier quoted context omitted.

Yes, Intel/AMD cannot match Apple in efficiency. But Apple cannot beat Intel/AMD in single-thread performance. (Apple marketing works very hard to convince people otherwise, but don't fall for it.) Apple gets very, very close, but they just don't get there. (As well, you might say they get close enough for practical matters; that might be true, but it's not the question here.) That gap, however small it might be for…

> Apple has a max-efficiency design that's excellent for personal computing. Intel/AMD have aging max-performance designs that do beat Apple at absolute peak... Can you explain then, how come switching from Intel MBP to Apple Silicon MBP feels like literally everything is 3x faster, the laptop barely heats up at peak load, and you never hear the fans? Going back to my Intel MBP is like going back to stone age computi…

Is the Intel MacBook very old?

Is it possible that your workloads are bound by something other than single-threaded compute performance? Memory? Drive speed?

Is it possible that Apple did a better job tuning their OS for their hardware, than for Intel’s?

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

#413

Post by bee_rider » Tue, Sep 09, 2025, 6:35 PM UTC

steveBK123 wrote: post #360

exmadscientist wrote: post #247

Earlier quoted context omitted.

Yes, Intel/AMD cannot match Apple in efficiency. But Apple cannot beat Intel/AMD in single-thread performance. (Apple marketing works very hard to convince people otherwise, but don't fall for it.) Apple gets very, very close, but they just don't get there. (As well, you might say they get close enough for practical matters; that might be true, but it's not the question here.) That gap, however small it might be for…

> looks less and less like the right choice with every passing month It does seem like for at least the last 3-5 years it's been pretty clear that Intel x86 was optimizing for the wrong target / a shrinking market. HPC increasingly doesn't care about single core/thread performance and is increasingly GPU centric. Anything that cares about efficiency/heat (basically all consumer now - mobile, tablet, laptop, even smal…

It seems impossible that CPUs could ever catch up to GPUs, for the things that GPUs are really good at.

I dunno. I sort of like all the vector extensions we’ve gotten on the CPU side as they chase that dream. But I do wonder if Intel would have been better off just monomaniacally focusing on single-threaded performance, with the expectation that their chips should double down on their strength, rather than trying to attack where Nvidia is strong.

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

#414

Post by robotnikman » Tue, Sep 09, 2025, 7:18 PM UTC

jorvi wrote: post #224

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…

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

> 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

A big reason for this, at least for AMD, is because Apple buys all of TSMC's latest and greatest nodes for massive sums of money, so there is simply none left for others like AMD who are stuck a generation behind. And Intel is continually stuck trying to catch up. I would not say its due to x86 itself.

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

#415

Post by astrange » Tue, Sep 09, 2025, 7:31 PM UTC

SOTGO wrote: post #3

I'd be interested to hear someone with more experience talk about this or if there's more recent research, but in school I read this paper: https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa... > that seems to agree that x86 and ARM as instruction sets do not differ greatly in power consumption. They also found that GCC picks RISC-like instructions when compiling for x86 which meant the number of micro-ops…

`lea` is a very common x86 instruction that isn't RISC-like. (Actually I don't think any x86 operations are RISC-like since they're variable length and overwrite their inputs.)

It's just that the most complicated of all x86 instructions are so specific that they're too irrelevant to use. Or were straight up removed in x86-64.

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

#416

Post by astrange » Tue, Sep 09, 2025, 7:32 PM UTC

cylemons wrote: post #326

KingOfCoders wrote: post #271

Earlier quoted context omitted.

What you have to understand, these are all the same people.

Dont high profile designers have strong anticompetes?

California doesn't allow noncompete clauses. It's why Silicon Valley exists in the first place.

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

#417

Post by adgjlsfhk1 » Tue, Sep 09, 2025, 7:34 PM UTC

brandmeyer wrote: post #379

newpavlov wrote: post #131

Earlier quoted context omitted.

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

Nothing major , just some oddball decisions here and there. Fused compare-and-branch only extends to the base integer instructions. Anything else needs to generate a value that feeds into a compare-and-branch. Since all branches are compare-and-branch, they all need two register operands, which impairs their reach to a mere +/- 4 kB. The reach for position-independent code instructions (AUIPC + any load or store) is…

> Floating point arithmetic spends three bits in the instruction encoding to support static rounding modes.

IMO this is way better than the alternative in x86 and ARM. The reason no one deals with rounding modes is because changing the mode is really slow and you always need to change it back or else everything breaks. Being able to do it in the instruction allows you to do operations with non-standard modes much more simply. For example, round-to-nearest-ties-to-odd can be incredibly useful to prevent double rounding.

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

#418

Post by adgjlsfhk1 » Tue, Sep 09, 2025, 7:39 PM UTC

brandmeyer wrote: post #379

newpavlov wrote: post #131

Earlier quoted context omitted.

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

Nothing major , just some oddball decisions here and there. Fused compare-and-branch only extends to the base integer instructions. Anything else needs to generate a value that feeds into a compare-and-branch. Since all branches are compare-and-branch, they all need two register operands, which impairs their reach to a mere +/- 4 kB. The reach for position-independent code instructions (AUIPC + any load or store) is…

> The base ISA is entirely too basic

IMO this is very wrong. The base ISA is excellent for micro-controllers and teaching, but the ~90% of real implementations can add the extra 20 extensions to make a modern, fully featured CPU.

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

#419

Post by adgjlsfhk1 » Tue, Sep 09, 2025, 7:51 PM UTC

camel-cdr wrote: post #256

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…

> trace caches They don't anymore they have uop caches, but trace caches are great and apple uses them [1]. They allow you to collapse taken branches into a single fetch. Which is extreamly important, because the average instructions/taken-branch is about 10-15 [2]. With a 10 wide frontend, every second fetch would only be half utilized or worse. > extra caches This is one thing I don't understand, why not replace th…

you need both. Branches don't tell you "jump to this micro-op", they're "jump to this address" so you need the address numbering of a normal L1i.

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

#420

Post by adgjlsfhk1 » Tue, Sep 09, 2025, 7:58 PM UTC

jabl wrote: post #341

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 also has flags, which add implicit dependencies between instructions, and must make designer's life harder. Fortunately flags (or even individual flag bits) can be renamed just like other registers, removing that bottleneck. And some architectures that use flag registers, like aarch64, have additional arithmetic instructions which don't update the flag register. Using flag registers brings benefits as well. E.g…

How big a difference is that? 1MB is still too small to jump to an arbitrary function, and 4K is big enough to almost always jump within a function.