Live data from Hacker News

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

techpowerup.com

371–380 of 446 posts

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

#371
post #320
post #306

Earlier quoted context omitted.

>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. Why would they spend billions to "catch up" to an ecological niche that is already occupied, when the best they could do - if the argument here is right that x86 and ARM are equivalent - is getting the same result? They would only invest this much money and time if they had some expectat…

The problem is that they are slowly losing the mobile markets, while their usual markets are not growing as they used to. AMD is less vulnerable to the issues that arise from that because they are fabless, and they could pivot entirely to GPU or non-x86 markets if they really wanted to. But Intel has fabs (very expensive in terms of R&D and capex) dedicated to products for desktop and server markets that must continu…

The markets didn't really budge. Apple only grew 1% in the traditional PC market (desktop/notebook) over the last 5 years and that's despite a wave of new products. The snapdragons are below 1%...

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

#372
post #320
post #306

Earlier quoted context omitted.

>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. Why would they spend billions to "catch up" to an ecological niche that is already occupied, when the best they could do - if the argument here is right that x86 and ARM are equivalent - is getting the same result? They would only invest this much money and time if they had some expectat…

The problem is that they are slowly losing the mobile markets, while their usual markets are not growing as they used to. AMD is less vulnerable to the issues that arise from that because they are fabless, and they could pivot entirely to GPU or non-x86 markets if they really wanted to. But Intel has fabs (very expensive in terms of R&D and capex) dedicated to products for desktop and server markets that must continu…

The question remains: Why would they spend billions only to "catch up"? That means, even after the investment is made and they have a product that is just as good, there is still no compelling technical reason for the customer to buy Intel/AMD over the other alternatives that are just as good, so their only possible avenue to attract customers is to drive the price into the ground which is a losing proposition.

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

#373
post #221
post #180

Earlier quoted context omitted.

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

Yes, I'm aware that Windows has memory compression, so let's think about why it's less successful and Windows systems need more memory than Macs.

The Apple version has a very high-performance hardware implementation versus Microsoft's software implementation (not a slam on Microsoft, they just have to support more hardware).

The Apple designers can assume a higher performance baseline memory subsystem because, again, they're working with hardware designers at the same company who are equally committed to making the product succeed.

The core Mac frameworks are optimized to reduce VM pressure and more Mac apps use the system frameworks, which means that you're paying the overhead tax less.

Many Mac users use Safari instead of Chrome so they're saving multiple GB for an app which most people have open constantly as well as all of the apps which embed a WebKit view.

Again, this is not magic, it's aligned incentives. Microsoft doesn't control Intel, AMD, and Qualcomm's product design, they can't force Google to make Chrome better, and they can't force every PC vendor not to skimp on hardware. They can and do work with those companies but it takes longer and in some cases the cost incentives are wrong – e.g. a PC vendor knows 99% of their buyers will blame Windows if they use slower RAM to save a few bucks or get paid to preload of McAfee which keeps the memory subsystem busy constantly so they take the deal which adds to their bottom line now.

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

#374
post #309

Earlier quoted context omitted.

He said "per watt", that's still true. You just talked about max throughput, which no one is discussing.

> The latest AMD under full load uses the same power as M1 and is faster, thus it has better performance per watt. He also said per watt. An AMD CPU running at full power and then stopping will use less battery than an M1 with the same task; that's comparing power efficiency.

[deleted]

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

#375
post #224

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…

> 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=/...

I see it's measuring full system wattage with a 12900k which tended to use quite a bit of juice compared to AMD offerings.

https://gamersnexus.net/u/styles/large_responsive_no_waterma...

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

#376
post #180

Earlier quoted context omitted.

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…

Is this meant to be contradicting what I said? It's all in the OS. There's absolutely no reason RAM can't be managed similarly effectively on a non-integrated product. Android is just Linux with full attention paid to power saving measures. These OS can get very long battery life, but in my experience the typical experience is something or other keeps the processor active and halves your expected battery life.

