@Gavin , These 2 statements are in contravention of each other. Will new processors support both AVX10 and AVX-512 or not?
"AVX10, by default, will allow developers that recompile their preexisting code to work with AVX10, as new processors with AVX10 won't be able to run AVX-512 binaries as they previously would have."
"While AVX-512 isn't going anywhere as an instruction set, it's worth highlighting that AVX10 is backward compatible, which is an essential aspect of supporting instruction sets with various vector widths such as 128, 256, and 512-bit where applicable."
A Xeon processor with only P-cores capable of running AVX-512 by nature of having wide enough vector processing will be able to directly support AVX-512. This should continue forward.
New processors that support AVX-512 operations via AVX10 due to the presence of Atom cores will require recompiled binaries.
To clarify the two different quotes. AVX-512 will still be there as it's a superset, hence the backward compatibility that AVX10 offers. Having x86 backward compatibility is important.
AVX10 will replace AVX-512 going forward, and developers, where applicable, can recompile to ensure compatibility and leverage the efficiency and performance bonuses.
Intel has alluded to divulging whether or not 512-bit wide vectors will be supported on chips and cores going forward, but they have committed to support 256-bit at the very least.
The author of the article did a poor job understanding and rephrasing what Intel really does. Those who are still confused should consult Intel's original document. From my understanding reading the Intel document, what Intel wanna to do is similar to ARM's SVD, where you may have a higher vector length instruction set, but such instruction set can still run on lower vector-length hardware. And this is exactly what Intel does here, making the AVX512 instruction set to be the norm, adding additional features and layers and rename it AVX10. But being different from AVX512, AVX10 can run your avx512 instructions on 256-bit and 128-bit vector length hardwares, the implementation is essentially compiler and hardware dependent, it can be similar to AMD's double pumping for its avx512 implementation on Zen4 with only 256bit vector length registers. So AVX10 is an evolution upon AVX512, it will be convergent unified ISA that will run on all future intel chips with various register length, how it runs on lower-width registers are compiler and hardware dependent.
I have looked at both documents on AVX10, and I see nothing that would allow the same piece of code to work with 512-bit instructions on one core and with 256-bit instructions on a less capable core.
Moreover, even ARM SVE does not allow to migrate running threads between cores with different vector widths; that's because the migration may be in the middle of some SVE code, with decisions taken based on the SIMD width on the original core, and this would not work on a narrower core.
AMD shows with Zen4 that the limitation of E-cores to 256 bits and the resulting instruction-set SNAFU is completely unnecessary. Intel could implement 512-bit SIMD on E-cores with little area cost by splitting the 512-bit stuff into two 256-bit parts in hardware, instead of dumping this burden on the software developer.
> Those who are still confused should consult Intel's original document.
Did you? Because, it sure doesn't sound like it!
> what Intel wanna to do is similar to ARM's SVD
First, it's SVE. Second, AntonErtl is exactly right that the operand size of AVX10 instructions is fixed at compile time. So, not really like SVE, at all.
> AVX10 can run your avx512 instructions on 256-bit and 128-bit vector length hardwares
No. Not even close.
> it can be similar to AMD's double pumping for its avx512 implementation on Zen4
The main difference is the register file. AVX10/256 only requires 256-bit registers. For Zen 4, AMD needed at least (the equivalent of) 32x 512-bit registers.
Also, some AVX-512 instructions can't be neatly split into 2x 256-bit halves and needed special accommodation.
Will AMD be able to use the new extensions in their new products, or will they have to licensee out the AVX10 IP first? Or perhaps they'll create their own extensions?
Honestly what are you talking about? AMD and Intel have cross-licensed for close to multiple decades.
For the most part, the extension wars are tame at this point. AVX-512 is a bit of a debacle, but the last minor standoff (FMA3 vs FMA4) was nearly a decade ago.
Most notably, AMD64, the introduction of 64 bit extensions to the preexisting ISA by AMD was a fork compared to Intel's methods. On the Intel front, Itanium was another twist on the x86 arch that failed. I could give more examples going throughout history.
Itanium was not a twist on the x86 architecture at all! It bordered VLIW and shared very little, in part to escape dealing with other x86 competition (reminder that VIA was still viable, Transmeta was a recent threat, and there's probably at least one more I've forgotten).
"I could give more examples going throughout history." There's like 3 or 4 extension standoffs total between 2000 and the FMA3/FMA4 standoff, which wasn't even that bad, and most of them happened before AMD64. Intel has mostly been the first-mover on instructions, and AMD has mostly implemented them soon after. AMD had incentive to push FMA because of its unique Bulldozer-era architecture, and delivered a short-sighted solution. The same thing essentially happened in reverse with AVX-512, where Intel had the larger core by die area and was incentivized to build a high-complexity instruction to turn its weakness into an advantage.
> Itanium was not a twist on the x86 architecture at all! My apologies, I was wrong here. But as I was trying to make the point above, it's still IP Intel was trying to use against it's competition.
I agree that there are not a lot of extension standoffs, but I don't see how that affects my question or my point that a standoff is possible.
Wasn't it Intel which did Hyper-Threading first, which was so countercurrent to the way AMD was doing their version. That it caused a gulf in performance and efficiency between the products. And it was compounded by the fact that Intel had the cutting-edge lithography at the time, whilst AMD was struggling with their GlobalFoundaries nodes.
In effect, any software that wasn't optimised for Intel actually ran bad on Intel Core-i chipsets, and only slightly worse on AMD chipsets. Meaning the AMD did run a bit thirstier, hotter, louder, and slower but more cheaper/value for money. That's what was initially observed back in the 2007-2010 era, whilst it was AMD that was dominant the previous generation.
As soon as you compared them with benchmarks, or software tasks, that adopted Intel's new Core-i Instruction Sets. Thanks in part to Windows/Microsoft. What you saw was a big disparity, and those software optimisations and shortcuts became the norm. By the time it was 2012, Intel had a huge lead in hardware, software, and program/market adoption.
So I am all for Intel with AVX10 since this sounds like clever maths to better optimise software into hardware. I just wish it won't create an artificial gulf, something that Intel would love to use to try to catch up to AMDs currently superior products. Sort of like what Nvidia has tried time and time again against the Radeon Graphics division.
Okay but there isn't going to be an extension standoff here because AMD basically already implemented AVX512 in a way that is formalized by AVX10.
Your question started as "this is bad because AMD might not get to license it!" when that's actually impossible. Even during the FMA3/FMA4 small standoff, both Intel and AMD automatically had licenses to each others' instruction additions, they just preferred their own for the reasons I discussed.
The only thing Intel can use this for as a point of differentiation is with enabling Meteor Lake client and their next-gen server product to deliver AVX-512 in a mixed core design. Server-space Intel has never lost AVX-512 as they never mixed core designs, and client-space, AMD is ahead now, so this just brings parity.
I would be much more concerned with AI extensions in the GPU space (and I guess also CPU space) being used for artificial segmentation. There is truly nothing to see here.
Someone from AMD doesn't spell out what happened here in particular, but suggests it tends to work out--large developers, customers, etc. really want one instruction set to target: https://twitter.com/philparkbot/status/16836234897...
Worth remembering it's gone both directions; there are places you'll still see x86-64 called "amd64".
So AVX10 doesn't have mandatory support for 512 bit ops on efficiency cores? That would be a big barrier to adoption because then you'd need to write 2 sets of functions. Why don't they use temporal SIMD to execute those 512 bit ops over multiple cycles? That will still get the benefit of amortizing the instruction processing cost.
Sorry,if its rather offtopic, but couldnt find any recent matching topic for my question: did Anandtech write any such Intel cpu mega test comparing all (most?) core i generations up to gen 10/11, or at least past Skylake?
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
27 Comments
Back to Article
ballsystemlord - Tuesday, July 25, 2023 - link
@Gavin , These 2 statements are in contravention of each other. Will new processors support both AVX10 and AVX-512 or not?"AVX10, by default, will allow developers that recompile their preexisting code to work with AVX10, as new processors with AVX10 won't be able to run AVX-512 binaries as they previously would have."
"While AVX-512 isn't going anywhere as an instruction set, it's worth highlighting that AVX10 is backward compatible, which is an essential aspect of supporting instruction sets with various vector widths such as 128, 256, and 512-bit where applicable."
brucethemoose - Tuesday, July 25, 2023 - link
Its backwards compatible with code, but not necessarily with avx512 binaries.lmcd - Tuesday, July 25, 2023 - link
A Xeon processor with only P-cores capable of running AVX-512 by nature of having wide enough vector processing will be able to directly support AVX-512. This should continue forward.New processors that support AVX-512 operations via AVX10 due to the presence of Atom cores will require recompiled binaries.
mode_13h - Tuesday, August 22, 2023 - link
> New processors that support AVX-512 operations via AVX10 due to the presence of Atom coresNope. Intel is very clear that hybrid CPUs will support only AVX10/256. That seems unlikely to change until AVX10/512 reaches the E-cores.
Gavin Bonshor - Tuesday, July 25, 2023 - link
Hey Ballsytemlord.To clarify the two different quotes. AVX-512 will still be there as it's a superset, hence the backward compatibility that AVX10 offers. Having x86 backward compatibility is important.
AVX10 will replace AVX-512 going forward, and developers, where applicable, can recompile to ensure compatibility and leverage the efficiency and performance bonuses.
Intel has alluded to divulging whether or not 512-bit wide vectors will be supported on chips and cores going forward, but they have committed to support 256-bit at the very least.
ballsystemlord - Tuesday, July 25, 2023 - link
Thanks guys!quasar_x - Thursday, July 27, 2023 - link
The author of the article did a poor job understanding and rephrasing what Intel really does. Those who are still confused should consult Intel's original document. From my understanding reading the Intel document, what Intel wanna to do is similar to ARM's SVD, where you may have a higher vector length instruction set, but such instruction set can still run on lower vector-length hardware. And this is exactly what Intel does here, making the AVX512 instruction set to be the norm, adding additional features and layers and rename it AVX10. But being different from AVX512, AVX10 can run your avx512 instructions on 256-bit and 128-bit vector length hardwares, the implementation is essentially compiler and hardware dependent, it can be similar to AMD's double pumping for its avx512 implementation on Zen4 with only 256bit vector length registers. So AVX10 is an evolution upon AVX512, it will be convergent unified ISA that will run on all future intel chips with various register length, how it runs on lower-width registers are compiler and hardware dependent.AntonErtl - Monday, July 31, 2023 - link
I have looked at both documents on AVX10, and I see nothing that would allow the same piece of code to work with 512-bit instructions on one core and with 256-bit instructions on a less capable core.Moreover, even ARM SVE does not allow to migrate running threads between cores with different vector widths; that's because the migration may be in the middle of some SVE code, with decisions taken based on the SIMD width on the original core, and this would not work on a narrower core.
AMD shows with Zen4 that the limitation of E-cores to 256 bits and the resulting instruction-set SNAFU is completely unnecessary. Intel could implement 512-bit SIMD on E-cores with little area cost by splitting the 512-bit stuff into two 256-bit parts in hardware, instead of dumping this burden on the software developer.
mode_13h - Tuesday, August 22, 2023 - link
> Those who are still confused should consult Intel's original document.Did you? Because, it sure doesn't sound like it!
> what Intel wanna to do is similar to ARM's SVD
First, it's SVE. Second, AntonErtl is exactly right that the operand size of AVX10 instructions is fixed at compile time. So, not really like SVE, at all.
> AVX10 can run your avx512 instructions on 256-bit and 128-bit vector length hardwares
No. Not even close.
> it can be similar to AMD's double pumping for its avx512 implementation on Zen4
The main difference is the register file. AVX10/256 only requires 256-bit registers. For Zen 4, AMD needed at least (the equivalent of) 32x 512-bit registers.
Also, some AVX-512 instructions can't be neatly split into 2x 256-bit halves and needed special accommodation.
ballsystemlord - Tuesday, July 25, 2023 - link
Will AMD be able to use the new extensions in their new products, or will they have to licensee out the AVX10 IP first?Or perhaps they'll create their own extensions?
brucethemoose - Tuesday, July 25, 2023 - link
And that is the critical question.In a perfect world, Intel fells the pressure from ARM SVE2/TSX like they should, and gave AMD this extension *before* the announcement.
lmcd - Tuesday, July 25, 2023 - link
Honestly what are you talking about? AMD and Intel have cross-licensed for close to multiple decades.For the most part, the extension wars are tame at this point. AVX-512 is a bit of a debacle, but the last minor standoff (FMA3 vs FMA4) was nearly a decade ago.
ballsystemlord - Tuesday, July 25, 2023 - link
As you just pointed out, a debacle can happen.Most notably, AMD64, the introduction of 64 bit extensions to the preexisting ISA by AMD was a fork compared to Intel's methods. On the Intel front, Itanium was another twist on the x86 arch that failed. I could give more examples going throughout history.
Suffice it to say, nothing "is set in stone."
lmcd - Tuesday, July 25, 2023 - link
Itanium was not a twist on the x86 architecture at all! It bordered VLIW and shared very little, in part to escape dealing with other x86 competition (reminder that VIA was still viable, Transmeta was a recent threat, and there's probably at least one more I've forgotten)."I could give more examples going throughout history." There's like 3 or 4 extension standoffs total between 2000 and the FMA3/FMA4 standoff, which wasn't even that bad, and most of them happened before AMD64. Intel has mostly been the first-mover on instructions, and AMD has mostly implemented them soon after. AMD had incentive to push FMA because of its unique Bulldozer-era architecture, and delivered a short-sighted solution. The same thing essentially happened in reverse with AVX-512, where Intel had the larger core by die area and was incentivized to build a high-complexity instruction to turn its weakness into an advantage.
ballsystemlord - Tuesday, July 25, 2023 - link
> Itanium was not a twist on the x86 architecture at all!My apologies, I was wrong here. But as I was trying to make the point above, it's still IP Intel was trying to use against it's competition.
I agree that there are not a lot of extension standoffs, but I don't see how that affects my question or my point that a standoff is possible.
Kangal - Wednesday, July 26, 2023 - link
Wasn't it Intel which did Hyper-Threading first, which was so countercurrent to the way AMD was doing their version. That it caused a gulf in performance and efficiency between the products. And it was compounded by the fact that Intel had the cutting-edge lithography at the time, whilst AMD was struggling with their GlobalFoundaries nodes.In effect, any software that wasn't optimised for Intel actually ran bad on Intel Core-i chipsets, and only slightly worse on AMD chipsets. Meaning the AMD did run a bit thirstier, hotter, louder, and slower but more cheaper/value for money. That's what was initially observed back in the 2007-2010 era, whilst it was AMD that was dominant the previous generation.
As soon as you compared them with benchmarks, or software tasks, that adopted Intel's new Core-i Instruction Sets. Thanks in part to Windows/Microsoft. What you saw was a big disparity, and those software optimisations and shortcuts became the norm. By the time it was 2012, Intel had a huge lead in hardware, software, and program/market adoption.
So I am all for Intel with AVX10 since this sounds like clever maths to better optimise software into hardware. I just wish it won't create an artificial gulf, something that Intel would love to use to try to catch up to AMDs currently superior products. Sort of like what Nvidia has tried time and time again against the Radeon Graphics division.
mode_13h - Tuesday, August 22, 2023 - link
> Wasn't it Intel which did Hyper-Threading firstAmong x86, yes. There were many SMT implementations before Intel introduced their Pentium 4's with "Hyperthreading Technology".
mode_13h - Tuesday, August 22, 2023 - link
BTW, AMD doesn't call it "Hyperthreading". That's still just Intel's branding. I think AMD just uses the industry standard term of SMT.mode_13h - Tuesday, August 22, 2023 - link
And Hyperthreading isn't an ISA extension, BTW.lmcd - Friday, July 28, 2023 - link
Okay but there isn't going to be an extension standoff here because AMD basically already implemented AVX512 in a way that is formalized by AVX10.Your question started as "this is bad because AMD might not get to license it!" when that's actually impossible. Even during the FMA3/FMA4 small standoff, both Intel and AMD automatically had licenses to each others' instruction additions, they just preferred their own for the reasons I discussed.
The only thing Intel can use this for as a point of differentiation is with enabling Meteor Lake client and their next-gen server product to deliver AVX-512 in a mixed core design. Server-space Intel has never lost AVX-512 as they never mixed core designs, and client-space, AMD is ahead now, so this just brings parity.
I would be much more concerned with AI extensions in the GPU space (and I guess also CPU space) being used for artificial segmentation. There is truly nothing to see here.
mode_13h - Tuesday, August 22, 2023 - link
> Server-space Intel has never lost AVX-512 as they never mixed core designsSierra Forest is their "all E-core" Xeon, and will not have AVX-512.
dotjaz - Thursday, September 7, 2023 - link
>Sierra Forest is their "all E-core" Xeon, and will not have AVX-512.And? has never = will not?
twotwotwo - Tuesday, July 25, 2023 - link
Someone from AMD doesn't spell out what happened here in particular, but suggests it tends to work out--large developers, customers, etc. really want one instruction set to target: https://twitter.com/philparkbot/status/16836234897...Worth remembering it's gone both directions; there are places you'll still see x86-64 called "amd64".
iAPX - Wednesday, July 26, 2023 - link
iNtel Advanced Processor eXtension, for the 8086 also dubbed iAPX 86.Now Intel APX (IAPX), this is confusing :)
YaleZhang - Thursday, July 27, 2023 - link
So AVX10 doesn't have mandatory support for 512 bit ops on efficiency cores? That would be a big barrier to adoption because then you'd need to write 2 sets of functions. Why don't they use temporal SIMD to execute those 512 bit ops over multiple cycles? That will still get the benefit of amortizing the instruction processing cost.soder - Thursday, August 17, 2023 - link
Sorry,if its rather offtopic, but couldnt find any recent matching topic for my question: did Anandtech write any such Intel cpu mega test comparing all (most?) core i generations up to gen 10/11, or at least past Skylake?mode_13h - Tuesday, August 22, 2023 - link
Perhaps you mean this?https://www.anandtech.com/show/14043/upgrading-fro...