Ok, so "no 32E" was from an ARL ES datasheet. Nothing is known about amount of E cores in the final SKUs then, and it could be 24/32E?
How do we know how sales relate to the presence/amount of E cores? There are many factors affecting sales, e.g. power consumption, price, ST/MT performance, etc. Correlation does not imply causation.
Having E-cores is definitely a bonus. But having way too many E-cores doesn't sound very appealing. Most of them will be idle for the life of the product itself considering there isn't much software to support them.
Many MT heavy workloads can handle more or less as many cores as you have available. If they already make use of 16C then they'll also make use of 48C.
You are correct that not a lot of software can effectively use 40 threads. Eventually Amdahl's law kicks in and you can't do one thing much (if any) faster with more threads. Some software doesn't try to do one thing though (especially a lot of the benchmarking software which arbitrarily create work). Think about almost anything in the distributed computing realm. They don't try to do one thing fast, they try to do many things fast. That type of software is perfect for core spamming. That is not applicable to everyone though as many people don't run those types of software.
Oh sry, I don't know anything about that. The ARL data was mentioned by a twitter which was deleted and author even change his name to avoid trouble. he seemed to post a lot like core config but I forgot that.
forums.anandtech.com
Compare to older generation before Alderlake. E core implementation doesn't change the picture too much when compare to competition.
Check your thread count. I'm at 4450. Context switching is in fact inevitable for the remainder of our life times. Operating systems cannot avoid it even if they have 1024 CPU cores.
I have ~3200 threads right now. But ~3182 of them are idle. They can sit on a single core unused along with other background tasks that do not need to be timely (or rent a core as needed). who cares if Microsoft Service Host: Themes gets delayed by 6 microseconds? Those aren't the issue.
Hmm... not sure how to interpret that. What point is it that you're trying to make?
E cores aren't really useful until you have 8, even better 16+ of them. The fact that many chips with E cores don't have enough makes people think the E core idea is bad (see A/// where he turns them off). Having just 4 E cores on a lot of chips was a terrible design choice. But, look at where they are heading and you'll see a different possibility.
Only 18 active threads? I find that hard to believe. Run ProcessExplorer and tell me what does it say the context switch delta is? Every tick is in the order of 20,000 context switches per second even on my idle 32 thread system. Windows isn't context switching because it's fun, but because it has a lot of threads to schedule. So unless you're proposing a 20P + 20000 E core CPU it'll never get to the point of no context switching. Even in an 18 important thread case the interactive threads should be on the P cores so you still have 18 threads that should be on 8P cores which means context switching.
I don't think I conveyed my message to you. Never did I say each thread gets its own core. I said each active thread that uses any significant amount of CPU time and needs to be run routinely (If you go back and reread, I arbitrarily put the cutoff at regularly >0.3% of my CPU, but that could be a different cutoff). That number is far, far lower than 20000. Yes, there will always be context switching but it could be limited to non-time sensitive tasks on a single core when the penalty doesn't matter and isn't felt (and then you have the rentable cores when a background thread suddenly needs a burst of resources). The threads that matter are usually orders of magnitude fewer. Those threads can have enough dedicated cores to avoid context switching issues.
Yeah I guess the part about
really confused me. Even when divided into P core pool and E core pool both will still be context switching all the time. Windows already tries to keep important threads resident longer & throwing more e cores at it will only decrease the portion of CPU time spent context switching if it also keeps clusters awake.
Actually, the threads work a bit differently. Threads are even-driven. The become active on a event, run for a short burst & idle most of the time. Even threads that iterate tend to go idle waiting for a system event or a state change. If any thread runs continuously, it drives up cpu utilization to 100% for that core.
I edited it to "no more context switching on threads that matter to you". Is that more clear? I thought from that context it would have been clear, but I don't mind editing it more.
None of that addresses what I was saying. Yes, when idle, it doesn't matter. If your computer utilization is low, who cares? Throw everything at a dedicated power efficient tiny core (or tiny cluster of cores) and go with it since your computer is idle. Avoid powering up a power hungry performance core.
No question that it's more MT throughput than needed. Sure rendering, transcoding, and some other tasks will always be able to make use of more cores. But that's getting beyond the 'mainstream' realm which likely wouldn't notice any difference between a 4P+8E configuration and 8P.
Sure. Just thinking out of the box. Let us assume that we pin some preferred threads to some preferred cores. Even then, when the other cores are running full and there are other threads waiting in the queue, the OS will still try to schedule (preempt) some of those other threads to the preferred cores.
I think that is where we differ. When there are plentiful E cores, there would be no need to preempt the preferred cores. We could finally have dedicated cores to our important programs with no* context switching, no preemption, etc. of those important tasks.
"Usually" is not sufficient in my experience. I see all kinds of stutters and delays when background tasks kick in. Maybe it is fine with your tasks. But certainly not for me.
even one you listed transcoding will prefer a smaller number ( ~8-16) of high performance cores then a sea of lower performance cores ( 16+ )
Facebook
Twitter