Hacker News Reader

Comment by Remnant44 | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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

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.

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

Reply on news.ycombinator.com