Comment fonctionnent les priorités sur le gestionnaire de tâches et quand dois-je / ne pas le définir?

J'ai défini la priorité de certains processus afin de voir ce qui se passe réellement, mais devinez quoi ... Rien; tout fonctionne de la même manière ...

J'ai trouvé sur Google que les priorités ne sont pas vraiment liées à la vitesse de traitement, est-ce vrai? Pourquoi pas alors? si un processus a la priorité la plus élevée, ne devrait-il pas aller plus vite ??

Supposons que vous ayez une carte «Aller en tête de file» pour l'épicerie. Vous allez au magasin, remplissez votre panier, allez aux caisses et constatez qu'il n'y a personne en ligne. Votre carte vous aide-t-elle à passer la commande plus rapidement? Nan.

Les priorités n'affectent pas la vitesse de traitement, en ce sens qu'un processus de priorité plus élevée ne s'exécute pas plus rapidement ni même utilise plus de temps CPU ... pas si c'est la seule chose qui veut utiliser le CPU.

Pour vraiment en parler, nous devons mentionner les fils. Les processus ne "s'exécutent" pas sous Windows. Les threads, qui font partie des processus, sont exécutés. (Même si un processus n'a qu'un seul thread, la distinction est assez floue de l'extérieur.)

(Soit dit en passant: la terminologie marketing selon laquelle un processeur a, par exemple, "quatre cœurs et huit threads", est trompeuse. Les processeurs ont des cœurs, mais les processeurs n'ont pas "de" threads. Les threads font partie des processus. Un noyau de CPU sans hyperthreading activé peut exécuter un thread; avec l'hyperthreading activé, un noyau peut exécuter deux threads. Mais les CPU n'ont pas de "threads".)

Chaque thread est toujours dans l'un des états de planification. Les états les plus courants sont les suivants: En attente (* nix appelle cela "bloqué"; dans les deux systèmes d'exploitation, cela signifie attendre les E / S ou similaire, n'utilise pas de temps CPU et n'en veut pas); Prêt (veut utiliser le temps CPU mais aucun CPU n'est disponible pour le moment); et Running . Seuls les threads en cours d'exécution consomment du temps CPU; c'est-à-dire que si un processus n'a pas de threads en cours d'exécution, il sera vu qu'il utilise zéro% de temps CPU dans des outils comme le Gestionnaire des tâches.

Un thread ne peut s'exécuter que sur un cœur (ou, si l'hyperthreading est activé, "processeur logique") à la fois, un processus ne peut donc utiliser que autant de cœurs de processeur (ou LP) qu'il a de threads qui souhaitent s'exécuter en ce moment. . (La même déclaration peut être faite du système dans son ensemble.)

La plupart des threads sur la plupart des systèmes passent la plupart de leur temps à l'état d'attente. (C'est pourquoi votre processus inactif devrait obtenir plus de 95% du temps processeur lorsque votre système ne fait rien.) Les exceptions seraient les threads "de travail" de choses comme la vidéo ou le rendu 3D, les jeux, etc. Très peu de threads pourrait vraiment utiliser 100% du CPU, car ils doivent généralement travailler sur certaines données d'entrée qu'ils doivent lire quelque part, et ils créent généralement des données de sortie qui doivent être écrites quelque part. Et ils peuvent faire référence à de nombreuses données différentes dans la mémoire au fil du temps, ce qui peut signifier qu'ils doivent attendre que les erreurs de page matérielle soient résolues.

Mais les threads faisant quelque chose comme le rendu vidéo ou le rendu d'image 3D pourraient bien passer presque tout leur temps à "calculer" dans le CPU, et très peu d'attente pour les E / S. Ces threads sont souvent appelés "liés au calcul", ce qui signifie que leurs performances globales sont principalement limitées par la vitesse du processeur.

Le paramètre que vous définissez dans le Gestionnaire des tâches établit en fait la «priorité de base» pour tous les threads du processus. La priorité réelle ou "actuelle" du thread peut être supérieure (mais jamais inférieure à la base). Plus sur cela dans un instant. Les décisions de planification («qui doit s'exécuter et sur quel processeur») sont toujours prises en utilisant la priorité actuelle du thread. La priorité n'a de sens que pour les threads prêts et en cours d'exécution (ou, pour le dire autrement, la priorité n'a pas de sens pour les threads en attente).

Windows utilise un algorithme de planification préemptif . Si un seul thread du système veut utiliser le temps CPU, alors peu importe sa priorité; il obtient 100% du CPU. Ce n'est pas comme si l'ordonnanceur «retenait» une partie des capacités du processeur lorsqu'un thread de faible priorité est en cours d'exécution, au cas où quelque chose de priorité plus élevée se produirait.

Si deux threads veulent utiliser un CPU et qu'ils sont de la même priorité, ils sont alors planifiés via ce que l'on appelle le "time-slicing" et au fil du temps, chacun obtient environ 50% du temps du CPU. Alors que s'ils ont des priorités différentes, le thread de priorité supérieure obtient 100% et le thread inférieur n'obtient rien .

(En pratique, il n'obtiendra rien, car il subira une "augmentation de priorité d'évitement de la famine" périodique qui peut lui donner quelques dizaines de msec toutes les 4 ou 5 secondes environ. Mais ce n'est pas vraiment une exception à la "priorité plus élevée" gagne ", car cela se fait en ajustant la priorité du thread affamé.)

Si vous avez plus d'un cœur de processeur, les choses deviennent plus intéressantes et les priorités en général ont moins d' effet. Supposons que vous ayez deux threads à exécuter. Et supposons que vous ayez deux cœurs de processeur ou plus qui ne font rien d'autre de priorité égale ou supérieure à ces threads. Ensuite, vos deux threads obtiendront chacun 100% d'un noyau, quelles que soient leurs priorités respectives .

(Deux personnes se présentent au supermarché, et il y a deux contrôleurs gratuits. Un des clients a une carte "aller en tête de file". Peu importe.)

tl; version dr (jusqu'à présent): les priorités ne concernent pas "qui obtient quelle proportion du temps processeur", mais plutôt "qui doit s'exécuter en premier".

Je ne vais pas me lancer dans l'hyperthreading ici, sauf pour dire que Windows traite chacun des deux "processeurs logiques" dans un cœur à peu près de la même manière qu'il traiterait un cœur si HT était désactivé. c'est-à-dire qu'ils sont traités comme de «vrais» processeurs, à cette exception près: Windows s'efforcera de ne pas utiliser plus d'un LP dans un cœur à la fois. c'est-à-dire que vous ne commencez normalement pas à voir les deux LP dans un noyau utilisé jusqu'à ce que vous ayez plus d'un nombre de threads de cœurs essayant de les exécuter tous en même temps. C'est parce que les deux "processeurs logiques" ne vous donnent rien de deux fois les performances d'un seul cœur non hyperthreadé.

À propos de la "priorité de base": Windows ajustera ("boost" et "decay") la priorité actuelle des threads en fonction de ce qu'ils ont fait récemment. Les threads qui ont récemment terminé les opérations d'E / S seront normalement un cran ou deux au-dessus de la base; Les threads d'interface utilisateur (threads qui exécutent une fenêtre) seront souvent considérablement plus élevés; Les threads liés au CPU seront généralement à leur base. Le but de ceci est de maintenir la réactivité dans l'interface utilisateur du programme, et également de faire en sorte que les demandes d'E / S circulent vers des choses comme les disques.

Un programme (processus) peut également modifier la priorité de base de chacun de ses threads, dans une plage déterminée par la priorité du processus (ce que vous définissez dans le Gestionnaire des tâches). Mais la grande majorité des programmes ne dérange pas. (Plus d'entre eux devraient.)

Il se passe d'autres choses. En raison de l'augmentation / décroissance de la priorité et du fait que les systèmes multiprocesseurs (multicœurs, ou hyperthreadés, ou les deux) sont si courants de nos jours, et parce qu'il y a toujours des choses en arrière-plan dans Windows (mais, nous l'espérons, n'utilisant pas beaucoup de temps CPU), et en raison des effets de "l'affinité" dure et douce, il est difficile d'exécuter des cas de test et d'obtenir les résultats exacts qui seraient prédits ici. Mais cela devrait vous donner une image correcte.

En conclusion...

Il est raisonnable de laisser la plupart des choses à "Normal". Si vous ne le faites pas, vous pouvez facilement finir par affamer quelque chose que vous aimeriez vraiment faire fonctionner (même si vous ne savez peut-être pas qu'il existe), comme les fonctions de vidage du cache de disque du système d'exploitation. En effet, la plupart des processus du système d'exploitation ne seront pas normaux, et ils devraient être laissés là où Windows les a placés.

Un cas raisonnable pour utiliser le Gestionnaire des tâches pour jouer avec les priorités est si vous avez une tâche monopolisant le processeur (comme la vidéo ou le rendu 3D) et que cela ralentit votre utilisation du système pendant son fonctionnement. La bonne chose est, croyez-le ou non, de réduire sa priorité d'un cran ou deux. Il utilisera avec plaisir tous les cycles de CPU que rien d'autre ne veut mais restera à l'écart de votre utilisation interactive du système. Cela peut prendre un peu plus de temps pour faire son travail, mais il le fera avec une interférence minimale à votre utilisation interactive d'autres programmes. Si vous n'aimez pas ce compromis, ne le faites pas! Mais définissez-le sur une priorité élevée dans le but de "l'accélérer" et cela peut bloquer l'intégralité de votre interface utilisateur jusqu'à ce qu'elle soit terminée.

Ne définissez jamais rien sur la soi-disant classe de priorité en temps réel.

(Modifier - ce paragraphe ajouté) Ok, c'est une déclaration extrême. ("Aucune revendication universelle n'est vraie - à l'exception de celle-ci.") Du moins, non sans un examen très attentif. Si votre objectif est d'accélérer l'exécution de quelque chose, cela n'aidera probablement pas. Mais cela peut "verrouiller en dur" votre système (nécessitant une réinitialisation ou, sur la plupart des machines modernes, un cycle d'alimentation) Ou le rendre si insensible qu'il pourrait tout aussi bien être verrouillé en dur.

nb: Toute application de lecteur vidéo doit opter pour la fonction "Planification de cours multimédia" dans Vista et versions ultérieures. Cela lui donnera automatiquement jusqu'à 80% d'un processeur, calculé sur des intervalles relativement courts. Si vous ne pouvez pas obtenir une lecture sans problème avec cela, quelque chose ne va pas.

Pour plus de détails, consultez les chapitres sur les threads et la planification dans Windows Internals 6th Edition de Solomon, Russinovich et Ionescu.

Voir également ma réponse ici pour plus d'informations sur la façon dont les priorités de processus et de thread sont définies, et la signification de la colonne "Priorité" dans le Gestionnaire des tâches.

La modification des priorités modifie la façon dont le système d'exploitation alloue le temps processeur aux applications en cours d'exécution. Il ne produit des effets visibles que si l'utilisation globale du processeur est élevée.

Par exemple, vous encodez une vidéo et regardez une autre vidéo en même temps. Il est probable que l'application d'encodage utilisera 100% de la puissance de calcul sur tous vos cœurs de processeur. Par conséquent, d'autres applications peuvent bégayer.

Windows accordera par défaut une priorité "normale" égale aux deux applications. À ce stade, vous souhaiterez peut-être augmenter la priorité de votre logiciel de lecture de films. De cette façon, vous aurez une lecture vidéo fluide au détriment d'un encodage vidéo plus lent car le logiciel d'encodage sera dégradé en un processus d'arrière-plan par rapport au lecteur vidéo.