4 ms·

ARM64 (aka AArch64) is the best version of x86 yet. It's clean, very little warts, they learned from their mistakes with ARMv7/Thumb2 (specifically the IT inst

ARM64 (aka AArch64) is the best version of x86 yet. It's clean, very little warts, they learned from their mistakes with ARMv7/Thumb2 (specifically the IT instruction). It helps that Apple controls the whole ecosystem and could seamlessly move to ARM64. The Android transition has been making progress also. Maybe someday we'll drop 32bit and 16bit support in x86 systems (and also in "modern" programming languages!).

shakna 7y ago
> ARM64 (aka AArch64) is the best version of x86 yet. Huh? Isn't that ARM and not even remotely compatible with x86?
- withzombies 7y ago
  ARM64 is what Intel would design if they learned from the lessons of x86 and got a chance to restart.
  - solarexplorer 7y ago
    Well, actually they did try a few times. Itanic and the Intel iAPX 432 come to mind...
  - unlinked_dll 7y ago
    https://en.wikipedia.org/wiki/IA-64 https://en.wikipedia.org/wiki/IA-64
  - monocasa 7y ago
    I'm sure that's not true. I've heard a great rant from an Intel CPU engineer about how CISC is a great fit for large OoO cores. Like how memory RMW instructions can be thought of as allocating physical register file resources with no architectural register file requirements, no extra instruction stream bits required, and no confusions inside the core about register data dependencies of the instruction. It'd be fun to throw together a modern CISC-V or something that does a better job than x86 from an instruction encoding efficiency perspective, and see how it stacks up against modern RISCs.
    - PeCaN 7y ago
      >It'd be fun to throw together a modern CISC-V or something that does a better job than x86 from an instruction encoding efficiency perspective, and see how it stacks up against modern RISCs. It'd probably be about the same since the combination of microcode and macroop fusion makes RISC and CISC essentially the same thing internally. You're basically just trading complexity of the instruction decoder for code density.
adwn 7y ago
> Maybe someday we'll drop 32bit and 16bit support in x86 systems (and also in "modern" programming languages!). You do realize that there exists a world beyond desktop and server CPUs, right? There are plenty of 32-bit embedded microprocessors, and plenty of applications where a 64-bit processor would be overkill.
wtarreau 7y ago
Thumb2 was good. The main issue with AArch64 is that they dropped the variable instruction length. As such all instructions are huge and this significantly slows down code, especially after a mispredicted branch. I'm observing on average a 20% performance loss from thumb2 to aarch64 on the exact same CPU and same kernel, just switching executables, an d 40% larger code or so. Also something to consider, an A53 can only read 64 bits per cycle from the cache, i.e. just two instructions. That doesn't even allow it to fetch a bit more and start to decode in advance.

shakna 7y ago

> ARM64 (aka AArch64) is the best version of x86 yet. Huh? Isn't that ARM and not even remotely compatible with x86?

withzombies 7y ago
ARM64 is what Intel would design if they learned from the lessons of x86 and got a chance to restart.
- solarexplorer 7y ago
  Well, actually they did try a few times. Itanic and the Intel iAPX 432 come to mind...
- unlinked_dll 7y ago
  https://en.wikipedia.org/wiki/IA-64 https://en.wikipedia.org/wiki/IA-64
- monocasa 7y ago
  I'm sure that's not true. I've heard a great rant from an Intel CPU engineer about how CISC is a great fit for large OoO cores. Like how memory RMW instructions can be thought of as allocating physical register file resources with no architectural register file requirements, no extra instruction stream bits required, and no confusions inside the core about register data dependencies of the instruction. It'd be fun to throw together a modern CISC-V or something that does a better job than x86 from an instruction encoding efficiency perspective, and see how it stacks up against modern RISCs.
  - PeCaN 7y ago
    >It'd be fun to throw together a modern CISC-V or something that does a better job than x86 from an instruction encoding efficiency perspective, and see how it stacks up against modern RISCs. It'd probably be about the same since the combination of microcode and macroop fusion makes RISC and CISC essentially the same thing internally. You're basically just trading complexity of the instruction decoder for code density.

adwn 7y ago

> Maybe someday we'll drop 32bit and 16bit support in x86 systems (and also in "modern" programming languages!). You do realize that there exists a world beyond desktop and server CPUs, right? There are plenty of 32-bit embedded microprocessors, and plenty of applications where a 64-bit processor would be overkill.

wtarreau 7y ago

Thumb2 was good. The main issue with AArch64 is that they dropped the variable instruction length. As such all instructions are huge and this significantly slows down code, especially after a mispredicted branch. I'm observing on average a 20% performance loss from thumb2 to aarch64 on the exact same CPU and same kernel, just switching executables, an d 40% larger code or so. Also something to consider, an A53 can only read 64 bits per cycle from the cache, i.e. just two instructions. That doesn't even allow it to fetch a bit more and start to decode in advance.