Tuesday, July 7th 2026
Intel "Nova Lake" to Feature AVX-512 on Both P-cores and E-cores
Intel's next-generation Core Ultra Series 4 "Nova Lake" processors will mark an official return of AVX-512 to the company's client processor lineup. The 512-bit SIMD instruction set will be featured on both the "Coyote Cove" P-cores, and "Arctic Wolf" E-cores, according to Jay Kihn. It is a requirement for both core types to feature an identical ISA, without which thread migration between the two core types will result in runtime errors arising from ISA mismatch.
The last Core processor to feature an official implementation of AVX-512 was 11th Gen Core "Rocket Lake," in which AVX-512 workloads would notoriously cause the 14 nm processor to overheat. Intel would deprecate AVX-512 on all succeeding client microarchitectures, mainly because their respective E-core types didn't support it. Intel is expected to offer a client-relevant set of AVX-512 instructions. Meanwhile, AMD introduced AVX-512 support with "Zen 4," and would go on to improve AVX-512 performance with "Zen 5." The reentry of AVX-512 on Core could advance client AI inferencing applications.
Source:
JayKihn (Twitter)
The last Core processor to feature an official implementation of AVX-512 was 11th Gen Core "Rocket Lake," in which AVX-512 workloads would notoriously cause the 14 nm processor to overheat. Intel would deprecate AVX-512 on all succeeding client microarchitectures, mainly because their respective E-core types didn't support it. Intel is expected to offer a client-relevant set of AVX-512 instructions. Meanwhile, AMD introduced AVX-512 support with "Zen 4," and would go on to improve AVX-512 performance with "Zen 5." The reentry of AVX-512 on Core could advance client AI inferencing applications.

84 Comments on Intel "Nova Lake" to Feature AVX-512 on Both P-cores and E-cores
What I meant was I'm not paying for a Windows license. Because the OS leaves performance on the table, thus I'm getting less value for the money I paid for a CPU, any CPU.
Also, the Ubuntu v3 tests I linked were from last month.
Each user gets what he can afford while aiming at having a comfortable user experience or in other words a satisfactory performance level. Of course this is relative to the prior experience which for most people is on Windows, but Windows itself has changed over the years so sometimes comparisons are not apples to apples, meaning it's not just a CPU change but also an OS change.
There are performance differences between CPUs, as I said all are hamstrung by the OS.
The more overkill a CPU is relative to one's needs the less one feels held back by the OS.
But we're back to affordability, not all can afford flagships.
Even if performance is the same Linux is free, right?
I mean it's literally "you get what you pay for".
Why would I complain in that case?
Gentoo is about choice. Others claim only a benefit of 1-4 % in the past for custom code compiles. I see it differently for my 20 years experience. Less software installed, less CVE holes, less disk usage, stripped down system, same functionality for over 10 years as I3wm.org hardly changed, openrc changed, xorg hardly changed. BTRFS with compression gave me speed improvements which windows can't. Even on old storage with massive disk errors. 20% disk space saved, BTRFS vs ext4 (which behaves closely to ntfs) is also a bonus. I do moved a lot of data in past 20 years from ntfs to ext4 and checked with DF if the disk space usage is similar.
bootup and DRAM usage on windows 11 pro are far worse. windows hardly use all cpu instructions available in the cpu cores.
maybe another project for winter to measure 1 hour internet surfing on www-client vivaldi in w11 pro vs my long term gentoo installation.
The benenfit of the linux kernel diminishes with the kde desktop environment and systemd. see e.g. the gentoo usb live image.
-- i'm curious on the price and motherboard choices which this future intel cpu with hopefully avx512 will provide. Will intel disable AVX512 again? will the power consumption be better as a ryzen 7700 non xt?
For low-level optimization, high sensitivity to L3 is seen as a symptom of software bloat, which is why we see large L3 caches mostly benefit poorly optimized games and workloads. And when something that's mostly "compensation" for shoddy work gets praised as a main feature, it may in the long term lead developers to care even less about getting the user "what they paid for".
And large L3 caches will to some extent make up for bad code, but only to some extent. The primary benefit is to cache hits in instruction cache, due to the code being too bloated, mainly due to abstraction layers. So this will help by reducing the penalty of bloated code, but the code will still never be close to as fast as it should have been. And there are some edge cases where it could make a meaningful difference, in most having a faster CPU overall still wins. It's simply not enough to make a laggy application smooth again.
Let me take an example, take something very basic like Excel. I don't know whether you were a heavy PC user back ~25 years ago, but it used to be snappy, instant, even on a fairly basic system. But now it's buggy, laggy, misinterprets keyboard input etc., even if you run it on a powerful CPU. Having lots of L3 cache might help, but it's only going to help a tiny bit, like the tip of an ice berg, and there are design "flaws" that it wouldn't help at all. If you overclocked the CPU to 7 GHz it would help a lot more, but it still wouldn't make it great.
Unfortunately many reviewers are focusing on exaggerated differences, not whether the difference is meaningful or even a good thing. So when one game shows large gains from a hardware difference and another don't, you can't conclude from that alone that the game with the largest gain is technically better. It requires deep technical knowledge to analyze what's going on, it could be that the other game is so well made that the CPU is not bottlenecked at all.
There are a lot of optimizations that compilers can do, provided that the performance critical paths are reasonably structured. But there are big differences between what compilers like gcc and llvm can do vs. msvc in terms of "free" optimizations, especially when it comes to AVX. Interestingly enough, a lot of what the binary optimization tool from Intel seems to be doing is "patchwork" to compensate from old/wrong compiler use, so this is unleashing performance which should be there. Manually crafting algorithms using AVX intrinstics goes beyond this.
"The exciting takeaway for end-users of FFmpeg is that Haas found RGBA24 1920x1080 to RGBA 1920x1080 conversion was 1.372x faster with this reworked code on AVX-512 processors. This is great news for AMD Zen 4 and newer CPUs or Intel Xeon and other select Intel CPUs supporting AVX-512."