Pourquoi la priorisation des processus ne produit-elle pas une amélioration de la vitesse?

J'ai 2 applications qui utilisent toutes deux beaucoup de ressources système. Lorsque je diminue la priorité de l'un dans le Gestionnaire des tâches, tout en augmentant l'autre, je ne remarque aucune amélioration significative de la vitesse dans l'application avec la priorité la plus élevée.

Pourquoi est-ce? Y a-t-il plus de choses en cours ou y a-t-il plus à faire?

La priorité n'aide pas lorsque le goulot d'étranglement est le CPU lui-même. La priorité réelle affecte l’ algorithme de planification que le système d’exploitation utilise pour déterminer quel processus s’exécute ensuite car il n’y a pas assez de processeurs dans la plupart des systèmes pour exécuter chaque processus en continu.

Une tâche de priorité plus élevée se rendra plus rapidement en haut de la file d'attente, donc cela aide à la latence générale, mais si votre processus épuise l'intégralité de la tranche de temps, il est alloué sur le calcul réel, alors la planification ne changera rien. La modification de la priorité est plus utile lorsque vous avez un processus en attente d'E / S et que vous souhaitez qu'il soit plus réactif.

La priorité est le temps CPU. Tous les cœurs sont-ils utilisés à 100% tout le temps? Sinon, la priorité n'aurait aucun effet. Très souvent, le CPU n'est pas le goulot d'étranglement, et c'est la mémoire, le disque ou les ressources GPU.

La priorité n'a d'importance que s'il y a plus de threads exécutables que de cœurs CPU disponibles. Lorsque cela se produit, la priorité contrôle les threads à exécuter. Dans la plupart des systèmes, il n'y a pas assez de calcul pour tout conflit sur le CPU: les threads sont tous bloqués , en attendant que quelque chose se produise. Cela peut vous attendre pour taper quelque chose, déplacer la souris, toucher l'écran ou pour que des données arrivent du disque, du réseau, d'un autre appareil que vous avez branché ou qu'un autre thread finisse de travailler sur des données critiques structure. Il peut être en attente qu'une partie du programme soit lue à partir du disque ou d'une mémoire qui a été échangée pour être relue, plutôt que de lire explicitement un fichier.

Sous Windows, le planificateur conserve une file d' attente de threads exécutables à chaque niveau de priorité. Quand il prend une décision de planification - soit qu'un thread a épuisé son quantum (temps autorisé avant que quelque chose d'autre ne doive s'exécuter), ce qui signifie qu'un autre thread devrait avoir un tour, ou le thread s'est bloqué et n'est plus exécutable, ou une priorité plus élevée le thread est devenu débloqué - le prochain thread dans la file d'attente au niveau de priorité supérieur avec tous les threads exécutables sera planifié. Si le thread en cours d'exécution a utilisé son quantum, il est placé à la fin de la file d'attente. Si c'est le seul thread à son niveau de priorité qui est exécutable, et qu'il n'y a aucun autre thread exécutable de priorité plus élevée, mais qui ne s'exécute pas, il obtiendra un autre tour.

Dans les systèmes multicœurs / multiprocesseurs, il peut y avoir des restrictions sur les cœurs sur lesquels un thread peut s'exécuter. En outre, le système essaie de conserver les threads sur leur noyau idéal et dans leur nœud NUMA afin que les données du thread soient toujours dans le cache de ce noyau et qu'il ait un accès rapide aux données qu'il a créées. Les threads seront toujours exécutés sur des cœurs non idéaux s'il n'y a pas de choix sur quoi exécuter ensuite.

Le système utilise divers boosts de priorité dynamique et tailles quantiques dynamiques afin que l'application de premier plan ait plus de temps (si elle en a besoin) que les processus d'arrière-plan, et que les processus puissent réagir rapidement lorsque les opérations d'E / S sont terminées (y compris la souris, le clavier et écran tactile). De plus, l'augmentation de priorité est utilisée pour contourner les inversions de priorité, où un thread de haute priorité attend une ressource qu'un thread de faible priorité détient actuellement. Si un thread de priorité moyenne est également en cours d'exécution, il affamera le thread de faible priorité du temps du processeur, ce qui maintiendra le thread de haute priorité. Ainsi, le thread à faible priorité est temporairement augmenté à la priorité la plus élevée, ce qui lui donne du temps et, espérons-le, libère la ressource dont le thread à haute priorité a besoin.

Avant Windows Vista, la priorité des threads n'avait aucun effet sur la rapidité d'exécution des opérations d'E / S. Depuis Windows Vista, les E / S peuvent également avoir une priorité, qui provient par défaut de la priorité du thread.

Résumé: vous ne verrez en grande partie aucun effet de la modification des priorités des threads, sauf si votre processeur est lourdement chargé, et même alors, l'effet sera généralement minime. Si le processus doit attendre les E / S ou s'il n'est pas en concurrence avec d'autres processus pour le temps CPU, il s'exécute déjà le plus rapidement possible et le changement de priorité ne va pas le rendre plus rapide.

En général, il faut un effort supplémentaire pour qu'un programme utilise plus d'un CPU (en ajoutant le multi-threading). Ainsi, même si le programme a la priorité la plus élevée disponible, il peut n'utiliser qu'un seul cœur.

Autres problèmes possibles:

• Le programme pourrait être inefficace / mal écrit
• Il pourrait être ralenti en raison d'un accès au disque "lent" ou d'un réseau lent

Même augmenter la priorité d'E / S d'un processus lié aux E / S ne le fera pas nécessairement fonctionner plus rapidement. Par exemple, s'il est un consommateur de données produites par un processus séparé, éventuellement distant, et qu'il suit le rythme auquel cette source produit les données, il ne peut pas aller plus vite ou avoir un débit plus élevé.

Contrairement à ce qui est catégoriquement indiqué dans la première phrase de la réponse actuellement acceptée ( /superuser//a/752587/322588 ), les changements de priorité sont plus efficaces lorsque le CPU est le goulot d'étranglement, comme expliqué dans la réponse de Mike Dimmick ( /superuser//a/752864/322588 ). En outre, la déclaration dans le deuxième paragraphe de la réponse acceptée, "si votre processus épuise l'intégralité de la tranche de temps, il est alloué sur le calcul réel, alors la planification ne changera rien là-bas" est complètement erronée, sauf si le processus a déjà généralement la plus haute priorité de tous. threads exécutables chaque fois qu'il attend d'être exécuté. En effet, dans toutes les autres circonstances, l'augmentation de la priorité est susceptible de lui faire plus de tranches de temps par intervalle d'horloge murale.

Mike Dimmick a souligné les problèmes avec cette réponse il y a quelques jours et a fourni une bien meilleure réponse, mais la première continue inexplicablement à gagner des voix. L'affirmation de son auteur selon laquelle il ne fait que simplifier sa réponse pour nous les nuls n'est pas plausible, car ce n'est pas simplement simple, ni même simpliste, c'est carrément faux, du moins en ce qui concerne les processus liés au processeur.

Avertissement: je ne connais pas M. Dimmick, mais je peux dire qu'il sait de quoi il parle.