Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techpowerup.com

Post reply on HN
Print view View original

131–140 of 446 posts

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

#131

Post by newpavlov »

codedokode wrote: post #126
newpavlov wrote: post #108

Earlier quoted context omitted.

>RISC-V is a new-school hyper-academic hot mess. Yeah... Previously I was a big fan of RISC-V, but after I had to dig slightly deeper into it as a software developer my enthusiasm for it has cooled down significantly. It's still great that we got a mainstream open ISA, but now I view it as a Linux of the hardware world, i.e. a great achievement, with a big number of questionable choices baked in, which unfortunately…

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 misaligned access with "aligned" loads/stores and provide separate misaligned instructions. Arguably, RISC-V should've done the latter (with misaligned instructions defined in a separate higher-end extension), since passing unaligned pointer into an aligned instruction signals correctness problems in software.

- The hardcoded page size. 4 KiB is a good default for RV32, but arguably a huge missed opportunity for RV64.

- The weird restriction in the forward progress guarantees for LR/SC sequences, which forces compilers to compile `compare_exchange` and `compare_exchange_weak` in the absolutely same way. See this issue for more information: https://github.com/riscv/riscv-isa-manual/issues/2047

- The `seed` CSR: it does not provide a good quality entropy (i.e. after you accumulated 256 bits of output, it may contain only 128 bits of randomness). You have to use a CSPRNG on top of it for any sensitive applications. Doing so may be inefficient and will bloat binary size (remember, the relaxed requirement was introduced for "low-powered" devices). Also, software developers may make mistake in this area (not everyone is a security expert). Similar alternatives like RDRAND (x86) and RNDR (ARM) guarantee proper randomness and we can use their output directly for cryptographic keys with very small code footprint.

- Extensions do not form hierarchies: it looks like the AVX-512 situation once again, but worse. Profiles help, but it's not a hierarchy, but a "packet". Also, there are annoyances like Zbkb not being a proper subset of Zbb.

- Detection of available extensions: we usually have to rely on OS to query available extensions since the `misa` register is accessible only in machine mode. This makes detection quite annoying for "universal" libraries which intend to support various OSes and embedded targets. The CPUID instruction (x86) is ideal in this regard. I totally disagree with the virtualization argument against it, nothing prevents VM from intercepting the read, no one excepts huge performance from such reads.

And this list is compiled after a pretty surface-level dive into the RISC-V spec. I heard about other issues (e.g. being unable to port tricky SIMD code to the V extension or underspecification around memory coherence important for writing drivers), but I can not confidently talk about those, so it's not part of my list.

P.S.: I would be interested to hear about other people gripes with RISC-V.

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

#132

Post by Panzer04 »

wvenable wrote: post #95
whynotminot wrote: post #33

Earlier quoted context omitted.

An annoying thing people have done since Apple Silicon is claim that its advantages were due to Arm. No, not really. The advantage is Apple prioritizing efficiency, something Intel never cared enough about.

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.

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

#133

Post by cosmic_cheese »

toast0 wrote: post #67
x0x0 wrote: 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.

I think the fundamental difference between an Apple CPU and an Intel/AMD CPU is Apple does not play in the megahertz war. The Apple M1 chip, launched in 2020 clocks at 3.2GHz; Intel and AMD can't sell a flagship mobile processor that clocks that low. Zen+ mobile Ryzen 7s released Jan 2019 have a boost clock of 4 GHz (ex: 3750H, 3700U); mobile Zen2 from Mar 2020 clock even higher (ex: 4900H at 4.4, 4800H at 4.2). Inte…

> Apple can sell a premium branded CPU where there's no option to burn a lot of power to get a little faster; but AMD and Intel just can't, people may say they want efficiency, but having higher clocks is what makes an x86 processor premium.

I think this is very context dependent. Is this a big, heavy 15”+ desktop replacement notebook where battery life was never going to be a selling point in the first place? One of those with a power brick that could be used as a dumbbell? Sure, push those clocks.

