undefined | Better HN

0 pointsamluto5y ago0 comments

I would argue that ISA does matter. Beyond the decode width issue, x86 has some material warts compared to ARM64:

The x86 atomic operations are fundamentally expensive. ARM’s new LSE extensions are more flexible and can be faster. I don’t know how much this matters in practice, but there are certainly workloads for which it’s a big deal.

x86 cannot context-switch or handle interrupts efficiently. ARM64 can. This completely rules x86 out for some workloads.

ARM64 has TrustZone. x86 has SMM. One can debate the merits of TrustZone. SMM has no merits.

Finally, x86 is more than an ISA - it’s an ecosystem, and the x86 ecosystem is full of legacy baggage. If you want an Intel x86 solution, you basically have to also use Intel’s chipset, Intel’s firmware blobs, Intel’s SMM ecosystem, all of the platform garbage built around SMM, Intel’s legacy-on-top-of-legacy poorly secured SPI flash boot system, etc. This is tolerable if you are building a regular computer and can live with slow boot and with SMM. But for more embedded uses, it’s pretty bad. ARM64 has much less baggage. (Yes, Intel can fix this, but I don’t expect them to.)

0 comments

jabl5y ago

> The x86 atomic operations are fundamentally expensive. ARM’s new LSE extensions are more flexible and can be faster. I don’t know how much this matters in practice, but there are certainly workloads for which it’s a big deal.

There's also the RcPc stuff in ARM 8.3 and 8.4 that could make acquire/release semantics cheaper.

> the x86 ecosystem is full of legacy baggage.

Luckily for ARM servers we have SBSA that adds things like UEFI and ACPI to the ARM platform. :)

stefan_5y ago

That baggage means I can at least boot an Intel system without first building my own device tree, then hacking the kernel to actually make it work. Meanwhile over in ARM M1 land, they apparently managed to break wfi.

j / k navigate · click thread line to collapse