| ▲ | hypercube33 2 days ago | |||||||
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. | ||||||||
| ||||||||