3 ms·

This is hopeful. Whatever the ARM enthusiasts would like, x86 is going to stick around for a long time, and working together to evolve the ISA extensions in a m

This is hopeful. Whatever the ARM enthusiasts would like, x86 is going to stick around for a long time, and working together to evolve the ISA extensions in a more cohesive manner would go a long way. In particular, I'd really like AMD and Intel to get on the same page in terms of avx10 / avx512 support. Many people correctly note that avx512 support is not super relevant today, but this can be laid heavily at the feet of Intel's process troubles and a terrible decision to use ISA for market segmentation purposes. Zen4/zen5 show that it is possible to implement wide vector units on a cpu in an extremely beneficial way - even if you're running reduced width execution units under the hood, the improved frontend performance is really useful - and also actually saves power, as the decoders and schedulers account for a fair chunk of power consumption these days.

adgjlsfhk1 2y ago
honestly, as exciting as proper AVX-512 support will be, I am probably at least as excited for APX (16->32 general purpose registers). It brings x86 inline with ARM and RISCV, and just generally makes it a lot easier for compilers to not spill registers to the stack.
- Remnant44 2y ago
  Agreed.. in a lot of ways, APX is like AVX(512) for scalar code. Double integer register count, three-operand instructions, improved predication support including conditional load/stores.. If I remember correctly, they actually implement it by having the scalar instructions use the EVEX prefix introduced with avx512. I would really love to seem them settle on APX + AVX10/512 as a next-generation x86 baseline.
emn13 2y ago
Phoronix has a specific benchmark subset that tries to tease out (at least for zen5) a hint of how much the wider data-path matters vs. how much the frontend/ISA extension itself, by disabling those selectively on an epyc zen5 chip: https://www.phoronix.com/review/amd-epyc-9755-avx512 https://www.phoronix.com/review/amd-epyc-9755-avx512 It's pretty clear that the ISA/frontend is much more impactful than the data-width on this set of workloads, and that also seems to jive with more indirect evidence from performance patterns more broadly. i.e. it's the new instructions (and potentially register width) that matter significantly more than the actually wider data-path.
snvzz 2y ago
>x86 is going to stick around for a long time It won't. Due to its licensing, x86 does not stand a chance against RISC-V. Especially not after Apple, Microsoft and others (e.g. Box64) have demonstrated ability to run x86 code elsewhere reasonably well, thus providing a clear migration path. These actions by AMD and Intel are seen as a desperate attempt to keep x86-64 relevant. As non-x86 hardware increasingly shows up and runs legacy code with little issue, x86 is doomed.
- netbsdusers 2y ago
  It's exactly because of licencing that the situation with RISC-V is a world of proprietary SoCs with no consistency, as opposed to the open system that is an x86 PC. (That the ISA is or isn't open is trifling and matters to neither user nor kernel developer.) Essentially every single board requires its very own custom port of your preferred OS. I will wait for x86's doom, but it will take patience. After all, people have been saying it's dying and will be replaced by some RISC alternative for over 30 years now.
  - snvzz 2y ago
    >It's exactly because of licencing that the situation with RISC-V is a world of proprietary SoCs with no consistency, as opposed to the open system that is an x86 PC. (That the ISA is or isn't open is trifling and matters to neither user nor kernel developer.) Essentially every single board requires its very own custom port of your preferred OS. Can you cite any sources for this? What makes you say this? Can you cite one (1) example? I ask because it is entirely inconsistent with my experience with the available SoCs and their boards. They all implement the specs that were available at the time of design. Sometimes drafts out of necessity. And all of them use OpenSBI as their machine mode firmware. This is false to the point it reads like FUD to me; It couldn't be further detached from reality.

adgjlsfhk1 2y ago

honestly, as exciting as proper AVX-512 support will be, I am probably at least as excited for APX (16->32 general purpose registers). It brings x86 inline with ARM and RISCV, and just generally makes it a lot easier for compilers to not spill registers to the stack.

Remnant44 2y ago
Agreed.. in a lot of ways, APX is like AVX(512) for scalar code. Double integer register count, three-operand instructions, improved predication support including conditional load/stores.. If I remember correctly, they actually implement it by having the scalar instructions use the EVEX prefix introduced with avx512. I would really love to seem them settle on APX + AVX10/512 as a next-generation x86 baseline.

emn13 2y ago

Phoronix has a specific benchmark subset that tries to tease out (at least for zen5) a hint of how much the wider data-path matters vs. how much the frontend/ISA extension itself, by disabling those selectively on an epyc zen5 chip: https://www.phoronix.com/review/amd-epyc-9755-avx512 https://www.phoronix.com/review/amd-epyc-9755-avx512 It's pretty clear that the ISA/frontend is much more impactful than the data-width on this set of workloads, and that also seems to jive with more indirect evidence from performance patterns more broadly. i.e. it's the new instructions (and potentially register width) that matter significantly more than the actually wider data-path.

snvzz 2y ago

>x86 is going to stick around for a long time It won't. Due to its licensing, x86 does not stand a chance against RISC-V. Especially not after Apple, Microsoft and others (e.g. Box64) have demonstrated ability to run x86 code elsewhere reasonably well, thus providing a clear migration path. These actions by AMD and Intel are seen as a desperate attempt to keep x86-64 relevant. As non-x86 hardware increasingly shows up and runs legacy code with little issue, x86 is doomed.

netbsdusers 2y ago
It's exactly because of licencing that the situation with RISC-V is a world of proprietary SoCs with no consistency, as opposed to the open system that is an x86 PC. (That the ISA is or isn't open is trifling and matters to neither user nor kernel developer.) Essentially every single board requires its very own custom port of your preferred OS. I will wait for x86's doom, but it will take patience. After all, people have been saying it's dying and will be replaced by some RISC alternative for over 30 years now.
- snvzz 2y ago
  >It's exactly because of licencing that the situation with RISC-V is a world of proprietary SoCs with no consistency, as opposed to the open system that is an x86 PC. (That the ISA is or isn't open is trifling and matters to neither user nor kernel developer.) Essentially every single board requires its very own custom port of your preferred OS. Can you cite any sources for this? What makes you say this? Can you cite one (1) example? I ask because it is entirely inconsistent with my experience with the available SoCs and their boards. They all implement the specs that were available at the time of design. Sometimes drafts out of necessity. And all of them use OpenSBI as their machine mode firmware. This is false to the point it reads like FUD to me; It couldn't be further detached from reality.