Curious as to how an app that has been coded for multi-core use spreads the load? Would it by default allocate the load evenly across cores or will it simply spill over to additional cores as each core becomes saturated? I'm assuming both these scenarios are an option and basically dependent on the coders chosen implementation.
I've got both sorts of programs on my PC.
One of my video rendering programs allocates Core 0 most of the work, while Cores 1, 2 and 3, get just a bit of it.
Another video program spreads the load out evenly to all cores. Same with Folding@Home.
Thanks OvenMaster!
Much appreciate the verification.
Of the multi-core programs I have -- One stresses a single core to 85%-90% while the other three cores dance below 13%. My other multi-core apps unfortunately are always using 100% of all four cores when in use so I had no definitive answer. It's that one-core stresser that bothers me because I occasionally experience performance problems (data lag) with that app and am having difficulty determining if it's CPU related or due to other factors (i.e. data provider, network, etc.).
An application optimized to run on a multicore system is one that has threads designed to run simultaneously. This is difficult to do and even more difficult to do well. Many applications have multiple threads but this is for reasons other than performance and they do not really take advantage of multiple cores.
Thread scheduling with multiple processors (cores) is very complex. It is threads that are scheduled and this is done without regard to the processes they belong to. This is managed by the system with the goal of maximizing overall system performance. There is limited provision for applications to influence scheduling but most simply leave it to the system. This usually works best.
When a thread starts it is assigned an "Ideal processor" which it will be assigned to whenever possible. For some quite technical reasons that I do not fully understand this tends to optimize performance. Of course if that processor is busy when the threads turn comes up it will be assigned another. There are complex rules that govern all this.
The goal is optimum performance. Spreading of the workload among cores is not a priority and is only incidental when it happens.
It is possible to set affinity of a process to one or more cores and this can be useful. This limits the process to using only the selected cores. There is no provision for reserving cores for any purpose. Usually it is best to leave all this to the system.
It is very possible for an application to have performance issues and at the same time have cores that are largely inactive. Usually it is just the application cannot efficiently use more cores then it currently is. The scheduler could spread the work around and this might look better in Task Manager but performance would be worse.
Thanks a bunch for the detailed insight LMiller7!
I almost decided a few months back to upgrade to an i7 6700k. Based on your post and the fact the app in question doesn't seem to ever push the one core past 90% (if my monitoring tools are to be believed) I'd probably not notice any issue alleviation anyhow. Thankfully these hiccups are few and relatively brief as >95% of the time the assigned core is only running at 45%-60%.
Quote