My point is that it's not just the OS for Apple, because every part of the device is made by people with the same incentives. Android is slower and has worse battery efficiency than iOS not because Google are a bunch of idiots (quite the contrary) but because they have to support a wider range of hardware and work with the vendors who are going to use slower, less capable components to save $3 per device. Apple had a decade lead on basic things like storage security because when they decided to do that, the hardware team committed to putting high-quality encryption into the SoC and that meant that iOS could just assume that feature existed and was fast starting on the 3GS whereas Google had to spend years and years haranguing the actual phone manufacturers into implementing what was at the time seen as a costly optional feature.

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

#377

Earlier quoted context omitted.

Reviewers always use max performance setting for benchmarks and then max battery life for battery tests. That's how people get tricked. When they actually buy the laptop and use it for themselves, they complain that it's slow when on battery life or hot/loud when plugged in.

They're not trying to trick you. In fact when they were measuring perf/watt, the Lunar Lake chip was disadvantaged against the Apple M-series because they had to run the SPEC 2017 tests on Ubuntu for the Lunar Lake chip, which has poorer tuning for it compared to Windows 11. You can see a footnote saying the compilation environment was Ubuntu 24.04 LTS on the bottom left corner of the frame when they show the perf/wa…

They are trying to trick you. All reviewers are told by Intel to run benchmarks in max performance mode and battery either in balanced or max efficiency mode. These modes will throttle. So the performance you're seeing in reviews aren't achievable in battery mode unless you're ok with drastically lower battery life.

Meanwhile, PCWorld is one of the few that actually ran benchmarks while on battery life - which is what people will experience.

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

#378
post #180

Earlier quoted context omitted.

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 can get away with less RAM because the flash storage is blazing fast and attached directly to the CPU, making swap much more painless than on most Windows machines that get bottom-of-the-barrel storage and controllers.

Yes, that's exactly what I'm talking about: Apple can do that because everyone involved works at the same place and owns the success or failure of the product. Google or Microsoft have to be a lot more conservative because they have limited ability to force the hardware vendors to do something and they'll probably get blamed more if it doesn't work well: people are primed to say “Windows sucks!” even if the real answer is that their PC was marginally-specced when they bought it 5 years ago.

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

#379

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…

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 not quite +/- 2 GB. There is a hole on either end of the reach that is a consequence of using a sign-extended 12-bit offset for loads and stores, and a sign-extended high 20-bit offset for AIUPC. ARM's adrp (address of page) + unsigned offsets is more uniform.

RV32 isn't a proper subset of RV64, which isn't a proper subset of RV128. If they were proper subsets, then RV64 programs could run unmodified on RV128 hardware. Not that its going to ever happen, but if it did, the processor would have to mode-switch, not unlike the x86-64 transition of yore.

Floating point arithmetic spends three bits in the instruction encoding to support static rounding modes. I can count on zero hands the number of times I've needed that.

The integer ISA design goes to great lengths to avoid any instructions with three source operands, in order to simplify the datapaths on tiny machines. But... the floating point extension correctly includes fused multiply-add. So big chunks of any high-end processor will need three-operand datapaths anyway.

The base ISA is entirely too basic, and a classic failure of 90% design. Just because most code doesn't need all those other instructions doesn't mean that most systems don't. RISC-V is gathering extensions like a Katamari to fill in all those holes (B, Zfa, etc).

None of those things make it bad, I just don't think its nearly as shiny as the hype. ARM64+SVE and x86-64+AVX512 are just better.

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

#380

RISC-V has no PI lock like ARM or x86 and x86_64. RISC-V has to start to seriously defend itself, because it is a death sentence for ARM ISA and and could start to cast shadows on x86_64 in some areas slowly but surely. Some people will try to bring it down, hard. If you stick to core rva22+ (core RISC-V ISA), RISC-V is good enough to replace all of them, without PI lock, and with a global standard ISA, software may…

What is "PI lock"? A cursory web search didn't reveal much.
Post reply on HN