Live data from Hacker News

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

techpowerup.com

441–446 of 446 posts

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

#441
post #440

Earlier quoted context omitted.

No, and that's exactly the point I'm making. If you try to measure ISA efficiency using a workload where the CPU is idle the vast majority of the time, then your power usage will be dominated by things unrelated to the ISA. To further hammer the point home, let me reduce do a reductio ad absurdum: The chip is still "in use" when its asleep. Sleeping your laptop is a typical usecase. Therefore how much power is used w…

You're not taking into account dynamic clock speeds, just "idle" and "load." Most CPUs have configurable TDP, and if you give them more power they will run more cores at a higher frequency. Suppose I measured the same laptop CPU under "full load" in two different computers at full load, but one is configured for a 30w TDP and the other is configured for a 40w TDP. The first PC will be more efficient, because you get…

> You're not taking into account dynamic clock speeds, just "idle" and "load." Most CPUs have configurable TDP, and if you give them more power they will run more cores at a higher frequency. Suppose I measured the same laptop CPU under "full load" in two different computers at full load, but one is configured for a 30w TDP and the other is configured for a 40w TDP. The first PC will be more efficient, because you get diminishing returns for increased power. But it's the same CPU.

Dynamic clock speeds are exactly why you need to do this testing under full load. No you're probably not getting the same power draw on each chip, but at least you're eliminating the frequency scaling algorithms from the equation. This is why it's so hard to evaluate core efficiency (let alone what effect the ISA has).

What you can do however is compare chips with wildly different performance and power characteristics. A chip that is using significantly more power to do significantly less work is less efficient than a chip using less power to do more.

> To go back to your original argument, you're claiming that x86 ISA is more efficient than ARM because a certain AMD chip beat certain M1/snapdragon chips at 50w.

I never claimed x86 is more efficient than ARM. I did claim the latest AMD cores are more efficient than M1 and snapdragon elite X, while still having worse battery life.

> You can't draw that conclusion because the two chips may be designed to have peak efficiency at different power levels, even if the maximum power draw is the same. Likely the Snapdragon/M1 have better efficiency at 10W with reduced clock speed even if the CPU is not idling.

Firstly this is pretty silly: All chips get more efficient at lower clock speed. Maximum efficiency is at at whatever the lowest clockspeed you can go, which is primarily determined by how the chip is manufactured. Which brings me to my second point: What does any of this have to do with the ISA?

> Not to mention -- who even cares about ISA efficiency? What matters is the result for the product I can buy.

If you don't care about ISA efficiency why are you here‽ That's what this discussion is about! If you don't care about this just leave.

And to answer your question: We care about ISA efficiency because we care about the efficiency of our chips. If ARM was twice as efficient then we should be pushing to kill x86, backwards compatibility be damned. In actuality the reason ARM-based laptops have better efficiency has nothing/little to do with the ISA, so instead of asking AMD/intel to release an ARM-based chips we should be pushing them to optimize battery usage.

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

#442
post #440

Earlier quoted context omitted.

You're not taking into account dynamic clock speeds, just "idle" and "load." Most CPUs have configurable TDP, and if you give them more power they will run more cores at a higher frequency. Suppose I measured the same laptop CPU under "full load" in two different computers at full load, but one is configured for a 30w TDP and the other is configured for a 40w TDP. The first PC will be more efficient, because you get…

> You're not taking into account dynamic clock speeds, just "idle" and "load." Most CPUs have configurable TDP, and if you give them more power they will run more cores at a higher frequency. Suppose I measured the same laptop CPU under "full load" in two different computers at full load, but one is configured for a 30w TDP and the other is configured for a 40w TDP. The first PC will be more efficient, because you ge…

You didn't understand what I said before responding. Please don't waste my time like that.

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

#443

Earlier quoted context omitted.

I have a Ryzen box that I temperature limited to 65 C indeed. That was about 100 W in my office with just the graphics integrated into the Ryzen. However, next to it there's a M2 mac mini that uses all of 37 W when I'm playing Cyberpunk 2077 so... > Both Intel and AMD provide runtime power control so this is tunable. The last ~10% of performance requires far more than 10% of the power. Yes but the defaults are insane…

If you're measuring the draw at the wall, AFAIK desktop Ryzen keeps the chipset running at full power all the time and so even if the CPU is idle, it's hard to drop below, say, ~70W at the wall (including peripherals, fans, PSU efficiency etc). Apparently desktop Intel is able to drop all the way down to under 10W on idle.

The ryzen box idles at 40. But it's a ... 5500 G iirc? 6c/12t, integrated graphics, series beginning with 5.

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

#444

Earlier quoted context omitted.

I have a Ryzen box that I temperature limited to 65 C indeed. That was about 100 W in my office with just the graphics integrated into the Ryzen. However, next to it there's a M2 mac mini that uses all of 37 W when I'm playing Cyberpunk 2077 so... > Both Intel and AMD provide runtime power control so this is tunable. The last ~10% of performance requires far more than 10% of the power. Yes but the defaults are insane…

The last 20% of the performance takes like >75% of the power with Zen 4 systems XD. A Ryzen 9 7945HX mini pc I have achieves like ~80% of the all-core performance at 55W of my Ryzen 9 7950X desktop, which uses 225W for the CPU (admittedly, the defaults). I think limiting the desktop CPU to 105W only dropped the performance by 10%. I haven't done that test in awhile because I was having some stability problems I could…

I was doing yocto builds at the time i limited the power. A full build from scratch was measured in hours. I didn't notice a significant slowdown after I put the power limit in.

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

#445

Earlier quoted context omitted.

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

You can't even express static rounding in C. You can't even express them in the LLVM language-independent IR. Any attempt to use the static rounding modes will necessarily involve intrinsics and/or assembly.

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

#446

Earlier quoted context omitted.

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

You can't even express static rounding in C. You can't even express them in the LLVM language-independent IR. Any attempt to use the static rounding modes will necessarily involve intrinsics and/or assembly.

There's a chicken and egg problem here. C can't express this, and there's no LLVM IR for this because up till now, everyone has had global registers for configuring fpus which make them slow and useless.

C probably won't support this for decades (ISO tends to be pretty conservative), but other languages (e.g Rust/Julia) might support this soonish (especially if LLVM adds support)

Post reply on HN