In a machine that’s more balanced or focused on portability however, high clock speeds do nothing but increase the likelihood of my laptop sounding like a jet and chewing through battery. In that situation higher clocks makes a laptop feel less premium because it’s worse at its core use case for practically no gain in exchange.

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

#134

Post by happycube »

wvenable wrote: post #95
whynotminot wrote: post #33

Earlier quoted context omitted.

An annoying thing people have done since Apple Silicon is claim that its advantages were due to Arm. No, not really. The advantage is Apple prioritizing efficiency, something Intel never cared enough about.

By prioritizing efficiency, Apple also prioritizes integration. The PC ecosystem prefers less integration (separate RAM, GPU, OS, etc) even at the cost of efficiency.

There's a critical instruction for Objective C handling (I forget exactly what it is) but it's faster than intel's chips even in Rosetta 2's x86 emulation.

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

#135

Post by phire »

codedokode wrote: post #124
torginus wrote: post #18

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…

x86 decoding must be a pain - I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy. Also, more complicated decoding and extra caches means longer pipeline, which means more price to pay when a branch is mispredicted (binary search is a festival of branch misprediction for example, and I got 3x acc…

Intel’s E cores decode x86 without a trace cache (μop cache), and are very efficient. The latest (Skymont) can decode 9 x86 instructions per cycle, more than the P core (which can only decode 8)

AMD isn’t saying that decoding x86 is easy. They are just saying that decoding x86 doesn’t have a notable power impact.

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

#136

Post by rafaelmn »

tester756 wrote: post #109

Of course, because saying that X ISA is faster than Y ISA is like saying that Java syntax is faster than C# syntax Everything is about the implementation: compiler, JIT, runtime/VM, stdlib, etc. https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter

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)

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

#137

Post by kragen »

Rohansi wrote: post #129
kragen wrote: post #88

Earlier quoted context omitted.

What if the kernel handled unimplemented instruction faults by migrating the process to a core that does implement the instruction and restarting the faulting instruction?

Sounds great for performance.

Would this be more or less costly than a page fault? It seems like it would be easy to arrange for it to happen very rarely unless none of your cores support all the instructions.

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

#138

Post by toast0 »

jdsully wrote: post #68
toast0 wrote: 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 not impossible, but it'd be a pain in the butt. If you occasionally use some avx-512 infrequently, no big deal (but also not a big deal to just not use it). But if you use it a lot, all of a sudden your core count shrinks; you might rather run on all cores with avx2. You might even prefer to run avx-512 for cores that can and avx2 for those that can't ... but you need to be able to gather information on what cores support what, and pin your threads so they don't move. If you pull in a library, who knows what they do... lots of libraries assume they can call cpuid at load time and adjust... but now you need that per-thread.

That seems like a lot of change for OS, application, etc. If you run commercial applications, maybe they don't update unless you pay them for an upgrade, and that's a pain, etc.

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

#139

Post by ThrowawayR2 »

x0x0 wrote: post #50
kccqzy wrote: post #34

Earlier quoted context omitted.

That's not mostly because of a better ISA. If Intel and Apple had a chummier relationship you could imagine Apple licensing the Intel x86 ISA and the M series chips would be just as good but running x86. However I suspect no matter how chummy that relationship was, business is business and it is highly unlikely that Intel would give Apple such a license.

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

Intel and AMD are after the very high profit margins of the enterprise server market. They have much less motivation to focus on power efficient mobile chips which are less profitable for them.

Apple's primary product is consumer smartphones and tablets so they are solely focused on power efficient mobile chips.

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

#140

Post by tester756 »

rafaelmn wrote: post #136
tester756 wrote: post #109

Of course, because saying that X ISA is faster than Y ISA is like saying that Java syntax is faster than C# syntax Everything is about the implementation: compiler, JIT, runtime/VM, stdlib, etc. https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter

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.

Post reply on HN