New pc to 10 box but still not good enough?? :O

[mbox_bob]

All true but very misleading. In practice, this is excellent advice for normal users or someone running a single app that spawns tons of threads.

If you show me a computer that is ONLY running a single application with tons of threads, then I'll show you something running on MSDOS4.0 (tons of threads is subjective to the era though).

For the record, on "idle" my computer runs ~100 processes (applications, even if I didn't dbl click an icon to start it) with over 1800 threads. On average I get ~140 processes with ~2800 threads. This is without running any games at all. If I spawn a few game instances, then the numbers increase further.

Setting processor (read: core) affinity limits the available cores that an application's threads can execute on. If those cores happen to be busy servicing some other thing with a higher priority (like sound/network packets/clock ticks etc), or one or more of those cores are Parked then any thread that has been limited to that core (or group) will potentially miss it's quantum (time slice of CPU time), or be delayed while the core is activated. If you set processor affinity on an application then all of that applications threads will be limited to those cores (processor means cores remember - the name processor affinity has not yet caught up with reality).
This is the reason that I recommend you do not set processor affinity.
I find it to be rare, even in an Enterprise installation, to be necessary to set processor affinity (although funnily enough with certain virtual setups it is needed despite it not being so if those same services ran on a shared physical server).

If you were experiencing issues that required you to set processor affinity to resolve (that are not because the game is old enough to have not been compiled with flags to set multi-core aware, or is has race conditions under multicore so is flags as Uniprocessor), and thus limit the potential group of cores that a specific game instance could run on, then it is more than likely this was due to cores being Parked or in a sleep state to conserve electricity. Reduced energy usage is one of the design goals of CPU's these days, and the power management policy of client Windows (i.e. non server sku) aggressively enforces this. When a core is Parked, it is removed from the available pool for threads to execute on, until such time as the Power management policy awakens that core again due to high utilization of the active cores.
Yes, this sucks, because it means your multicore processor, may not be actively using all it's available cores, because the power management policy is shutting several of them down. The Windows scheduler does not awaken Parked cores, it will only schedule threads to run on already active cores, so any Parked cores are reducing your potential computation power (and your electricity bill by a piddling few cents per day). The power management policy in turn requires a sustained spike in demand of resources (i.e. use of the active cores) before it will begrudgingly re-activate a Parked core, and then it will aggressively aim to Park it again at the earliest opportunity. This is obviously a counter strategy to the desire of having your multicore processor available to handle a spike in demand as soon as it occurs, and with all available cores.

You can see if you have cores parking in the Windows Resource Manager. It shows cores in a Parked status. You might also notice the clockspeed changing too, which it is want to do depending on the selected power profile.

In order to combat the core Parking, you can ensure Windows is set to a High Power profile, and in your BIOS/UEFI, make sure that the C6 CPU sleep state is disabled. You may also benefit from disabling the C1E, C3 and C State Support.
If you don't want to change the BIOS/UEFI, you may be able to do this via the powercfg utility too as outlined on this site. The registry entry that is mentioned near the end of the post also works well and makes this item available in the Power profile settings. ***I am not affiliated, nor have I verified the utility offered there; I have used the registry entry to make the setting available in the Power profile and that works just fine.

All that said, if you have set affinity, and this in turn forced activity on cores that would normally have Parked or moved to a sleep state, then fair enough, it is what works for you, and is a valid strategy, but it is essentially a workaround to an issue that can be resolved by setting the correct power management policy.
I believe my recommendation still stands over and above any fixed decision you make up front, and if you removed the competing priorities of the OS, by disabling the core Parking feature you'd have a far better computing experience overall without needing to mess around and find the optimal core allocation strategy.


*Note: If using a laptop, then disabling the Cx Sleep States will reduce battery runtime.




edit: Made a couple of minor clarifications after going back and refreshing my memory on the Thread scheduling and Core Parking strategies in Windows (i.e. re-read the appropriate parts of Windows Internals).