There's nothing that requires closed boot loaders and locked OSes on ARM, nor is there anything preventing the same on X64. Most X64 chips have embedded security processors that can and sometimes are used to do just that, while the Raspberry Pi and countless other ARM boards are fairly open.

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.

Raspberry pi needs proprietary blob to boot. It is not "fairly open".

ARM will definitely need a BIOS interface standard before it sees big traction in servers, desktops, and cloud. There's apparently some work going on here. As it stands there just hasn't been a big motive to create such a standard because ARM has mostly been used on embedded and mobile devices that ship with canned images anyway.

The advantage of ARM fixed length decoder is probably largely irrelevant in laptop/desktop segment. Memory model has probably much bigger effect although that's not exactly clear yet either.

But overall people assign too much weight to ISA, especially in case of M1 and forget other aspects of the CPU design.

The fixed length encoder means more in those segments.

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.

Isn't Power also fixed-length? Why isn't POWER9 killing it?

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

Well I see in my testing and use 20% more performance and 30% _less_ cost with AWS Graviton 2 ARM instances vs x86. The cost savings can be enormous. The bottom line of your company doesn't really care about bootloaders and OS 'freedom'.

I was thinking more of my workstation. If I lose access to free software, I might as well just leave the whole industry and stop using technology.

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.

¯\_(ツ)_/¯ I'm with you on not enjoying loss of access to my hardware and getting further and further away from the metal. But also, we gotta make a living and pay the bills... it's a competitive disadvantage with online services to be using more expensive to run instances.

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.