Conversation

Notices

1. Embed this notice
   John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:54:54 JST John Regehr

   is this bullshit? or does ISA not really matter in some fictitious world where we can normalize for process and other factors?

   https://www.techpowerup.com/340779/amd-claims-arm-isa-doesnt-offer-efficiency-advantage-over-x86

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:44 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @regehr @steve To wit: virtual memory is a lie, by design. Uniform memory is a lie. Shared instruction/data memory is a lie. Coherent caches are a lie, caches would rather be _anything_ else. Buses are a lie. Memory-mapped IO is IO lying about being memory. Oh and the data bits and wires are small and shitty enough now that they started lying too and everything is slowly creeping towards ECCing all the things

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:45 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @regehr @steve Basically almost everything that _all_ major ISAs pretend is true about memory at the ISA level is an expensive lie, but one that ~ALL the SW depends on. :)

     ✧✦Catherine✦✧ repeated this.
   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:46 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @regehr @steve For example, it's a goddamn NIGHTMARE doing a high-performance memory subsystem for absolutely anything.

     This whole "shared memory" fiction we're committed to maintaining is a significant drag on all HW, but HW impls of it are just in another league perf-wise than "just" building message-passing and trying to work around it in SW (lots have tried, but there's little code for it and it's a PITA), so we're kind of stuck with it.

   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:54:47 JST John Regehr

     in reply to

     • Fabian Giesen
     • I Can't Believe It's Not Zero!

     @rygorous @steve sure sure

   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:54:48 JST John Regehr

     in reply to

     • Fabian Giesen
     • I Can't Believe It's Not Zero!

     @rygorous @steve I've seen part of a convincing / complete formal spec for x86 and I would run away from any effort to validate an implementation of this

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:48 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @regehr @steve Anecdotally, there's at least 3 (Intel, AMD, Centaur) companies that do this on the regular, and one of them (Centaur) is quite small as such things go.

     I wouldn't want to do it either, but the other thing you gotta keep in mind is that the CPU core, while important, is only part of a SoC and ISA has very little impact on the "everything else".

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:49 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @steve @regehr Anyway, take that with whatever amount of salt you want, but Intel and AMD both are strongly incentivized to seriously look at this.

     They for sure would prefer to sell you x86s because they have decades of experience with that, but they're looking at what it costs them to do it both in capex and in how much it hurts the resulting designs.

     And for the latter, the consistent answer has been "a bit, but not much".

   • Embed this notice
     I Can't Believe It's Not Zero! (steve@discuss.systems)'s status on Tuesday, 09-Sep-2025 10:54:51 JST I Can't Believe It's Not Zero!

     in reply to

     • Fabian Giesen

     @rygorous @regehr yeah, this

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:52 JST Fabian Giesen

     in reply to

     @regehr Eventually, there's nowhere left to hide. For applications where you'd use say an ARM Cortex-M0 or a bare-bones minimal RV32I CPU, I'm not aware of anything x86 past or present that would really make sense.

     Intel did "Quark" a while back which I believe was either a 486 or P5 derivative, so still something like a 5-stage pipelined integer core. If you want to go even lower than that, I don't think anyone has (or wants to do) anything.

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:53 JST Fabian Giesen

     in reply to

     @regehr Some more details:
     - the D/V and toolchain costs are amortized. Broadly speaking, the bigger your ecosystem/market share, the bigger your ability to absorb that cost.
     - This holds for what ARM would call "application" cores; oversimplifying a bit, it's essentially a constant overhead on the design that adds some extra area and pipe stages. It's more onerous for smaller cores, but you need to be really small.

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:54 JST Fabian Giesen

     in reply to

     @regehr Every serious study (both from independent researchers and from vendors themselves) that I've ever seen (and I'm up to 5 or so at this point), broadly, supports this, with some caveats.

     It's not "no difference", but for server/application cores, what differences there are typically somewhere in the single-digit %. You can always find pathological examples, but typically it's not that much.

     There is a real cost to x86s many warts but it's mostly in design/validation cost and toolchains.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:57:21 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @regehr @steve Also, re: ISA efficiency, I like re-posting this, by now, rather old image that shows you what the score really is.

     This was on the Xeon Phis but the general trend holds to this day. (Source: https://people.eecs.berkeley.edu/~ysshao/assets/papers/shao2013-islped.pdf p. 3) NB this is an in-order core with 512b vector units.

     ✧✦Catherine✦✧ repeated this.
   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:57:22 JST John Regehr

     in reply to

     • Fabian Giesen
     • I Can't Believe It's Not Zero!

     @rygorous @steve yep this is more or less how I teach this stuff

     ✧✦Catherine✦✧ repeated this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 09-Sep-2025 11:08:25 JST Rich Felker

     in reply to

     • Fabian Giesen
     • I Can't Believe It's Not Zero!

     @rygorous @regehr @steve If you throw out speculative & ooo execution to make a cpu that actually honors security boundaries, ISA will matter a lot more...

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 11:08:26 JST Fabian Giesen

     in reply to

     • I Can't Believe It's Not Zero!

     @regehr @steve This is one of the bigger reasons for why ISA doesn't matter more.

     Broadly, your uArch is only as good as its data movement, because that shit is what's really expensive, not the logic gates.

     It's things like:
     - how good is your entire memory subsystem
     - how good is your bypass network
     - how good are your register files
     etc.

     It's not like you can't make mistakes in the ISA that will really kill your design, you can. That's what happened to VAX.

   • Embed this notice
     Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 12:44:12 JST Fabian Giesen

     in reply to

     @regehr It's not that x86 couldn't do that, but you'd need to dive even deeper into history, and P5 level is honestly about the lowest anyone still wants to go.

     You could do 286-or-less but that's 16-bit x86 and tooling for that is essentially extinct at this point. You're stuck with old compilers etc.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 18-Jul-2026 13:42:59 JST Rich Felker

     in reply to

     • David Chisnall (*Now with 50% more sarcasm!*)

     @david_chisnall @regehr My objection to the premise: "modern microarchitectures" are bad. You have massive energy efficiency and safety/security advantage throwing them away and doing classical microarchitecture directly aligned with instruction set architecture.

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Saturday, 18-Jul-2026 13:43:00 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     @regehr

     There are two different questions here:

     • Is AArch64 a better ISA for modern microarchitectures than x86-64?
     • Does the architecture limit the performance of an implementation?

     The latter is trivially true. We have a load of examples of dead ends. Stack machines make extracting instruction-level parallelism really hard so lost completely to register machines.

     Complex microcode makes out-of-order execution hard because you have to be able to serialise machine state on interrupt and decoded microops may have a bunch of state that isn't architectural. This one is quite interesting because it's a very sharp step change. Building a microcode engine that works is quite easy: serialise the pipeline, disable interrupts, run a bunch of microops, reenable interrupts. Building one that is efficient and allows multiple microcoded instructions to run in parallel is really hard, but if you do it then the complexity is amortised across a potentially large number of instructions. x86 chips took the first approach until fairly recently because there was a lot of lower-hanging fruit and microcoded instructions were rare. Having one instruction that requires complex microcode is absolutely the worst case.

     Different ISAs favour different implementation choices. AArch32's choice to make the program counter architectural was great on simple pipelines, for example. It made PC-relative addressing trivial (just use PC as the base of any load or add) and made short relative jumps just an add to the PC. This became more annoying for more complex pipelines because you can't tell whether an instruction is a jump until you've done full decode (on most other RISCy ISAs, you can tell from the major opcode), which impacts where you do branch prediction. Similarly, all of the predication in AArch32 is great for avoiding using the branch predictor in common cases with simple pipelines, but you need that state anyway on big out-of-order machines. Thumb-2's if-then-else instruction provided a denser way of packing predication that scales nicely up to dual-issue in-order cores, but really hurts if you want to decode multiple instructions in parallel.

     The question of AArch64 vs x86-64 is much more interesting.

     Register rename is the biggest single consumer of power and the bottleneck on a lot of very high-end implementations. Complex addressing modes really help reduce this overhead, but so do memory-register operations where you avoid needing to keep a rename register live for a value that's used only once.

     At MS, we did a lot of work on dataflow architectures to try to avoid this. This was largely driven by two observations:

     • Around 2/3 of values are used exactly once.
     • Around 2/3 of values (not the same 2/3, but an overlapping set) of values are used only within the same basic block where they are created.

     The theory was that, by encoding this directly in the ISA (input operands were implicit, output operands were the distance in executed instruction stream to the instruction that consumed the result) you'd be able to significantly reduce rename register pressure. Unfortunately, it turned out that speculative execution required you to do something that looked a lot like register rename for these values.

     AArch64 intentionally tries to provide a useful common set of fused operations. x86-64 does it largely by accident, but there isn't a clear winner here.

     The one big win that we found has not really made it into any instruction set, which continues to surprise me. A cheap way of marking a register as dead can massively improve performance. I've seen a 2x speedup on x86 from putting an xor rax, rax at the end of a tight loop because the pipeline was stalling having to keep all of the old rax values around in rename registers, even though no possible successor blocks used them. If I were designing a new ISA, for high-performance systems I'd be tempted to do one of the following:

     • Have a short instruction with a bitmap of dead registers that compilers could insert at end of the basic block for the back arc in a loop to mark multiple registers as dead.
     • Put an extra bit in each source operand to mark it as a kill.

     The latter hurts density, but would probably be a bigger win because it would let you rewrite a load of operations from allocating rename registers to using forwarding in the front end.

     The other bottleneck is parallel decode. A64 ditched the variable-length instruction set that T32 introduced because it makes orthogonal decoding trivial. Fetch 16 bytes, decode four instructions. Apple's implementations make a lot of use of this and also have a nice sideways forwarding path that allows values produced in one instruction to be directly forwarded to a consumer in the same bundle without going via register rename (if the value isn't clobbered, they still need to allocate a rename register).

     x86-64 is staggeringly bad here. As Stephen Dolan quipped, x86 chips don't have an instruction decoder, they have an instruction parser. Instructions can be very long, or as short as a single byte. Mostly this doesn't matter on modern x86-64 chips because 90% of dynamic execution is in loops and modern x86-64 chips do at least some caching of decoded things (at the very least, caching the locations of instruction boundaries, often caching of decoded micro-ops) in loops.

     And this is where it gets really interesting. The extra decode steps and the extra caches add area, but they also save instruction cache by providing a dense instruction encoding (x86-64 isn't perfect there, it's not that close to a Huffman encoding over common instruction sequences, but it's a moderately good approximation). Is that a good tradeoff? It almost certainly varies between processes (the relative power and area costs of SRAM vs logic vary a surprising amount).

     The thing that I find really surprising is the memory model. Arm's weak memory model is supposed to make high-performance implementations easier by enabling more reorderings in the core, whereas x86's TSO is far more constrained. Apple's processors have a mode that (as I understand it) decodes loads and stores into something with the same semantics as the load-acquire / store-release instructions but with the normal addressing modes. It doesn't seem to hurt performance (it's only used by Rosetta 2, so it's hard to do an exact comparison, but x86-64 emulation is ludicrously fast on these machines, so it isn't hurting that much. I'd love to see some benchmarks enabling it by default on everything).

     Doing any kind of apples-to-apples comparison is really hard because things in the architecture force implementation choices. You would not implement an x86-64 and an AArch64 core in exactly the same way. There was a paper at ISCA in 2015 that I absolutely hated (not least because it was used to justify a load of bad design decisions in RISC-V) that claimed it did this, but when you looked at their methodology they'd simulated cores that were not at all how you would implement the ISAs that they were discussing.