If I were AMD or Intel, I'd keep investing in HPC, but be terrified that my lead there was just one good ARM BLAS library away from evaporating.
And those are big cores. For a ton of little cores, looks less clear-cut for me because of the communication overhead. (could work out though, but won't be exactly easy).
E: A64FX seems like a really cool chip, but it sure is much easier to get time on AWS than Fugaku. :)
(mandated by Arm ServerReady SR/SBSA, you are not allowed to ship Device Tree there)
(even for 32-bit Windows on Arm, back in the Windows RT times, this was the case. It's a shame that Microsoft decided to lock those down back then)
On more affordable Arm machines, Honeycomb LX2K has an official UEFI firmware (with ACPI) and NVIDIA's Jetson AGX Xavier has an official (but experimental) UEFI+ACPI option.
Those aren't complete yet in mainline when using ACPI. For the LX2K, onboard networking currently doesn't work when using mainline kernels. And for the AGX Xavier, you lose PCIe (until the quirk to support it there is merged, or the ECAM through PSCI patchset) and integrated GPU support.
When using a Windows on Arm laptop, most Qualcomm drivers only have device tree bindings, not ACPI at least at this point. As such, you might need to load a device tree at boot for a more complete experience. (you can look at repos on https://github.com/aarch64-laptops if you have one)
For SBCs, forget about almost anything not named "Raspberry Pi", for which... a third-party UEFI + ACPI firmware is available at https://rpi4-uefi.dev, which allowed the original RPi4 to be certified as SystemReady ES.
A lot of the things that actually drive making people implement UEFI + ACPI is that Windows, RHEL and VMWare ESXi require UEFI + ACPI to boot on 64-bit Arm.
It can see a future where x86 is the modern equivalent of a “mainframe”
I want to be wrong though...
The new M1 Mac is fairly open too in that you can boot non-MacOS OSes on it. It differs from the iPhone and iPad in this way as the Mac is made for a different market niche.
The best way to fight closed devices is to not buy them regardless of their CPU ISA.
ARM is just a different ISA with somewhat superior efficiency characteristics due to fixed length easier to decode instruction encoding. That's about it.
But overall people assign too much weight to ISA, especially in case of M1 and forget other aspects of the CPU design.
X64 decoders are really complex. I've heard 5% of the die. Unlike other parts like the ALU, SSE/AVX, AES engines, etc., the decoder is almost 100% "hot" all the time. This adds significant energy overhead vs. a simpler decoder.
The other problem is that it's hard to decode lots of X64 instructions at once without this energy cost ballooning. Apparently 4X decode is kind of a magic number. Intel cranked it to 6X in Ice Lake and newer with some magic, but beyond 6X is gonna be hard.
The Apple M1 has 8X decode, meaning that it can fully saturate 8 execution units for a lot of instruction level parallelism. Nothing in ARM makes it that hard to go higher. If there's a performance advantage to it we will see 12X, 16X, or even higher decode pipelines.
Another big win for ARM is looser memory semantics, allowing for more memory write reordering and more efficient cache designs.
Overall ARM is just easier to optimize than X64. X86/X64 is only fast because vast amounts of money has been spent optimizing these designs. If the same amount were spent optimizing ARM, we'd be way ahead of where we are now.
P.S. The only area where X64 still really shines is its big complex vector units, but these massive vector instruction sets are to some extent a hack to get around the difficulty of decoding X64 instructions. Think of huge SSE/AVX instructions as big macros. I'm sure ARM will get 256-bit and maybe even 512-bit vector extensions at some point, at which point the gap will shrink a lot in this area too.
P.P.S. SMT / hyperthreading is a hack to get around the difficulty decoding lots of instruction in parallel. It's a way to keep a big parallel core busier. It comes with its own overhead though, which increases power consumption, and is a security minefield. Are there even any SMT ARM cores? It's just not as big of a win when you can add more decode width easily.
EDIT: To answer my first question, it was 32-bit fixed-length. The ISA for POWER10 additionally supports aligned prefixed 64-bit instructions. See section 1.6 in https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1...
It is kind of important for me I do not have to use closed source blobs or operating systems. And I think I'm not the only one.
Btw, I've yet to see a Graviton instance that compiles our Rust project faster than my 3090x workstation. Maybe there is, but it costs a fortune. And what Amazon does here is it just kicks out all competition who cannot build their own CPUs. Then they can ramp up the prices.
In my experience and testing Rust lang is lagging a bit with ARM support. It's not that the language doesn't have good support (it does, it's great and very easy to cross compile), it's that the ecosystem around rust is _very_ x86 focused. Like I saw a simple JSON parsing library decided it would be cool to add SSE and SIMD support and now it doesn't work well on ARM (which has a totally different set of SIMD extensions). I have a strong suspicion your rust projects depend on libs with similar issues--but be ready because once those libs support similar optimizations for ARM, it's going to be super fast.
If you're working on online services and NOT looking at or using ARM servers right now--you are in big trouble and already too late to the game.
I only know about unaligned reads and the weaker memory model, but both of them are already undefined behaviour in C/C++/Rust.