Is x86 ready to ACE it?

https://chipsandcheese.com/p/is-x86-ready-to-ace-it

by mfiguiere • 9 days ago

107 31 9 days ago

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?

deadmutex• 9 days ago

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

simonask• 9 days ago

"Vibrant" is certainly one way to describe it...

aidenn0• 9 days ago

With 8kb of registers for just this one feature, what does a modern process-control-block look like?

monocasa• 9 days ago

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.

fragmede• 9 days ago

AI Compute Extensions, ACE.

rob74• 9 days ago

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?

3245t345f345g3• 9 days ago

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

ksec• 9 days ago

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.

rando1234• 9 days ago

Could the registers potentially be used to store encryption keys?

rbanffy7• 9 days ago

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.

benj1113• 8 days ago

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

AussieWog93• 9 days ago

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?

cogman10• 8 days ago

It's impossible to say what sort of improvement (if anything) this will give.

My assumption is the determining factor in performance is going to ultimately be memory bandwidth.

and if unified memory plus a basic GPU will render this dead in the water?

Yeah, generally I think that is the case. The main benefit this thing would have is power consumption will likely be lower than what it is to send this operation to the GPU.

usrusr2• 9 days ago

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.

rbanffy7• 9 days ago

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.

usrusr2• 8 days ago

Yeah, I guess in these days of hardware not getting completely outdated even after half a decade, it might well make sense to spend chip area on specialist units that are shut down almost the entire time.

In the old days, when it was all about squeezing maximum performance from a given chip area budget you'd prefer using those transistors for some improvement of the general purpose parts, no matter how marginal. But now it's the thermal envelope, or power consumption of you prefer looking at it from that angle, and even slightly esoteric special purpose units can start making sense.

adrian_b• 8 days ago

Not long ago, China has demonstrated a supercomputer faster than any existing US supercomputer.

The Chinese supercomputer uses custom CPUs designed in China, which implement the SME matrix extension of Armv9.3-A, while the fastest US supercomputers use GPUs.

The Chinese CPUs with SME have a lower energy efficiency than the best NVIDIA datacenter GPUs, and also a little lower than the best AMD datacenter GPUs, but not only they reached a greater absolute performance, but they also reach a much higher percentage of their theoretical maximum throughput, and this is likely to happen for all problems solved on them, because writing efficient programs is easier for CPUs than it is for GPUs.

As discussed in TFA, the Arm SME and the Intel/AMD ACE are similar.

Thus server CPUs that have hundreds of cores and ISAs with matrix extensions can be very competitive in performance with GPUs, even if it is very likely that GPUs will always hold the records for the best energy efficiency.

The Chinese CPUs have fast HBM memory, with an 8 TB/s memory bandwidth per socket, equal to that of the latest AMD Instinct datacenter GPU and much greater than that of most less expensive GPUs. Very few consumer GPUs exceed a 1 TB/s memory bandwidth.

So at least where electric energy is cheap and abundant, running AI inference or training on server CPUs may be a competitive solution, especially when that computing cluster is also used for other purposes, not only for AI.

nicole_express• 8 days ago

Questionable acronym choice; immediately made me think of arbitrary code execution (which, you know, I would hope any processor would be capable of)

rcleveng• 8 days ago

Sounds interesting, I wonder if any of it will be available on consumer hardware. Making CUDA work across the stack seems to be the key thing that helped NVIDIA become the main purveyor of GPUs for AI. Apple seems to be doing well by the same approach.

Last time I looked, anything remotely useful here was only on the Xeon chips, which means there'll be very few open source and even fewer non-corporate folks doing anything interesting with it.

AMD seems to be better at that, maybe there's hope.

Is x86 ready to ACE it?

Related Stories