Intel Continues GCC Compiler Preparations For AVX10 & APX

[phoronix]

Phoronix: Intel Continues GCC Compiler Preparations For AVX10 & APX

Since announcing the Advanced Performance Extensions (APX) and AVX10 back in July, Intel's open-source compiler engineers have been busy preparing the GCC and LLVM/Clang compiler toolchains for these major CPU extensions to be found with future Intel processors...

https://www.phoronix.com/news/Intel-More-GCC-APX-AVX10

[drakonas777]

I still don't understand why Intel could not just implement simple double-pumped AVX512 on E cores and call it a day. It would have made life easier for everyone.

[Setif]

I still don't understand why Intel could not just implement simple double-pumped AVX512 on E cores and call it a day. It would have made life easier for everyone.

because AVX512 consume huge amount of electricity, which is the opposite of what E cores were to meant to be!

[drakonas777]

because AVX512 consume huge amount of electricity, which is the opposite of what E cores were to meant to be!

Not the double-pumped implementation.

The only reason I can think of is they want to minimize E core size to maximize the amount of E cores per silicon surface. In other words minimizing the BOM for client platform die.

[coder]

Not the double-pumped implementation.

I think the "double-pumped" term is doublespeak. It means the opposite of what the words suggest, in this context. It would be more accurate to call it "bifurcated", "half-rate", "half-width", or "folded", but some marketing dork probably thought "double-pumped" sounded way cooler.

The only reason I can think of is they want to minimize E core size to maximize the amount of E cores per silicon surface. In other words minimizing the BOM for client platform die.

What I think it comes down to is that you can probably manage vector registers at half the size of the ISA width. Cutting them down to 1/4th becomes too big of a headache. So, essentially what it could mean for Intel is that the vector portion of their E-cores would need to be natively 256-bit, instead of 128-bit, as they could be, today. If a lot of the code out there is still 128-bit, then it's definitely less efficient to implement it @ 256-bit.

Therefore, not only is it likely to be motivated by die size, but also by efficiency on 128-bit code.

The only reason I can think of is they want to minimize E core size to maximize the amount of E cores per silicon surface. In other words minimizing the BOM for client platform die.

I think not so much BOM, but more about increasing the number of cores you can put on a die - either for a given a price point or just due to logistic constraints. Don't forget that Sierra Forest has 144 of these E-cores on a die!

At the end of the day, if Intel can squeeze in enough E-cores to be competitive with a smaller piece of silicon than they otherwise might've, then they would indeed get some cost savings out of it. However, you have to at least be competitive on a price/performance basis, before you can worry too much about cost savings!

[coder]

BTW, the other half of this patchset is for APX. In my mind, that's actually more interesting. Intel claims a 10% performance improvement on scalar code.