Live data from Hacker News

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

techpowerup.com

191–200 of 446 posts

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

#191

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…

> x86 didn't dominate in low power because Intel had the resources to care but never did Remember Atom tablets (and how they sucked)?

Eeepc was was a hit. Its successors still make excellent cheap long-life laptops, if not as performant as Apple.

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

#192
post #68
post #36

Earlier quoted context omitted.

Like o11c says, that's setting everyone up for a bad time. If the heterogenous cores are similar, but don't all support all the instructions, it's too hard to use. You can build legacy instructions in a space optimized way though, but there's no reason not to do that for the high performance cores too --- if they're legacy instructions, one expects them not to run often and perf doesn't matter that much. Intel droppe…

I don't really understand why the OS can't just trap the invalid instruction exception and migrate it to the P-core. E.g. AVX-512 and similar. For very old and rare instructions they can emulate them. We used to do that with FPU instructions on non-FPU enabled CPUs way back in the 80s and 90s.

It's slow and annoying. What would cpuid report? If it says "yes I do AVX-512" then any old code might try to use it and get stuck on the P-cores forever even if it was only using it sparingly. If you say no then the software might never use it, so what was the benefit?

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

#193

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

> When the whole chip is idling at 1-2W, 0.1W of socket power is 10%.

But how are you losing 10% of power to the socket at idle? Having a socket might require traces to be slightly longer but the losses to that are proportional to overall power consumption, not very large, and both CPU sockets and the new CAMM memory standard are specifically designed to avoid that anyway (primarily for latency rather than power reasons because the power difference is so trivial).

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

This isn't really integration and it's very nearly the opposite: The primary advantage here in terms of hardware is that the SoC is being fabbed on 3nm and then the storage controller would be too, which would be the same advantage if you would make an independent storage controller on the same process.

Which is the problem with PCs again: The SSDs are too integrated. Instead of giving the OS raw access to the flash chips, they adhere a separate controller just to do error correction and block remapping, which could better be handled by the OS on the main CPU which is fabbed on a newer process or, in larger devices with a storage array, a RAID controller that performs the task for multiple drives at once.

And which would you rather have, a dual-core ARM thing integrated with your SSD, or the same silicon going to two more E-cores on the main CPU which can do the storage work when there is any but can also run general purpose code when there isn't?

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

#194
Related to this, I remember seeing a research talk that fairly convincingly demonstrated that almost all performance differences between several ARM amd x86 CPUs were explained by microarchitectural features (branch predictor type and size, etc) rather than ISA. There was one benchmark affected by a deficiency in the ARM ISA, but that’s probably fixed by now.

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

#195
post #147

Earlier quoted context omitted.

Does that really say anything about efficiency? Why can't they decode 100 instructions per cycle?

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

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

#196

Earlier quoted context omitted.

> While I'm not a hardware designer, my gut says that you can probably do x86 instruction length-decoding in one cycle That's some very faint praise there. Especially when you're trying to chop up several instructions every cycle. Meanwhile RISC-V is "count leading 1s. 0-1:16bit 2-4:32bit 5:48bit 6:64bit"

The chopping up can happen the next cycle, in parallel across all the instructions in the cache line(s) that were fetched, and it can be pipelined so there's no loss in throughput. Since x86 instructions can be as small as one byte, in principle the throughput-per-cache-line can be higher on x86 than on RISC-V (e.g. a single 32-byte x86 cache line could have up to 32 instructions where the original RISC-V ISA might o…

> The chopping up can happen the next cycle

It still causes issues.

> Since x86 instructions can be as small as one byte, in principle the throughput-per-cache-line can be higher on x86 than on RISC-V (e.g. a single 32-byte x86 cache line could have up to 32 instructions where the original RISC-V ISA might only have 8).

RISC-V has better code density. The handful of one byte instructions don't make up for other longer instructions.

> And in any case, there are RISC-V extensions that allow variable-length instructions now, so they have to deal with the problem too.

Now? Have to deal with the problem too?

It feels like you didn't read my previous post. I was explaining how it's much much simpler to decode length. And the variable length has been there since the original version.

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

#197
post #115
post #50

Earlier quoted context omitted.

> That's not mostly because of a better ISA Genuinely asking -- what is it due to? Because like the person you're replying to, the m* processors are simply better: desktop-class perf on battery that hangs with chips with 250 watt TDP. I have to assume that amd and intel would like similar chips, so why don't they have them if not due to the instruction set? And AMD is using TSMC, so that can't be the difference.

> Genuinely asking -- what is it due to? Mostly memory/cache subsystem. Apple was willing to spend a lot of transistors on cache because they were optimizing the chips purely for mobile and can bury the extra cost in their expensive end products. You will note that after the initial wins from putting stonking amounts of cache and memory bandwidth in place, Apple has not had any significant performance jump beyond the…

I still don't understand though. Given their profit margins, the fact that they're shipping m chips in eg $1k computers means it's a $150 part.

There's tons of people that would pay $300+ for an equivalent perf + heat x86 competitor.

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

#198
It's not the ISA. Modern Macbooks are power-efficient because they have:

- RAM on package

- PMIC power delivery

- Better power management by OS

Geekerwan investigated this a while ago, see:

https://www.youtube.com/watch?v=Z0tNtMwYrGA https://www.youtube.com/watch?v=b3FTtvPcc2s https://www.youtube.com/watch?v=ymoiWv9BF7Q

Intel and AMD have implemented these improvements with Lunar Lake and Strix Halo. You can buy an x86 laptop with Macbook-like efficiency right now if you know which SoCs to pick.

edit: Correction. I looked at the die image of Strix Halo and thought it looked like it had on-package RAM. It does not. It doesn't use PMIC either. Lunar Lake is the only Apple M-series competitor on x86 at the moment.

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

#199
post #122
post #16

Irrelevant. There are two entities allowed to make x86_64 chips (and that only because AMD won the 64 bit ISA competition, otherwise there'd be only Intel). They get to choose. The rest will use arm because that's all they have access to. Oh, and x86_64 will be as power efficient as arm when one of the two entities will stop competing on having larger numbers and actually worry about power management. Maybe provide a…

> Oh, and x86_64 will be as power efficient as arm when one of the two entities will stop competing on having larger numbers and actually worry about power management. 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.

I remember hearing on one of the podcasts I listened to about the difference between the Apple power cores and efficiency cores.

The power ones have more execution units I think, and are allowed to run faster.

When running the same task, the efficiency ones are just ridiculously more efficient. I wish I had some link to cite.

The extra speed the power units are allowed is enough to tip them way over the line of exponential power usage. I’ve always known each bump in megahertz comes with a big power cost but it was eye-opening.

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

#200

From what I have heard it's not the RISCy ISA per se, it's largely arm's weaker memory model. I'd be happy to be corrected, but the empirical core counts seem to agree.

Indeed, the memory model has a decent impact. Unfortunately it's difficult to isolate in measurement. Only Apple has support for weak memory order and TSO in the same hardware.

Oh there’s an interesting idea. Given that Linux runs on the M1 and M2 Macs, would it be possible to do some kind of benchmark there where you could turn it on and off at will for your test program?
Post reply on HN