Will the workloads exist? As in not going straight to something at least as dedicated as the Strix Halo CPU/GPU combo (with air quotes around the G)? Or the Apple max? Somehow I don't picture this as an attempt to make a full AI rig that just happens to be x86 in the housekeeping parts but just something that will make CPU inference a little less bad. In that case it would at best be a hedge against some low requirements use case becoming more important than expected, yet another unused spec sheet checkbox engineering marvel otherwise.
Dedicated PCIe or memory-attached inference units will continue to exist, and will continue to do the heavy lifting, but an ISA extension provides latencies any external unit would have trouble matching. You can, with some work, extract some decent throughput with CPUs alone, with a large enough CPU you can use for non-AI jobs the rest of the time. There was a nice writeup not that long ago here on HN describing the flags and the reasoning behind them to use on that specific machine.
This all went over my head, but does anyone know either how much faster this will make things (4x faster than AVX512 at 2048-bit??), and if unified memory plus a basic GPU will render this dead in the water?
FWIW, I wouldn't be surprised if you only have a couple threads using this at a time max since it looks an awful lot Apple's AMX/SME stuff. Those Apple execution units only have single engines shared about per cluster.
XSAVE lets you not bother saving register state that user space hasn't changed at the granularity of each large feature.
Great article. What does the (organizational) process look like to convert one of these specs to a processor product, does it go through a committee like the C++ standards?
> AMD, in partnership with Intel and the x86 EAG (Ecosystem Advisory
Group) [EAG24], is readying ACE as the standard matrix acceleration architecture for x86, further enhancing the already
vibrant x86 ecosystem.
Now I wonder how many such "extension packages" Intel (and AMD?) have introduced since MMX (which I believe was the first, and interestingly enough didn't have an official meaning - https://en.wikipedia.org/wiki/MMX_(instruction_set)) in 1997?
Well... They are registers, so yes. The question is whether it'd make sense to do it and what problem would that solve.
In a past life, I taught young programmers you can, of course, make a phone number a numeric field in your database (and save a couple bytes by doing that!) but it'd only make sense if you wante to figure out the average phone number for all your clients so you could call them all at once.
There are extreme cases where it would actually make sense, but that I usually left to dig into in a later discussion.
I don't know enough about phone numbers to say whether you could encode them as an int anyway. In the UK all standard numbers start 0 and international codes start 00? Of course you could introduce a 'locale' and then 20 years later try to solve that mess with multiple ways of representing international numbers. Or maybe not teach young programmers that you can make the phone number a numeric field?
So it seems to me the solution is to save them as BCD...
Will the workloads exist? As in not going straight to something at least as dedicated as the Strix Halo CPU/GPU combo (with air quotes around the G)? Or the Apple max? Somehow I don't picture this as an attempt to make a full AI rig that just happens to be x86 in the housekeeping parts but just something that will make CPU inference a little less bad. In that case it would at best be a hedge against some low requirements use case becoming more important than expected, yet another unused spec sheet checkbox engineering marvel otherwise.
Dedicated PCIe or memory-attached inference units will continue to exist, and will continue to do the heavy lifting, but an ISA extension provides latencies any external unit would have trouble matching. You can, with some work, extract some decent throughput with CPUs alone, with a large enough CPU you can use for non-AI jobs the rest of the time. There was a nice writeup not that long ago here on HN describing the flags and the reasoning behind them to use on that specific machine.
Funny thing, I can't find the article.
I assume Zen 6 won't support these, so we are looking Zen 7 at the earliest, which is 2028 earliest.
In the meantime x86 don't have much in the roadmap that compete well with ARM vendor's offering. And that was before Nvidia decided to join the fight.
This all went over my head, but does anyone know either how much faster this will make things (4x faster than AVX512 at 2048-bit??), and if unified memory plus a basic GPU will render this dead in the water?
With 8kb of registers for just this one feature, what does a modern process-control-block look like?
On x86, basically whatever XSAVE writes out.
FWIW, I wouldn't be surprised if you only have a couple threads using this at a time max since it looks an awful lot Apple's AMX/SME stuff. Those Apple execution units only have single engines shared about per cluster.
XSAVE lets you not bother saving register state that user space hasn't changed at the granularity of each large feature.
Great article. What does the (organizational) process look like to convert one of these specs to a processor product, does it go through a committee like the C++ standards?
> AMD, in partnership with Intel and the x86 EAG (Ecosystem Advisory Group) [EAG24], is readying ACE as the standard matrix acceleration architecture for x86, further enhancing the already vibrant x86 ecosystem.
Source: https://x86ecosystem.org/wp-content/uploads/2026/03/ACE-Whit...
"Vibrant" is certainly one way to describe it...
AI Compute Extensions, ACE.
Also, AMX = Advanced Matrix Extensions.
Now I wonder how many such "extension packages" Intel (and AMD?) have introduced since MMX (which I believe was the first, and interestingly enough didn't have an official meaning - https://en.wikipedia.org/wiki/MMX_(instruction_set)) in 1997?
https://www.sandpile.org/x86/cpuid.htm#leaf_0000_0001h_more
Then click "...details for the "generations" of Intel's vector instructions."
Beware, it's dense acronym soup. :)
Could the registers potentially be used to store encryption keys?
Well... They are registers, so yes. The question is whether it'd make sense to do it and what problem would that solve.
In a past life, I taught young programmers you can, of course, make a phone number a numeric field in your database (and save a couple bytes by doing that!) but it'd only make sense if you wante to figure out the average phone number for all your clients so you could call them all at once.
There are extreme cases where it would actually make sense, but that I usually left to dig into in a later discussion.
How do you represent a leading 0?
I don't know enough about phone numbers to say whether you could encode them as an int anyway. In the UK all standard numbers start 0 and international codes start 00? Of course you could introduce a 'locale' and then 20 years later try to solve that mess with multiple ways of representing international numbers. Or maybe not teach young programmers that you can make the phone number a numeric field?
So it seems to me the solution is to save them as BCD...