n на брой ядра/процесори се утилизират най-добре, ако CPU-интензивното приложение стартира n на брой CPU-intensive нишки или процеси, уреди си комуникацията между тях (с нишките е доста по-лесно и бързо), от друга страна уреди конкурентният достъп до ресурси (locking), за да няма грозни гранични ситуации, които чупят приложението.
В този ред на мисли, ако програмистите не са се сетили да предвидят тези неща, те няма да станат факт каквито и БИОС опции да се бутат, както и да се компилира ядрото, с каквито и флагове да се компилира приложението.
Просто защото за task scheduler-a, атомарната единица се води процесът (от една версия на ядрото нататък, нишката). Не може един процес или нишка едновременно да се изпълнява на повече от един процесор/ядро. Поради тази причина, не може да се утилизират еднакво добре всички ядра/процесори.
Иначе на теория може да се подходи по друг начин, на много малък интервал от време, процесът/нишката насила се preempt-ват, нещо друго чакащо в runqueue се изпълнява на тяхно място, а това същото се изпълнява на друг процесор/ядро. Това на теория вероятно би подобрило responsiveness-а на една десктоп система, няма да става така, че един CPU-интензивен процес да тормози работата на останалите процеси чак толкова. От друга страна, цената на това е огромна - това "превключване" между процеси върху процесора се нарича context switch и включва запазване/възтановяване на състоянието на регистри, операции по копиране на памет, изчистване на едни кешове, въобще разни "скъпи" операции, които от своя страна ще доведат до по-бавното изпълнение на процесите като цяло. В случаят с видеото, това вероятно ще доведе до насичане на звука или картината или нещо от сорта.
Така че нещата са в ръцете на програмистите

'>