3 ms·

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 securit

by api 6y ago

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.

marcodiego 6y ago
Raspberry pi needs proprietary blob to boot. It is not "fairly open".
- api 6y ago
  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_Colonel 6y ago
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.
- api 6y ago
  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.
  - wahern 6y ago
    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.pdf https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1...

by api 6y ago

marcodiego 6y ago

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

api 6y ago
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_Colonel 6y ago

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.

api 6y ago
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.
- wahern 6y ago
  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.pdf https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1...