"E-cores" are not the same

The 32 core / die AMD products are almost certainly Zen 6c, which is the same "idea" as Intel E-Cores albeit way less crappy.

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.

▲

eigenspace 2 days ago | parent | next [-]

I was about to reply with an "well, actually..." comment and then I saw that you beat me to it with your edit.

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.

▲

hypercube33 2 days ago | parent | prev | next [-]

I may be wrong, as I'm not an expert but Intel E-Cores are basically decendents of Intel ATOM (I personally really liked the idea of ATOM it was just so nerfed by Intel with its memory limits and platforms) and P cores are derived from the i-Series - two totally different cores. Yes they support the same instruction sets generally, but they are different 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.

▲

bri3d 2 days ago | parent [-]

Yes, you're right and that's what I discuss in the last paragraph of my comment. And, yes, E-cores are rough descendants of some processors that were sometimes called Atom. Using Intel marketing names is fraught with peril, though (see, Celeron) as "Atom" has referred to many conceptually different microarchitectures over time; the modern E-Core is of no relation to the original in-order "Atom" processor many remember.

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.

	▲	kijiki a day ago \| parent [-]
		I've never understood why Intel didn't just soft-disable AVX512 on P-cores until the OS writes a value to some MSR that means "I understand that only some cores have AVX512". 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.

▲

2 days ago | parent | prev | next [-]

[deleted]

▲

eigenform 2 days ago | parent | prev [-]

ie. marketed as "dense" instead of "efficient"

▲

tester756 2 days ago | parent | prev [-]

By what logic?

▲

eigenspace 2 days ago | parent [-]

Intel E-cores are basically a different microarchitecture. They often support different instruction sets than their P-cores, have different "instructions-per-clock" rates (IPC), and all sorts of other major differences. They're just very different things, and those differences are responsible for most of the bad reputation that E-cores have.

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.

▲

zozbot234 2 days ago | parent | next [-]

There's nothing wrong with E-cores though, their bad reputation is quite undeserved. They pack a lot of compute in tiny area and power constraints compared to P-cores. They're probably not the optimal choice for a single-thread workload, but that's an entirely different matter.

▲

eigenspace a day ago | parent | next [-]

Their bad reputation is fully deserved, it's just also out of date. Reputations are almost always about first impressions, and the first impression with E-cores was bad. They've done a lot to fix the situation though, and they do indeed run pretty well nowadays if you have a more modern Intel CPU.

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.

	▲	a day ago \| parent [-]
		[deleted]

▲

saagarjha 2 days ago | parent | prev [-]

Intel is building their new chips on that microarchitecture so it will probably be fine.

▲

tester756 2 days ago | parent | prev [-]

>They often support different instruction sets than their P-cores

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

	▲	wmf 2 days ago \| parent \| next [-]
		The P and E cores support different instructions and Intel "fixed" it by disabling instructions on the P-cores. So now they have the same instructions but at the cost of a bunch of wasted silicon.
	▲	adrian_b 2 days ago \| parent \| prev \| next [-]
		The Intel server CPUs with P-cores support AVX-512, like all current AMD CPUs, and they also support a few extensions not currently supported by AMD, like AMX (Zen 6 will add FP16 arithmetic support in AVX-512, reducing the differences vs. Intel P-core servers). 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.
	▲	eigenspace 2 days ago \| parent \| prev [-]
		> Do they? Yes?