Live data from Hacker News

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

techpowerup.com

171–180 of 446 posts

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

#171

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 have a hard time believing this fully: more custom instructions, more custom hardware, more heat. How can you avoid it?

The computation has to be done somehow, I don't know that it is a given that more available instructions means more heat.

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

#172
post #159

Earlier quoted context omitted.

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…

Transistor count does not equal performance. More transistors isn't necessarily going to speed up any random single-threaded bottleneck.

Again, the CRAY-1 CPU is around 42000 mm^2, so I'm guessing you'd rather run that today, right?

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

#173
post #84

Earlier quoted context omitted.

Since the Pentium Pro the hardware hasn't implemented the ISA, it's converted into micro ops.

Come on, you know what I meant :) If you want to support AVX e.g. you need 512bit (or 256) wide registers, you need dedicated ALUs, dedicated mask registers etc. Ice Lake has implemented SHA-specific hardware units in 2019.

ARM has instructions for SHA, AES, vectors, etc too. Pretty much have to pay the cost if you want the perf.

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

#174
post #71

Earlier quoted context omitted.

I have, the m4 is significantly ahead by any measure I’ve seen, with snapdragon just behind. https://www.xda-developers.com/tested-apple-m4-vs-intel-luna...

The m4 is not the same fab technology so not comparable. If you want to discuss the validity of some CPU architecture it needs to be between comparable fab technology, M4 being a generation ahead there makes the comparison unfair. If you compare like to like the difference almost completely disappears.

X elite uses an older node than lunar lake and does better

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

#175

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…

> - The hardcoded page size.

I'm pretty confident that this will get removed. It's an extension that made it's way into RVA23, but once anyone has a design big enough for it to be a burden, it can be dropped.

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

#176

Earlier quoted context omitted.

C# syntax is faster than Java because Java has no way to define custom value types/structs (last time I checked, I know there was some experimental work on this)

and yet there's more Java in HFT than C# And don't get me wrong, I'm C# fanboi that'd never touch Java, but JVM itself is impressive as hell, so even despite not having (yet) value types/structs, Java is still very strong due to JVM (the implementation). Valhalla should push it even further.

HFT code is unusual in the way it is used. A lot of work goes into avoiding the Garbage Collection and other JVM overheads.

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

#177

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.

> By prioritizing efficiency, Apple also prioritizes integration. The PC ecosystem prefers less integration (separate RAM, GPU, OS, etc) even at the cost of efficiency. People always say this but "integration" has almost nothing to do with it. How do you lower the power consumption of your wireless radio? You have a network stack that queues non-latency sensitive transmissions to minimize radio wake-ups. But that's t…

> How much power is saved by soldering the memory or CPU instead of using a socket? A negligible amount if any; the socket itself has no significant power draw.

This isn't quite true. When the whole chip is idling at 1-2W, 0.1W of socket power is 10%. Some of Apple's integration almost certainly save power (e.g. putting storage controllers for the SSD on the SOC, having tightly integrated display controllers, etc).

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

#178
After playing around with some ARM hardware I have to say that I don't care whether ARM is more efficient or not as long as the boot process remains the clusterfuck that it is today.

IMHO the major win of the IBM PC platform is that it standardized the boot process from the very beginning, first with the BIOS and later with UEFI, so you can grab any random ISO for any random OS and it will work. Meanwhile in the ARM world it seems that every single CPU board requires its own drivers, device tree, and custom OS build. RISC-V seems to suffer from the same problem, and until this problem is solved, I will avoid them like toxic waste.

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

#179

Earlier quoted context omitted.

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.

TIL the k5 was RISC. thank you

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

#180

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.

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 vendors slacking on QA!

One good example of this is RAM. 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. 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. That’s not magic or because Apple has some super elite programmers, it’s because they all work at the same company and nobody wants to go into Tim Cook’s office and say they blew the RAM budget and the new Macs need to cost $100 more. The hardware has compression support and the OS and app teams worked together to actually use it well, whereas it’s very easy to imagine Intel adding the feature but skimping on speed / driver stability, or Microsoft trying to implement it but delaying release for a couple years, or not working with third-party developers to optimize usage, etc. – nobody acting in bad faith but just what inevitably happens when everyone has different incentives.

Post reply on HN