Intel Core i5-12600

[bug]

MT is important though, so why does it matter how they make it better. E cores will make sense when the scheduler works properly, I won't disable mine as they have no detrimental effect on my PC

Except that, with a less than perfect scheduler, they do. Start to compile something that takes a long time, bring your YouTube browser window to the foreground to watch something while compiling and watch your compiler being relegated to the E cores.
E cores can be helpful, but in order to do that, you have to keep your eyes on the scheduler more often than not. Whether that's worth it, only you can say. And it will vary from one person to another. Luckily, save for the 8P/0E cores, you have a selection of CPUs including pretty much everything, so it's all good (if a bit confusing for the less informed buyer - but then again, when hasn't that been a problem?).

 

[Deleted member 24505]

Except that, with a less than perfect scheduler, they do. Start to compile something that takes a long time, bring your YouTube browser window to the foreground to watch something while compiling and watch your compiler being relegated to the E cores.
E cores can be helpful, but in order to do that, you have to keep your eyes on the scheduler more often than not. Whether that's worth it, only you can say. And it will vary from one person to another. Luckily, save for the 8P/0E cores, you have a selection of CPUs including pretty much everything, so it's all good (if a bit confusing for the less informed buyer - but then again, when hasn't that been a problem?).

I did say when the scheduler works properly.

So if i go into the bios and disable the E cores. My MT performance will go down but what would the advantage be?

 

[Wirko]

For the record, E cores make sense when you look at perf/die area, but we need the scheduler to be smart enough to send light loads to them properly. What we're seeing right now in Win11 (send a window to the background, watch it becoming a low-priority task) seems to be quite far from that. And I'm not very confident a scheduler can be smart enough to figure things out properly, unless programs themselves start providing hints.

Fully agreed. But how to handle those light loads? One example that hasn't been researched enough: when you have all P cores running one thread each, and you need to run another 1 or 2 threads (or more), do you gain more performance if you put them on the P cores, or the E cores? I expect the latter to be the case but we need more testing with various types of CPU load.
Also, the scheduler will improve, I have no doubt. Little by little. Intel needs a kiloton of telemetry data first, only then can they improve such a complex program (no, no sarcasm here).

 

[bug]

I did say when the scheduler works properly.

So if i go into the bios and disable the E cores. My MT performance will go down but what would the advantage be?

Your MT performance goes down only if you routinely saturate all P cores. The advantage is that, when you don't saturate all P cores (i.e. most of the time), you don't run the risk of a CPU intensive task being banished to an E core.
Plus, without E cores, you can safely run Win10

Fully agreed. But how to handle those light loads? One example that hasn't been researched enough: when you have all P cores running one thread each, and you need to run another 1 or 2 threads (or more), do you gain more performance if you put them on the P cores, or the E cores? I expect the latter to be the case but we need more testing with various types of CPU load.
Also, the scheduler will improve, I have no doubt. Little by little. Intel needs a kiloton of telemetry data first, only then can they improve such a complex program (no, no sarcasm here).

Exactly, that hard to describe on paper, much less implement in silicon.
If your threads aren't very memory intensive, the best scenario may be running everything on a single core. If they are memory intensive, you want them spread out. Waking up an E core for a single thread may or may not be worth it, from a power point of view.

So yeah, until I learn Intel has made headroom in this area, I'd rather stick with a classic configuration.

 

[Selaya]

For the record, E cores make sense when you look at perf/die area, but we need the scheduler to be smart enough to send light loads to them properly. What we're seeing right now in Win11 (send a window to the background, watch it becoming a low-priority task) seems to be quite far from that. And I'm not very confident a scheduler can be smart enough to figure things out properly, unless programs themselves start providing hints.

the way the E-cores are working rn (MT pad) honestly what we need is a dumber not smarter schedule
since their point seems to be padding MT performance, they should be kept idle until all P-cores are at (almost) full load and then and only then should they be activated, for extra MT performance headroom

 

[Deleted member 24505]

I bet that's not how BIG.little works on phones, no one complains about that. I just ignore them, if they work right, fine, if not dgaf as it does not impact me at all. still a fast CPU with or without the E cores active.

 

[bug]

the way the E-cores are working rn (MT pad) honestly what we need is a dumber not smarter schedule
since their point seems to be padding MT performance, they should be kept idle until all P-cores are at (almost) full load and then and only then should they be activated, for extra MT performance headroom

That would make sense. But I'm afraid they'll just try to put light workloads on E cores, trying to gain some advantage on mobile. And that will mess with the desktop scheduler as well.

I bet that's not how BIG.little works on phones, no one complains about that. I just ignore them, if they work right, fine, if not dgaf as it does not impact me at all. still a fast CPU with or without the E cores active.

Sticking your head in the sand can make you feel better, but it still doesn't mean "it does not impact me at all".

 

[Deleted member 24505]

That would make sense. But I'm afraid they'll just try to put light workloads on E cores, trying to gain some advantage on mobile. And that will mess with the desktop scheduler as well.

Sticking your head in the sand can make you feel better, but it still doesn't mean "it does not impact me at all".

How does it impact me? my PC seemingly runs fine, no apparent lag. If i had something to whine about, i would, but i haven't. Whatever is going on in the background is not having no effect on my PC that i can discern. What should i be seeing if it is going tits up?

I don't get what i am supposed to be seeing. Are others having problems with the E cores or the scheduler? As far as i can see, i am not. I am very happy with the way my PC runs.

Btw-I just ignore them, the E cores, not any problems there might be.

 

[bug]

How does it impact me? my PC seemingly runs fine, no apparent lag. If i had something to whine about, i would, but i haven't. Whatever is going on in the background is not having no effect on my PC that i can discern. What should i be seeing if it is going tits up?

I have already answered that a few posts above.

 

[Deleted member 24505]

I have already answered that a few posts above.

Ok i will start panicking then that i bought the wrong setup and should have bought AMD as the dreaded E cores are a waste of silicon and should not exist, or maybe i can just disable them in the bios and pretend they are not there.

I guess yours are disabled as you seem to have such a problem with them.

 

[Valantar]

For the record, E cores make sense when you look at perf/die area, but we need the scheduler to be smart enough to send light loads to them properly. What we're seeing right now in Win11 (send a window to the background, watch it becoming a low-priority task) seems to be quite far from that. And I'm not very confident a scheduler can be smart enough to figure things out properly, unless programs themselves start providing hints.

This really shouldn't be a problem at all, and MS are making good headway getting there - they just haven't quite arrived yet. The scheduler putting out-of-focus high performance threads onto the E cores frankly ought to be easily solved - they can just check if the workload is sufficiently demanding and if it is, leave it be (barring other more pressing tasks needing that core). This also seems to be relatively application specific, which might speak to some complexity in how that workload is limited and how that makes the scheduler treat it. Still, a more dynamic scheduler will always make performance a tad less predictable, but it also lets the system allocate resources more dynamically, which is a huge benefit.

As for the need for the programs themselves giving hints: they can to a certain degree (threads can be set as higher/lower priority etc.), but that's also what Thread Director is supposed to do. If TD worked as advertised, no compute-bound task would ever get set as "background" and allocated to E cores only, but apparently it still struggles with some applications. Still, all the necessary parts are already there.

Fully agreed. But how to handle those light loads? One example that hasn't been researched enough: when you have all P cores running one thread each, and you need to run another 1 or 2 threads (or more), do you gain more performance if you put them on the P cores, or the E cores? I expect the latter to be the case but we need more testing with various types of CPU load.
Also, the scheduler will improve, I have no doubt. Little by little. Intel needs a kiloton of telemetry data first, only then can they improve such a complex program (no, no sarcasm here).

An E core will drastically outperform SMT on a P core. Intel's SMT increases performance over a single thread by ~25%. In SPEC, the E cores deliver 65% (SPECint) and 55% (SPECfp) of the performance of a P core. SPEC is of course not universally representative, but it gives a good ballpark estimate - and 55% is quite a lot more than 25%.

 

[bug]

Ok i will start panicking then that i bought the wrong setup and should have bought AMD as the dreaded E cores are a waste of silicon and should not exist, or maybe i can just disable them in the bios and pretend they are not there.

I guess yours are disabled as you seem to have such a problem with them.

Sure, knee-jerk reactions always work when the brain gets too strained.

 

[ThrashZone]

Hi,
Cooling tends to vary
If good enough cooling is used doubt you'd notice any issues with e cores being used or not.

 

[InVasMani]

For the record, E cores make sense when you look at perf/die area, but we need the scheduler to be smart enough to send light loads to them properly. What we're seeing right now in Win11 (send a window to the background, watch it becoming a low-priority task) seems to be quite far from that. And I'm not very confident a scheduler can be smart enough to figure things out properly, unless programs themselves start providing hints.

The OS should just treat each chiplet as foreground/background assignment if possible and allow the end user to swap them to desired usage based on if you desire the P cores or E cores to be the foreground chiplets. It might not be possible with the way designed though I'm not certain. I would imagine AMD could do their own take on it that would work that way and Intel could follow up with something like that for it's successor or the one after depending on how far along it is.

 

[bug]

This really shouldn't be a problem at all, and MS are making good headway getting there - they just haven't quite arrived yet. The scheduler putting out-of-focus high performance threads onto the E cores frankly ought to be easily solved - they can just check if the workload is sufficiently demanding and if it is, leave it be (barring other more pressing tasks needing that core). This also seems to be relatively application specific, which might speak to some complexity in how that workload is limited and how that makes the scheduler treat it. Still, a more dynamic scheduler will always make performance a tad less predictable, but it also lets the system allocate resources more dynamically, which is a huge benefit.

As for the need for the programs themselves giving hints: they can to a certain degree (threads can be set as higher/lower priority etc.), but that's also what Thread Director is supposed to do. If TD worked as advertised, no compute-bound task would ever get set as "background" and allocated to E cores only, but apparently it still struggles with some applications. Still, all the necessary parts are already there.

I agree with all that. I'm just not sure whether Windows can tell the difference between a shell running a CPU-intensive compile or transcode task and a shell running a low-priority rsync or smth. If it can, we're golden.

 

[Valantar]

The OS should just treat each chiplet as foreground/background assignment if possible and allow the end user to swap them to desired usage based on if you desire the P cores or E cores to be the foreground chiplets. It might not be possible with the way designed though I'm not certain. I would imagine AMD could do their own take on it that would work that way and Intel could follow up with something like that for it's successor or the one after depending on how far along it is.

Chiplet? Intel's CPUs are (so far) monolithic. Also, that is precisely the behaviour that @bug was complaining about above: if they're fixed to foreground/background and you want to do something lightweight while a heavy task is running, that heavy task gets shifted to the E cores, tanking performance. That's hardly ideal, right? And while having the option for user intervention is good, this really ought to be automatic. Manual thread management is really not something you want to be doing on a regular basis - it would be a major hassle, wildly inflexible, and could cause all kinds of issues. Heck, PCs are supposed to be kind of smart, no? Having to direct their operations manually is kind of antithetical to that.

I agree with all that. I'm just not sure whether Windows can tell the difference between a shell running a CPU-intensive compile or transcode task and a shell running a low-priority rsync or smth. If it can, we're golden.

Yeah, those systems clearly need some tuning. Not that I have a single clue about how schedulers are programmed, but IMO there ought to be several conditions that keep a thread in P cores no matter what, but controls also need to be granular - wholesale shifting of all threads for an application to the E cores, for example, sounds rather excessive unless that app is creating no load at all.

 

[W1zzard]

I agree with all that. I'm just not sure whether Windows can tell the difference between a shell running a CPU-intensive compile or transcode task and a shell running a low-priority rsync or smth. If it can, we're golden.

Intel in their briefings made it sound like the CPU is able to tell that difference. Technically the shell isn't even involved in that, because it just spawns another process.

Compile and transcode are fundamentally different though. Compile spawns a gazillion of ultra-short lived processes (one per file compiled), while transcode is a single long-running process that properly puts the core(s) at 100%

 

[tussinman]

Wait, so this chip is only 4% ahead of the 5600x? So does that mean that the P-cores only have a very small IPC uplift when compared to Zen3?

Hard to say because IPC doesn't necessarly transition to benchmarks and real world performance. 12600 for example is supposedly 20% higher IPC then 11th gen yet the 11600k is within 5% of both the 5600x and 12600 non-k both in the overall CPU test and 1080p/1440p gaming.

 

[Valantar]

Hard to say because IPC doesn't necessarly transition to benchmarks and real world performance. 12600 for example is supposedly 20% higher IPC then 11th gen yet the 11600k is within 5% of both the 5600x and 12600 non-k both in the overall CPU test and 1080p/1440p gaming.

You can't really bring IPC measurements alone into a gaming benchmark, simply because it's also dependent on the GPU, interconnects, etc. IPC is also task dependent (and typically averaged across some broad test suite to account for this), and gaming tends to be rather different than most CPU only loads. So while IPC differences are really useful in understanding the difference between various architectures, they're hardly the be-all, end-all of real world performance.

 

[tussinman]

You can't really bring IPC measurements alone into a gaming benchmark, simply because it's also dependent on the GPU, interconnects, etc. IPC is also task dependent (and typically averaged across some broad test suite to account for this), and gaming tends to be rather different than most CPU only loads. So while IPC differences are really useful in understanding the difference between various architectures, they're hardly the be-all, end-all of real world performance.

Exactly. Gaming and non-gaming cpu test (overall) will differ little sometimes between gens since it's so task dependent

 

[Deleted member 24505]

Sure, knee-jerk reactions always work when the brain gets too strained.

Maybe i should have put /s (sarcasm which i guess you never got)

 

[Why_Me]

Another year another Intel Gimmick!

Gear Modes?

E-Cores?

***EyeRoll***

Obviously you don't read benchmarks.

 

[bug]

Intel in their briefings made it sound like the CPU is able to tell that difference. Technically the shell isn't even involved in that, because it just spawns another process.

Compile and transcode are fundamentally different though. Compile spawns a gazillion of ultra-short lived processes (one per file compiled), while transcode is a single long-running process that properly puts the core(s) at 100%

They may have said that, but in your testing, the scheduler still messed up dispatching wPrime. And that's a simple scenario, like you point out, it can get way more complicated.

 

[Taraquin]

I think 5600X is a better deal, with pbo+co and better ram oc (3800+ vs 3400-3700 gear 1) you get about identical performance at a lower price due to high price of B660. 12400F and 12600KF is also better deals.

 

[bug]

I think 5600X is a better deal, with pbo+co and better ram oc (3800+ vs 3400-3700 gear 1) you get about identical performance at a lower price due to high price of B660. 12400F and 12600KF is also better deals.

It's not that easy to compare. To overclock 5600X properly (even if it's overclocking itself), cheaper boards may not be enough (crappy VRM and everything). But yes, when the CPU price and performance are so close together, I'd make the choice based on where I can find the cheaper motherboard that meets my requirements.