256 cores on a die. Stunning.
It's a smaller denser core but still incredibly incredibly promising and so so neat.
iirc, in the 2016 a quadcore intel cpu ran the original crysis at ~15fps
https://www.techpowerup.com/forums/threads/amd-zen-6-epyc-ve...
EDIT: actually, now that I think about it some more, my characterization of Zen-C cores as the same "idea" as Intel E-cores was pretty unfair too; they do serve the same market idea but the implementation is so much less silly that it's a bit daft to compare them. Intel E-Cores have different IPC, different tuning characteristics, and different feature support (ie, they are usually a different uarch) which makes them really annoying to deal with. Zen C cores are usually the same cores with less cache and sometimes fewer or narrower ports depending on the specific configuration.
Fully agreed, they may be targetting a similar goal, but the execution is so different, and a Intel screwed up the idea so bad that it can really mislead people into assuming that dense Zen cores are the same junk as a Intel E-cores.
AMD's approach was to basically trim the fat on Zen as far as they possibly could but keep the core fast and efficient and you end up with the C-Cores.
In practice (where I generally live with expertise) AMD's approach lets you move software between cores and it generally doesn't care or know, whereas Intel's method applications definetly do care and can have issues.
To me, the difference is moving a virtual machine between two similar CPUs and not having to reboot it (AMDs approach) and having to reboot for one reason or another (Compatibility) -- Intels method.
I've had the same experiences as you with Intel mixed-core desktop parts. They're incredibly difficult to optimize for due to the heterogeneous core mixture, whereas AMD mobile parts are generally more reasonable (you're on a slow core or a fast core, basically), and AMD never made a mixed-core desktop part.
However, Intel server parts several years ago switched to E-core only or P-core only, so all of the heterogeneous core mixture issues aren't a thing - you basically have two separate processor generations being sold at once, which isn't particularly surprising or uncommon.
With AMD server processor families (linked in my comment), depending on the part's density you get either "slow" or "fast" cores and either "wide" or "narrow" units, so you do still have to think about things a little bit there too.
Where Intel really screwed up in general, microarchitecture differences aside, is AVX512. That's the wrench that prevents the same compiled code from running across most Intel parts - they just couldn't decide what they wanted to do with it, whereas AMD just chose to support it and stick with it, even though the throughput for the wide instructions is wildly different between processors.
From the OS side, the change to support it is pretty simple. On the first #UD trap caused by an AVX512 instruction being missing, pin the process to just the P-cores and end the process's timeslice.
AMD's dense-cores are the same microarchitecture, have the same IPC, use all the same instruction sets. The only real difference between them and regular AMD cores is that their dense cores have less cache, and lower peak clocks.
Do they?
I thought it caused very significant problems (when there's switch between E and P core) and they avoided it
But I cannot find anything about it
Yes?
The Intel server CPUs with E-cores, both the current Sierra Forest CPUs with Crestmont cores and the future Clearwater Forest CPUs with Darkmont cores do not support AVX-512 and they are almost identical with the E-cores from Intel laptop/desktop CPUs.
Therefore, for demanding applications you cannot run the same programs on Intel servers with P-cores or E-cores, unless they use dynamical dispatch to select at run-time between AVX and AVX-512 libraries, as the gain from AVX-512 can be very substantial and on server applications not using it would lose money by lowering the throughput.
The Intel Darkmont cores of Panther Lake and Clearwater Forest are almost identical with the Skymont cores of Arrow Lake and Lunar Lake (the main difference is that the Skymont cores are made by TSMC, while the Darkmont cores are made by Intel in their new 18A CMOS process) and they are extremely similar in die size and in performance with the ARM Neoverse V3 cores from the newly launched AWS Graviton5 (which are known as Cortex-X4 in their smartphone variant).
Intel has said that they will eliminate this ISA difference between E-cores and P-cores, but a couple of years might pass until this will reach their server CPUs.
That said, manually disabling AVX-512 on P-cores just so I can have E-cores is still a *bad* tradeoff as far as I'm concerned, but I get that my use-cases aren't everyone's use-cases.
I wonder how many of these you could cram into 1U? And what the maximum next gen kW/U figure looks like.
* It just seems like a lot of threads to wrangle without some hierarchy. Nested OpenMP is also possible…
* I’m wondering if explicit communication is better from one die to another in this sort of system.
The above doesn't even consider the possibility of multi-CPU systems. I suspect the existing programming models are quickly going to become insufficient for modeling these systems.
I also find myself wondering how atomic instruction performance will fare on these. GPU ISA and memory model on CPU when?
Before 8 cores per die (introduced in Zen 3, and retained in 4, 5 and 6), the Zen 1/+ and 2 series this would have been two sets of four cores instead of one set of eight (and a split L3 instead of a unified one). I can't remember if the split-CCX had its own NUMA layer in the tree or not, or if they were just iterated in pairs.
I realize that HPC code can be customized to the specific device it will be run on but more widely deployed software is going to want to abstract these increasingly complex relationships.
Ironically, a lot of people keep shooting themselves in the foot and blindly using MPI or OpenMP or any of the other popular industry supported frameworks, and then thinking that magically bails them out. It doesn't.
The most important thing you need, above all others: make sure the problem you're solving can be parallelized, and CPUs are the right way of doing it. Once you've answered this question, and the answer is yes, you can just write it pretty much normally.
Also, ironically, you can write Java that isn't shit and takes advantage of systems like these. Sun and the post-Sun community put a lot of work into the Hotspot JVM to make it scale alarmingly well on high core count machines. Java used correctly is performant.
Even today, I think very large enterprise systems (where a single kernel runs on a single system that spans multiple racks) are built like this, too.
NVidia's use of "cores" is simply wrong. unless you think a core is a simple scalar ALU. but cores haven't been like that for decades.
or would you like to count cores in a current AMD or Intel CPU? each "core" has half a dozen ALUs/FP pipes, and don't forget to multiply by SIMD width.
Here's analysis of a prior LTT video showing 1/3 of cores at 100%, 1/3 of cores at 50%, and 1/3 idle cores:
https://www.youtube.com/watch?v=XqSCRZJl7S0
In any case, CS2 can take advantage of far more cores than most games.
Things like games, desktops, browsers, and such were designed for computers with a handful of cores, but the core count will only go up on these devices - a very pedestrian desktop these days has more than 8 cores.
If you want to make software that’ll run well enough 10 years from now, you’d better start using computers from 10 years from now. A 256 core chip might be just that.
the standard consumer computer of today has only a few cores that race-to-sleep, because there simply isn't that much to do. where do you imagine the parallel work will come from? even for games, will work shift off the GPU onto the host processor? seems unlikely.
future-proofing isn't about inflating your use of threads, but being smart about memory and IO. those have been the bottleneck for decades now.
Because the cores will be there, regardless. At some point, machines will be able to do a lot of background activity, learn about what we are doing, so that local agentic models can act as better intelligent assistants. I don't know what will be the killer app for the kilocore desktop - nobody knows that, but when PARC made a workstation with bit-mapped graphics out of a semi custom built minicomputer that could easily serve a department of text terminals we got things like GUIs, WYSYWIG, Smalltalk, and a lot of other fancy things nobody imagined back then.
You can try to invent the future using current tech, or you might just try to see what's possible with tomorrow's tools and observe it first hand.
They scale very well for web and db servers as well. You just put lots of containers/VMs on a single server.
AMD EPYC has a separate architecture specifically for such workloads. It's a bit weaker, runs at lower frequency and power and takes less silicon area. This way AMD can put more such cores on a single CPU (192 vs 128 for Zen 5c vs 5). So it's the other way round - web servers love high core count CPUs.