APX + AVX10

[Mysticial]

Originally Posted by retina

I am.

Itanium.

'nuf said.

Oh I don't mean replacing the existing stuff with something new. I was suggesting that they use the proposed REX2 prefix byte to deliminate a new instruction format. Something sane like ARM or whatever. At least put your 5 bits for a register operand together instead of splitting them up across 3 different bytes with random inversions.

So the old x86 stuff would stay as is. The new byte would prefix a new encoding instead of trying to reuse as much of the old (crap) as possible.

[mackerel]

Originally Posted by Mysticial

it's not entirely unexpected since port5's 512-bit unit doesn't split up in 256-bit mode. So you lose the upper half with 256-bit code.

Thanks for the testing.

I'm not awake yet, but I thought Tiger Lake doesn't have the extra FMA unit on port 5? Or are you doing something else? Probably a bad habit for me that I associate AVX with how much FMA you can shove through it!

[Mysticial]

Originally Posted by mackerel

Thanks for the testing.

I'm not awake yet, but I thought Tiger Lake doesn't have the extra FMA unit on port 5? Or are you doing something else? Probably a bad habit for me that I associate AVX with how much FMA you can shove through it!

Port5 can do integer SIMD and shuffles.

[retina]

Originally Posted by Mysticial

I was suggesting that they use the proposed REX2 prefix byte to deliminate a new instruction format. Something sane like ARM or whatever. At least put your 5 bits for a register operand together instead of splitting them up across 3 different bytes with random inversions.

Like this?

REX2 + 4-byte ARM64
REX3 + 4-byte RISC-V
REX4 + 4-byte Alpha

Four CPUs in one.

The PC alignment requirement is completely borked, but I'm sure Intel can figure it out.

[henryzz]

Originally Posted by Mysticial

Intel's E-cores already split 256-bit instructions into 2 x 128-bit. Assuming they don't widen them any time soon, 512-bit would mean quad-pumping. The way AMD double-pumped Zen4 is quite ingenious in that's there's almost no cost to the splitting. So I don't really understand why Intel can't just do the same.

Still doesn't seem to be much disadvantage. Yes, it will take longer but it still needs doing. IMO they should abandon fixed lengths and allow you to request 128*2^x bit instructions. Why fix the instructions to what the hardware can do? Allowing longer requests means free speedups with the same code if intel later widens it in the CPU(which will inevitably happen eventually). I believe ARM took this approach.

[Prime95]

Originally Posted by Mysticial

It looks like Zen4 cannot buffer 8 super-aligned NT-stores across loop iterations for write-combining.

Can you define "super-aligned"? Thanks.

[Mysticial]

Originally Posted by henryzz

Still doesn't seem to be much disadvantage. Yes, it will take longer but it still needs doing. IMO they should abandon fixed lengths and allow you to request 128*2^x bit instructions. Why fix the instructions to what the hardware can do? Allowing longer requests means free speedups with the same code if intel later widens it in the CPU(which will inevitably happen eventually). I believe ARM took this approach.

I haven't studied flex width concepts too much, but I can already see non-trivial issues with it.

If you allow the program to specify the width, you'll run into an issue where the hardware just can't do it. Say the hardware is natively 128-bit, and I request 2048-bit just because I can. The CPU won't have the register state to hold 2048-bit x 32 registers. And if you try to pipe it through memory, you're effectively running without registers. (IOW, slow.)

If you allow the program to ask the hardware for its size so it can adapt, you've now burdened the program with being able to correctly and efficiently run on any vector length. This just isn't feasible for numerous reasons. For example, shuffles are inherently tied to the vector length. And while many applications have length-agnostic algorithms to handle simple things like a general NxN transpose, they are far from trivial and far from being optimal given a specific set of hardware. Then you have cases where the optimal data layout depends on the native vector size.

For example, complex FFTs like to use a semi-interleaved pattern like this:

[r0 r1 r2 r3][i0 i1 i2 i3][r4 r5 r6 r7][i4 i5 i6 i7]

where each vector consists entirely of real or imaginary parts. But the real and imaginary parts are kept together in adjacent vectors for locality purposes.

What happens when this length-dependent data layout has to cross an API abstraction layer? You can't possibly expect both sides of an API to be able to handle flex width.

[Mysticial]

Originally Posted by Prime95

Can you define "super-aligned"? Thanks.

Offset by (multiples of) large powers-of-two. So last N bits of the addresses are identical.

(FWIW, I made a conscious decision not to insert padding at the highest levels. Which would be a separate discussion.)