But for the new Alder Lake cpu, which has P/E Performance/Efficiency cores, the efficiency cores don't have AVX-512, so code would have to find a way to switch modes it runs in as it is shuffled between cores. So generally, AVX-512 is regarded as not-actually-available on Alder Lake.
It's even worse than that. Initially you could disable E-cores in BIOS to get the system to report AVX-512 being available, but Intel released a microcode update to remove this workaround[0]. Intel also stated that they started fusing off the AVX-512 in silicon on later production Alder Lake chips[1]. Also compare the Ark entries for the Rocket Lake[2], Alder Lake[3], and Raptor Lake[4] flagships. Only the 11900k lists AVX-512 as an available Instruction Set Extension. So it's reasonable to say that AVX-512 on consumer Intel lines is dead for now, whereas AMD has just introduced it in the Ryzen 7000 series.
[0] https://www.tomshardware.com/news/intel-reportedly-kills-avx...
[1] https://www.intel.com/content/www/us/en/support/articles/000...
[2] https://ark.intel.com/content/www/us/en/ark/products/212325/...
[3] https://ark.intel.com/content/www/us/en/ark/products/134599/...
[4] https://ark.intel.com/content/www/us/en/ark/products/230496/...
The immediate problem is that CPUID is not deterministic for naive software, if you don't set affinity-masks you don't know whether you will be scheduled onto p-cores or e-cores, and so the result you get will vary.
More generally, software doesn't know what configurations of threads to launch... you want to launch as many AVX-512 threads as you have logical cores, but not more, because they won't run on e-cores.
Software could potentially run a cpuid instruction affine to each logical core though, and collate the results... all you need know is "16 logical cores with AVX-512 and 4 without".
And software that isn't AVX-512 aware doesn't need to worry about it at all, since it doesn't know AVX-512 instructions. I guess the long tail of support is the stuff written for Skylake-SP in the meantime, but how much adoption really is there? It's that narrow gap between "regular stuff that never adopted AVX-512 because it wasn't on consumer platform" and "stuff that isn't HPC enough to be really custom" but also "stuff that won't receive an update". How much software can that really describe, especially with the reaction against Skylake-SP's clockdowns in mixed AVX-512+non-AVX workloads?
And also, that software can just launch AVX-512 threads and if they end up on the e-cores you trap the instruction and affine them to the p-cores. Linux already has support for this because Linux doesn't save AVX registers if there have never been AVX instructions used, so, it just would become another type of interrupt for that first AVX-512 instruction. Linus has commented that this is perfectly feasible and he's puzzled why they're not doing it too.
Nobody knows what the fuck is going on and there has been no plan expressed to anyone outside the company as to what the exact problem is and whether they're looking at anything to fix it going forward. It's a complete mystery, nobody even knows if it's something critical or everything is just too on-fire to care about that right now.
(and if it wasn't on fire before, it probably is now, nobody you want to retain is hanging around after a 20% pay cut off the top and truly insulting retention bonuses... ranging as high as $200 for a senior principal (no, that is not missing a "K"). Oh and we paid $4b in dividends, and you need to move to Ohio if you want to keep your job, yes the ohio with the cancer cloud. Intel is fucked.)
You can schedule among heterogeneous cores, that's not really a problem. You simply have another bit for "task used AVX512" and let the task run without AVX512 so it faults the first time it tries to use it. The same stuff is done (or used to be done) for AVX, because if you know a task doesn't use AVX, you don't need to preserve all those registers.
The issue is that eventually someone will find that memcpy* is 4.79 % faster on average with AVX-512 and will put that into glibc and approximately five minutes later all processes end up hitting AVX-512 instructions and zero processes can be scheduled on the E cores, making them completely pointless.
* It doesn't have to be memcpy or glibc, it's sufficient if some reasonably commonly used library ends up adopting AVX-512 when available.
So because AVX-512 is fast, but E cores are slow, we should keep everything slow and prevent adoption of fast AVX-512 to prevent those E cores becoming pointless?
It would be highly desirable for e-cores to implement microcoded AVX-512 support to break the heterogeneous-ISA problem, if nothing else. You don't need to use the same implementation but if you can support the same ISA via microcode then software doesn't need to worry about heterogeneous ISA. Maybe crestmont does the microcode thing, possibly, but in the die shots there aren't many visible changes in the vector unit vs gracemont design.
The next p-core will continue to have AVX-512 but it will continue to be fused off.
This obviously is completely insane, like, even if you validated Raptor Cove already and you can't just take AVX-512 out, you're just going to keep including it in all your future designs too? It's not an insignificant amount of area, even on consumer it's probably at least 10% extra area just to even support a 256b vector/microcode, and it just looks crazy to introduce and then abandon it at the exact moment your competitor adopts and supports it.
Only thing I can think of is that maybe they have some other instructions which utilize microcode intrinsics implemented on the AVX-512 engines... like how Turing implements its Rapid Packed Math (dual-rate FP16) support using the tensor engines. Something else in the design that locks them into AVX-512 even if it is not externally exposed?
But again, they don't even support it even if you turn off the e-cores entirely... why the fuck would you do that? It's like the most confusing resolution to this problem and satisfies nobody, probably not even Intel. I guess they flatly do not want to touch it at all for some reason.
Note that this also includes mobile going forward since mobile will have big.LITTLE designs too... it's a serious amount of work and years of rollout they're pissing down the drain here.
https://news.ycombinator.com/item?id=34494484
So sure, let's do Bulldozer, a bunch of weaker but space-efficient threads (you know, e-cores) but put four threads on a single module sharing an AVX-512 unit, but let's also make it SMT so they can steal unoccupied execution units from other threads in their module. We could call it... Xeon Phi. ;)
https://en.wikipedia.org/wiki/Xeon_Phi#Knights_Landing
And sure maybe Bulldozer was "ahead of its time" but I think that probably undersells just how weak they are especially when threads in a module start contending for shared resources. Both Bulldozer and Xeon Phi get incredibly weak when multiple threads are on a module, the higher threadcount is offset by a reduction in IPC too. And while that is still probably a net perf-per-area gain, your application really has to like threads for it to be worth it.
I'm gonna say it: if you think Bulldozer was "ahead of its time" then so was Larrabee and Xeon Phi. Bulldozer was a first stab at this Xeon Phi idea for AMD. And in both cases I'm not 100% sure it was worth it. The market doesn't seem to have thought so.
Now again: the devil is kinda in the details. It all depends what is shared. If you can make it so the performance hit is really small except for the shared FPU, that's one thing - there's nothing inherently wrong with this idea, that's what the Sun Niagara series does too. But Sun Niagara is also noted for comparatively weak FP performance (it's an integer-monster for database work). It all depends on just how much duplication per-thread and how much shared resource and how much area benefit it gets you.
But like, take a Niagara core, and let's say we have a couple threads with an opportunity for a bunch of ILP and a bunch of unused execution units sitting there. Why should you not launch onto them? That's the CMT vs SMT question to me. And it's fine if the answer is "scheduling complexity" but you need to think about that question before just blindly pinning resources to specific threads.
And again none of this is to dump on e-cores specifically. Intel's P-cores are too big, they are like triple the transistor count of AMD for a smidge more performance. I think the long-term future lies in the e-cores for Intel, they will replace Coves with Monts eventually. Sierra Forest is the most interesting Intel product in a long time imo. AMD is in less need of e-cores, a Zen3 core only has about 2x the transistor count of a Gracemont core and to me that's fine, it's an SMT core with higher per-thread performance too, that's a reasonable sidegrade. AMD's strategy of pursing "compact" cores makes sense to me, they don't need a whole separate e-core, their P-cores are already area-efficient. They just are going to squeeze the last 10-20% out of it for area-optimized applications and call it a day.
(AMD has done a really good job avoiding cruft - supposedly Zen3 was a from-scratch redesign (Zen2 was actually supposedly a tweak, according to AMD's engineering lead), etc. And they've built this modularity of design that lets them embrace semicustom and advanced packaging and make innovative products and not just architectures. It really feels like Intel has been coasting on the Sandy Bridge design for a long time now, not even the kinds of Zen2->3 shifts, just incremental tweaks. Their iGPU stuff is evidently just as tightly tied to the CPU side as the CPU stuff is to their nodes, everything at Intel is obviously just one giant ball of mud at this point and it's incremental changes and legacy cruft all the way down. I am very down on Intel lately because even completely ignoring the current set of products and their merits, AMD is executing well and Intel is simply not. They've had 6 years since the Ryzen launch to turn things around and they still can't do the job right. AMD is obviously the better company right now in the Warren Buffett "own stocks that you'd want to buy the product" sense.)
https://www.youtube.com/watch?v=3vyNzgOP5yw
But I'm just not sure the Xeon Phi/Bulldozer/Niagara concept has really worked all that well in practice.
Anyway it's also possible that instead of sharing one unit among four cores, they put a unit in each core but it executes over multiple cycles, like AMD did with Zen1/Zen+ and 256b vectors. Or you have two 256b units that fuse to become a 512b unit. That seems to have been the design trend recently, that's how AMD does their AVX-512 on Zen4.
But those kinds of changes are what I mean when I say "if there were changes in the vector units it would probably show up on the die shots". Crestmont die shots seem to show a pretty unchanged AVX unit from Gracemont - it seems unlikely they changed it too significantly.
https://www.semianalysis.com/p/meteor-lake-die-shot-and-arch...
Happy 1 year-since-reveal to Sierra Forest's, announced February 17th 2022 at the Intel Investors Meeting. Definitely have a deep love of the "communication processor" grade gear, many-thread cloud systems, & this really can set the tone on what to expect from new Intel & massively-many-core systems. Wikipedia says it's Gracemont and Intel 4 (Intel 4 being due really soon, Gracemont from 2021), and Intel's recently said SF ought ship in 2024; I hope the plans for this chip have some room to evolve, or that we see more follow-up parts in good time. As you say, P-cores are just too damned big; Intel's been iterating on one big-core design for too long & it's gotten too big. Figuring out what we can do with smaller-core is much closer to the sweet spot for nearly all cloud louds: lots of processes of all sorts running; seems like turf for SMT (and you're 99.98% likely to be right about CMT but who knows, especially if we have a limited number of very big vector executors).
Two random mentions. I did really like Lakefield, which tried to be a ultraportable capable 1P 4E alike system, extremely well integrated. Also, I was incredibly fascinated by the semianalysis post mentioning a rumors, that the Intel Meteor Lake SOC die might have it's own integrated E-core island? That seems insanely bright; just turn off the core complex, a lot. Extremely smart for consumer computers. I think that task of actually understanding when real P-cores really should be brought up is an interest challenge facing consumer computing today; a place where Lakefield probably had good hardware but not enough software tuning to make the power-efficiency trade-offs that would have let it truly shine as exceptional.
Ok, so meanwhile AMD is going to be trying Zen 4c (starting with Bergamo, due about now-ish), with SMT2 (alike Zen4) & a huge number of somewhat cut down Zen cores (less cachesd, power, clocks). AVX512 is supposedly still included, but at an even more reduced rate than Zen4's reduced rate; awesome, sounds great. Not as relevant to the discussion so far, but just gonna mention: rumor-mill this week is that Genoa, the large Zen4 epyc chips, which were expected real-soon-now, are alleged to be facing some significant delays.
I'd love to see some SMT3/SMT4 show up again. Calling out Knights Landing as an SMT4 chip with a big vector unit is extremely on target, extremely interesting. That question of how bad the scheduling complexity really is is a compelling question, one that is much less visible than many of the knobs & dials that core design more visually alters (cache sizes & bus widths often being measurable via a random die shot at a trade show, for example). I suspect it probably is not really that huge a barrier. Still, we seem lament to explore much beyond SMT2, for the time being, but maybe that's fine.
Thanks again for the very fun posts paulmd. You have a ton of other delightful chip-design scuttlebutt in comments elsewhere too; this is a treasure to read.
PaulGPT aims to deliver. Not actually an AI, just frequently accused of being one because I read some shit and it triggers Opinions and Tangents. And I don’t stake any position lightly, I have More Opinions why I’m right lol. It leads to Controversy. But I’m perfectly willing to defend my opinions against counterarguments and ultimately I’d rather mald and then admit I’m wrong.
> Definitely have a deep love of the "communication processor" grade gear,
I really wish Denverton had been more available. I can't even bite on surplus enterprise gear because there's barely any out there. Same with xeon-D, sick on paper but way too expensive. Plz make the intel accelerator thingy just onboard everything and also useful for zfs checksumming, that would be a gamechanger for ZFS on NVMe :\
> I did really like Lakefield, which tried to be a ultraportable capable 1P 4E alike system
Yes as I have commented, I really have been a fan of Kabini (Athlon 5350), Airmont (N2808), and Goldmont Plus (J5005) and recently I landed a pair of Skylake NUC7i7 for $125 a pop as well. They still are compelling for certain "microserver" applications given their extreme low price - a $50 CPU+mobo or a $125 booksize changes the expectations. 10 years ago it was $50 for a 5350 and mobo, 8 years ago it was $125 for a 2GB/32GB ECS Liva X, 3 years ago it was $125 for a J5005 NUC, recently $125 for a barebones with thunderbolt support? Yes, I like cheap machines even if their power is limited, $150 for a barebones machine that offers a faster capability at low TDP or some other unique capability is fine with me.
I am looking to use a RPi4 for a local NTP stratum-1 server with GPS and maybe use some of the nucs or other minipcs for freeIPA or a wireguard bastion or similar. With sufficient RAM a J5005 NUC actually made a really nice thin client during COVID WFH - swapping completely tanks performance and 16GB+ makes it perfectly fine even with lots of tabs/etc.
I have my eye on the Atlas Canyon NUCs too, which are finally available in quantity. The only things I don't like are the reduction to single-channel (Which seriously impacts performance vs the expected scaling, especially in iGPU) and the continued lack of Thunderbolt/USB4 - I like that it finally has M.2 NVMe and some other niceties but it really needs USB4 so you can plug it into more powerful stuff if desired. External expansion is going to be very baseline once USB4 reaches saturation and it’s not going to be that many years.
> rumors, that the Intel Meteor Lake SOC die might have it's own integrated E-core island? That seems insanely bright; just turn off the core complex,
Yeah that would be a cool workaround to the data-movement power penalties of chiplets/tiles. I mentioned elsewhere but having to have IF links powered up just to have cores idling along is an obviously dumb thing and yeah that’s a good solution for it, turn off the IF links and just run shit on the IO die.
Data movement and general idle-power is obviously the penalty of MCM and the more data you move across the more (smaller) chiplets the higher it is. It’s all just some new asymptotic limit of scalability (which direct bonding like cu-cu will change again, at the cost of thermals).
Intel claims EMIB is less than an interposer… I’m not really clear how the fiberglass-style interposer vs silicon interposer vs EMIB all stack up in practice. EMIB is 900% crucial to Intel’s future though, remember that TSMC offers advanced packaging solutions and (just like sapphire rapids getting their shit together so Intel has a viable cell library+process to sell to custom foundry) getting their shit together on EMIB is going to be a mandatory requirement for custom foundry’s success. The idea that a couple major intel chiplet/tile based products are seeing a lot of delays is generally concerning.
> I think that task of actually understanding when real P-cores really should be brought up is an interest challenge facing consumer computing today
I think phones have pretty good solutions for this but consumer and server both may have a different optimum for poweriness and boostiness. I think an optimum solution probably is not computable for the same reasons most “sufficiently advanced compiler-magic” doesn’t work - you’ll only really know at runtime. Still I am highly in favor of whatever hinting schemes we can come up with - good dev behavior can make a lot of difference.
Apple’s cores are really interesting in this area. Blizzard is extremely fast and small (like 1/3 of a Gracemont core transistors for similar-ish performance? I’ve never seen exact numbers but broadly that’s how it stacks up) and honestly Avalanche is sick, especially for any sort of JVM task. It’s just generally good at JIT, it’s not just x86 it really just crushes JIT compared to other architectures and JVM falls into that too. Cinebench is underselling the perf/w at load (because of less frontend load on x86) and I think the idle power stuff is undersold too. When it’s really on Linux I think the numbers are going to be impressive.
What’s a real easy answer to “when should I run p-cores”? Just have a real fucking fast e-core and if the e-core complex is getting overrun on a prolonged basis, pull out the really big guns.
> Not as relevant to the discussion so far, but just gonna mention: rumor-mill this week is that Genoa, the large Zen4 epyc chips, which were expected real-soon-now, are alleged to be facing some significant delays.
I did not know this, welp. Intel catches a bit of a lucky break. I think their mindshare is damaged though, even if Genoa were 6 months after SPR-SP nobody would really care tbh, intel’s been a lot later and AMD shows signs of better execution these days.
Sapphire Rapids is a good chip though. It’s not “lol throw your AMD shit in the dumpster” tier good, but, the game is back on, it’s good enough Intel can sell it, especially if they continue to be willing to cut deals. They need cash, they’re desperate, and this is obvious even now, if you’re paying more than half list price for intel you’re a complete fucking chump and quarter or less is more typical. Same for the 10-series during pandemic and the 12/13th gen prices, Intel is willing to deal to keep the fabs busy and keep the cash coming.
https://www.youtube.com/watch?v=_2yjjHzifL8
> Calling out Knights Landing as an SMT4 chip with a big vector unit is extremely on target, extremely interesting.
That’s never occurred to me either but the framing of “lol what if bulldozer but with AVX-512” rubbed both those nerves at the same time. No fuck you what if that already exists and everyone hates it!?!? ;)
(And then the transformer model takes over, beep boop paulGPT online, that's an interesting one for the following reasons ;)
> That question of how bad the scheduling complexity really is is a compelling question
Yes I agree, that is the money question. How much area did AMD save by having some fixed portions of the pipeline that don’t have to be scheduled between threads? How much does Sun save on Niagara? Or Intel on Core-SMT2 or Phi-SMT4? This would be an extremely interesting three-way from chips+cheese or similar, how well did all those sets of tradeoffs work and why were respective decisions made for those designs/use-cases? They all made different decisions around their frontend, I should take a peek at agner fog’s microarchitecture on those uarchs sometime.
> I suspect it probably is not really that huge a barrier.
That’s my guess as well. Alternating threads on the frontend may be the worst of it. If you have fixed decode/fetch units per-thread ala HyperThreading (or the option of a split of 5/0, 3/2, 2/3, etc) maybe that’s most of the squeeze. IDK though.
> Still, we seem lament to explore much beyond SMT2, for the time being, but maybe that's fine.
No… there is another ;)
https://en.wikipedia.org/wiki/POWER9
TBH I really really want a TALOS II setup, that is going to be one of those things that I snipe in 10-15 years when they’re cheap, it’s a neat piece of hardware. I have an AMD Quadfather and a KNL pcie coprocessor (we have a discord, folks!) and some other assorted nostalgia-tech too.
https://discord.gg/2qJXMTmE (expiring link to control spam, feel free to ping me on another tech thread later if anyone needs)