E-cores as a concept are fine. The problem is that the current e-core implementations all suck. Alder/Raptor lake awkwardly bolted e-cores onto the existing ring/cache structure and they're 1.5x the latency of any other core in the system, and actually the latency is even higher inside the e-core "CCX"/4-core cluster (possibly implying they might be having to look through the P-core cache hierarchy or something).
https://images.anandtech.com/doci/17601/Core%20i9-13900K%20C...
https://images.anandtech.com/doci/17047/12900K%20Bounce.png
(I haven't seen results, but, I am guessing N100/N300 processors have better latency than this, and this is purely an artifact of alder lake still being kind of a shitty implementation from a bunch of teams that are flailing... it just looks good because the p-cores are good, but the rest of the product is shit.)
(if you have a N100/N300 and could spare a moment, you can answer this question with this tool!) https://github.com/nviennot/core-to-core-latency
Similarly, Apple's e-cores are really intended for background workers in phones, not interactive tasks, and not batch processing an intensive workload.
AMD's e-cores are literally just slightly lower-clocking/lower-cache/4-core-CCX versions of the normal cores, so, there shouldn't be this cliff. Being inside an e-core CCX should be the same as being on a non-big.little processor entirely, other than going back to a multi-CCX model and having a bit lower performance.
Similarly, in the long term, Intel is supposedly looking at something they call "royal cores"/"rentable units" where it's actually (eg) 3x little/1x big core in the same cluster, or some of the units can be paired together to work faster as a single execution stream. So you don't have the latency of flinging a work item all the way to some other stop on the ringbus, because the e-cores are right there and work in the same cache hierarchy/etc.
There is some iceberg-work there in terms of making the scheduling play nicely. But oh look, they've been working towards exactly that with the Intel Thread Director (tm) stuff. Everyone thought it was hideously overwrought for just some basic big.little design... and it is. But when you are scheduling 4 threads onto a core and 1 of them goes fast, the CPU itself will need to make the determination. This will actually vary over time too - sometimes you will have threads on the e-cores while you wait for memory access, etc, but then when they're ready they will burst on the p-cores and churn through their work, and go back to the e-cores.
(in a way you can argue this is the same vision that xeon phi was built for... xeon phi looks like a processor built for a world of intensive AVX-512 work segments, stitched together with highly-threadable low-performance IO segments/other work. Knight's Landing basically Silverton (e-cores) with SMT4 added (to an e-core, yes) and you get 72 of them, and the bulk of your work is happening in the AVX-512 parts stitched together by these scalar SMT4 threads. Well, Royal Cores are the same idea but with regular scalar code - put the hard parts in the p-cores and the easy parts in the e-cores, and run enough work to saturate it.)
But everyone is fishing at this same "p-cores churn through the hot thread and emit bulk work items, e-cores handle the bulk work out of a queue or something" model and that's just not tenable when the e-cores have this massive latency hit/etc. It's not that "e-cores are shit for games" it's that "having half of your processor have twice the latency and exist in a separate cache partition is shit for games"... same reason multi-CCD AMD chips don't do well in games.
https://images.anandtech.com/doci/17601/Core%20i9-13900K%20C...
https://images.anandtech.com/doci/17047/12900K%20Bounce.png
(I haven't seen results, but, I am guessing N100/N300 processors have better latency than this, and this is purely an artifact of alder lake still being kind of a shitty implementation from a bunch of teams that are flailing... it just looks good because the p-cores are good, but the rest of the product is shit.)
(if you have a N100/N300 and could spare a moment, you can answer this question with this tool!) https://github.com/nviennot/core-to-core-latency
Similarly, Apple's e-cores are really intended for background workers in phones, not interactive tasks, and not batch processing an intensive workload.
AMD's e-cores are literally just slightly lower-clocking/lower-cache/4-core-CCX versions of the normal cores, so, there shouldn't be this cliff. Being inside an e-core CCX should be the same as being on a non-big.little processor entirely, other than going back to a multi-CCX model and having a bit lower performance.
Similarly, in the long term, Intel is supposedly looking at something they call "royal cores"/"rentable units" where it's actually (eg) 3x little/1x big core in the same cluster, or some of the units can be paired together to work faster as a single execution stream. So you don't have the latency of flinging a work item all the way to some other stop on the ringbus, because the e-cores are right there and work in the same cache hierarchy/etc.
There is some iceberg-work there in terms of making the scheduling play nicely. But oh look, they've been working towards exactly that with the Intel Thread Director (tm) stuff. Everyone thought it was hideously overwrought for just some basic big.little design... and it is. But when you are scheduling 4 threads onto a core and 1 of them goes fast, the CPU itself will need to make the determination. This will actually vary over time too - sometimes you will have threads on the e-cores while you wait for memory access, etc, but then when they're ready they will burst on the p-cores and churn through their work, and go back to the e-cores.
(in a way you can argue this is the same vision that xeon phi was built for... xeon phi looks like a processor built for a world of intensive AVX-512 work segments, stitched together with highly-threadable low-performance IO segments/other work. Knight's Landing basically Silverton (e-cores) with SMT4 added (to an e-core, yes) and you get 72 of them, and the bulk of your work is happening in the AVX-512 parts stitched together by these scalar SMT4 threads. Well, Royal Cores are the same idea but with regular scalar code - put the hard parts in the p-cores and the easy parts in the e-cores, and run enough work to saturate it.)
But everyone is fishing at this same "p-cores churn through the hot thread and emit bulk work items, e-cores handle the bulk work out of a queue or something" model and that's just not tenable when the e-cores have this massive latency hit/etc. It's not that "e-cores are shit for games" it's that "having half of your processor have twice the latency and exist in a separate cache partition is shit for games"... same reason multi-CCD AMD chips don't do well in games.