Live data from Hacker News

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

techpowerup.com

301–310 of 446 posts

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

#301
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?

That's a gross misrepresentation of what SMT is to the point where nothing you said is correct.

First of all. In SMT there is only one instruction decoder. SMT merely adds a second set of registers, which is why it is considered a "free lunch". The cost is small in comparison to the theoretical benefit (up to 2x performance).

Secondly. The effectiveness of SMT is workload dependent, which is a property of the software and not the hardware.

If you have a properly optimized workload that makes use of the execution units, e.g. a video game or simulation, the benefit is not that big or even negative, because you are already keeping the execution units busy and two threads end up sharing limited resources. Meanwhile if you have a web server written in python, then SMT is basically doubling your performance.

So, it is in fact the opposite. For SMT to be effective, the instruction decoder has to be faster than your execution units, because there are a lot of instructions that don't even touch them.

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

#302
post #96

Earlier quoted context omitted.

Wait are you saying the diff in perf per watt from apple arm to x86 is purely on fab leading edge ness?

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.

  Basically yeah, if you compare CPU from same fab then its basically the same.
This isn't true. If you compare N5 Apple to N5 AMD chips, Apple chips still come out far ahead in efficiency.

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

#303
post #224

Earlier quoted context omitted.

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…

> 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. Do not conflate battery life with core efficiency. If you want to measu…

[deleted]

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

#304

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…

Yeah I'm not sure I buy it either. It doesn't matter if most instructions have simple encodings. You still need to design your front end to handle the crazy encodings. I doubt it makes a big difference, so until recently he would have been correct - why change your ISA when you can just wait a couple of months to get the same performance improvement. But Moore's law is dead now so small performance differences matter…

The core argument in RISC vs CISC has never been that you can't add RISC style instructions to a CISC. If anything, the opposite is true, because CISC architectures just keep adding more and more instructions.

The argument has been that even if you have a CISC ISA that also happens to have a subset of instructions following the RISC philosophy, that the bloat and legacy instructions will hold CISC back. In other words, the weakness of CISC is that you can add, but never remove.

Jim Keller disagrees with this assessment and it is blatantly obvious.

You build a decoder that predicts that the instructions are going to have simple encodings and if they don't, then you have a slow fallback.

Now you might say that this makes the code slow under the assumption that you make heavy use of the complex instructions, but compilers have a strong incentive to only emit fast instructions.

If you can just add RISC style instructions to CISC ISAs, the entire argument collapses into irrelevance.

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

#305

Earlier quoted context omitted.

https://github.com/riscv-non-isa/riscv-server-platform/blob/...

But those initiatives are focused on servers. What about desktops and laptops? Cellphones? SBC like the Raspberry Pi? That is my concern.

This is also supposed to be for desktops/laptops afaik, idk about phones.

Edit, this part of the server platforms spec certainly: https://github.com/riscv-non-isa/riscv-brs/blob/main/intro.a...

> BRS-I is expected to be used by general-purpose compute devices such as servers, desktops, laptops and other devices with industry expectations on silicon vendor, OS and software ecosystem interoperability.

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

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

>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 expectation of being better, but "sharing the first place" is not good enough.

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

#307

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…

> Handling of misaligned loads/stores Agreed, I think the problem is that RVI doesn't want to/can't mandate implementation details. I hope that the first few RVA23 cores will have proper misaligned load/store support and we can tell toolchains RVA23 or Zicclsm means fast misaligned load/store and future hardware that is stupid enough to not implement it, will just have to suffer. There is some silver lining, because…

> I feel like encoding scalar fmacc with three sources and seperate destinations and rounding modes was a huge waste of encoding space

This might be easily solved by defining new lighter varieties of the F/D/Q extensions (under new "Z" names) that just don't include the fmacc insn blocks and reserve them for extension. (Of course, these new extensions would themselves be incompatible with the full F/D/Q extensions, effectively deprecating them for general use and relegating them to special-purpose uses where the FMACC encodings are genuinely useful.) Something to think about if the 32-bit insn encoding space becomes excessively scarce.

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

#308
post #180

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

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

#309
post #224

Earlier quoted context omitted.

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…

> 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. Do not conflate battery life with core efficiency. If you want to measu…

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