Qu'est-ce que la priorité et l'affinité de Windows et quels avantages offre-t-il?


9

Qu'est-ce que la priorité et l'affinité (trouvées dans le Gestionnaire des tâches) et à quoi servent-elles:

Trouvé dans le Gestionnaire des tâches

Dans quelles situations doivent-ils / pourraient-ils être utilisés et quels avantages sont trouvés lors de la personnalisation de ces paramètres.

Réponses:


3

La définition de l'affinité fait quelque chose, mais vous ne voudrez plus jamais l'utiliser.

La définition de l'affinité CPU oblige Windows à n'utiliser que le CPU (ou les cœurs) sélectionné. Si vous définissez l'affinité sur un seul processeur, Windows exécutera uniquement cette application sur ce processeur, jamais sur aucun autre.

Windows place automatiquement les applications exécutées sur le processeur le moins occupé, donc le limiter à un seul processeur ne permet pas à Windows de faire son travail. Même si CPU / core 1 est occupé à exécuter d'autres applications, Windows ne pourra pas exécuter une application avec une affinité définie sur CPU / Core 2.

Vraiment, la seule raison pour laquelle vous voudriez le faire est d'exécuter une ancienne application qui ne fonctionne pas correctement lors de l'exécution sur un système multi-CPU / Core.


5
> vous ne voudrez plus jamais l'utiliser. Pas vrai. Si vous avez une application à thread unique, elle ne peut pas utiliser les threads / cœurs du processeur dans toute sa mesure et Windows ne peut rien faire pour la forcer / la tromper. Si vous avez deux applications à un seul thread, vous pouvez dire à Windows d'utiliser chacune un thread / core séparé de sorte qu'au lieu d'avoir une utilisation totale du CPU oscillant entre 50 et 75%, vous pouvez le maximiser à 100% (chaque core utilisé au maximum par un programme). Alors oui, vous pouvez en effet utiliser le paramètre, mais c'est un scénario spécifique que la plupart des gens ne connaissent pas / ne réalisent pas / n'ont pas besoin.
Synetech

2
Si vous avez deux applications à thread unique, Windows s'exécutera chacune sur un thread / noyau différent et vous obtiendrez une utilisation de 100% du processeur sans définir d'affinité. Pour tester, je viens d'exécuter 4 instances d'un programme à thread unique sur ma machine à 4 cœurs et j'ai obtenu 100% d'utilisation du processeur. Windows est suffisamment intelligent pour planifier efficacement le processeur.
shf301

Je suppose que cela dépend du système et / ou de la version de Windows. Je l'ai vu (XP) survoler les deux cœurs à 50-75% où les deux processus ont été définis sur les deux cœurs et les régler manuellement au maximum du processeur.
Synetech

@Synetech: Cela semble presque impossible. Il aurait fallu déplacer les deux processus d'un cœur à l'autre, toujours les deux en même temps.
David Schwartz

Un autre cas d'utilisation valable pour cela: il existe des applications qui peuvent utiliser tous les processeurs disponibles et empêcher d'autres programmes de bien fonctionner et / ou faire réagir le système d'exploitation très lentement aux entrées de l'utilisateur. Dans ce cas, quelqu'un pourrait décider de limiter une telle application à seulement certains CPU. En tant que développeur, j'utilise cette fonctionnalité fréquemment lors du profilage de mes applications gourmandes en CPU, car l'acte de profilage lui-même nécessite un CPU.
Eyal Roth

2

La définition de l'affinité indique à ce processus sur quels processeurs il est autorisé à s'exécuter.

Bien que très utile pour certains cas de niche, l'utilisateur moyen ne devrait probablement pas jouer avec.

Par exemple, si un processus était autorisé à exécuter son propre noyau, il pourrait s'exécuter en (presque) temps réel sans que ces 70 utilitaires Windows interrompent et échangent constamment la pile sur le processeur pour leur propre tranche de temps. Les applications en temps réel étaient quelque chose que Windows ne pourrait jamais faire avant que les systèmes multiprocesseurs / multicœurs n'entrent en scène, car le système d'exploitation interromprait / commutait constamment l'application pour ses propres besoins. Cela peut maintenant être principalement surmonté en isolant l'application en temps réel d'un processeur tout en empêchant toutes les autres applications du système d'utiliser ce processeur. C'est un sujet très spécifique, mais des systèmes tels que les simulateurs de vol (réels), l'automatisation en usine et les systèmes de rétroaction des commandes dépendent de l'architecture en temps réel pour fonctionner.

Les applications gourmandes en processeurs (comme les machines virtuelles) peuvent être isolées dans leur propre cœur afin que vous puissiez les utiliser sans analyser le reste de votre système. En théorie, un hyperviseur fonctionnant sur un processeur prenant en charge l'interaction hyperviseur nu peut atteindre des performances de processeur égales à un système d'exploitation indépendant s'exécutant seul (moins le processeur nécessaire pour exécuter le système d'exploitation hôte). Bien sûr, dans la pratique, même une machine virtuelle fonctionnant sur son propre cœur / processeur isolé devra toujours accepter une petite quantité de surcharge de l'hôte du système d'exploitation hôte.

Pour les applications qui gèrent une grande quantité de données en flux, l'isolement de l'application sur son propre processeur (et potentiellement en utilisant toujours plusieurs cœurs) réduira l'échange de cache.

Les applications plus anciennes qui se cassent lorsqu'elles sont réparties sur plusieurs processeurs peuvent effectivement être limitées à un cœur / processeur pour résoudre le problème.

Si vous faisiez des mesures de performances sur une application spécifique, il est presque impossible d'obtenir des résultats cohérents sur différents systèmes, sauf si vous pouvez isoler le processus car, sinon, vous n'avez aucun contrôle sur le temps que le système d'exploitation donne à votre application. La plupart des gens conviennent que la mesure des performances d'exécution ne donne pas de bons résultats, mais ces personnes n'ont jamais considéré que l'intervention du système d'exploitation (qui rend les résultats si incohérents) peut être limitée en utilisant l'affinité.

Il existe de nombreux cas où l'affinité est vitale, mais si vous ne savez pas ce que c'est, vous n'en aurez probablement pas besoin.


La chose qui rend l'affinité beaucoup moins utile que beaucoup ne le pensent est la suivante: définir l'affinité de votre processus pour un sous-ensemble des processeurs disponibles. ne ferme rien d'autre de ces processeurs. Pour ce faire, vous devez accéder à tous les autres processus du système pour les garder hors du processeur que vous souhaitez avoir pour vous-même. Ce n'est presque jamais pratique.
Jamie Hanrahan

C'est possible en utilisant un logiciel tiers . Pourquoi MS n'inclut pas cette fonctionnalité par défaut me dépasse.
Evan Plaice

Parce que, comme je l'ai écrit, ce n'est pas du tout utile. Et il est très sujet à une mauvaise utilisation. En fait, le résultat habituel d'être trop "créatif" avec l'affinité est que les choses ne fonctionnent pas alors qu'elles pourraient l'être autrement. Il est généralement préférable d'exécuter un thread sur un autre que celui que vous pensez être le processeur préféré que pas du tout (après avoir défini bêtement l'affinité pour lui refuser l'accès aux processeurs qui sont autrement inactifs). Le mécanisme par défaut du "processeur idéal" et du "processeur précédent" de Windows accomplit une bonne cohérence de cache sans cet instrument contondant du masque d'affinité.
Jamie Hanrahan

2

Il s'agit d'une fonctionnalité très utile dans certains scénarios. Supposons que vous ayez une application multithread qui a tendance à être inactive ou à saisir agressivement 100% de chaque CPU pendant plusieurs minutes, faisant des recherches, des builds, etc. Appelons cette application "éclipse".

Disons également que pendant que vous travaillez sur cette application, vous avez un tas d'autres applications qui ont des exigences de processeur modestes, mais sont essentiellement des applications en temps réel. Par exemple, pendant que vous utilisez Eclipse et qu'il lance des builds au hasard ou effectue des compilations gwt, vous utilisez également votre ordinateur pour diffuser de la musique ou effectuer des recherches dans une fenêtre de navigateur (par exemple, rechercher la cause d'un problème de build) . Bien sûr, vous ne mourrez pas si votre musique saute ou si votre navigateur cesse de répondre, mais c'est ennuyeux.

Ce que l'affinité vous permet de limiter votre application de restauration de processeur à 7/8 cœurs afin que tout le monde ait un accès garanti à un processeur relativement inutilisé et que vous n'ayez pas constamment à faire face au bégaiement et aux interruptions de l'utilisation de tout le reste sur votre ordinateur tandis que l'éclipse s'effrite.


Vous seriez beaucoup mieux dans ce cas en définissant simplement votre processus de porc CPU à une faible priorité.
Jamie Hanrahan

1

Une priorité plus élevée signifie que le traitement d'une tâche sera avantagé par rapport aux tâches de faible priorité. Si vous exécutez une application dont vous avez besoin pour être très réactif, et un tas d'autres processus non interactifs par exemple, les priorités peuvent garantir une meilleure expérience avec votre processus hautement prioritaire.

Par exemple: depuis Windows Vista, Windows Media Player obtient automatiquement une priorité plus élevée pour assurer une lecture fluide et continue des fichiers multimédias, avec seulement environ 20% du temps CPU disponible pour les autres processus par défaut. Ceci est juste un exemple pour vous aider à comprendre quelles sont les priorités. (Vous pouvez en savoir plus sur les priorités du lecteur multimédia dans Vista sur Technet .)

Une affinité douce ou dure peut augmenter la vitesse de traitement car le cache du processeur peut toujours contenir des restes du processus lorsqu'un processus a été précédemment interrompu, puis repris ultérieurement.


Merci merci! Alors, quel est un bon guide pour utiliser afinity?
James Mertz


Un bon guide pour utiliser l'affinité: "Ne pas".
Jamie Hanrahan

Le "seulement 20% de temps CPU disponible pour d'autres processus" n'est pas une description précise. L'implémentation réelle est qu'un thread qui opte pour le planificateur de classe multimédia est autorisé à s'exécuter jusqu'à 80% de chaque intervalle de planification dans la classe de priorité en temps réel. Il ne doit pas nécessairement en utiliser autant, et si ce n'est pas le cas. plus de 20% seront disponibles pour d'autres threads.
Jamie Hanrahan du

1

Un exemple parfait de ceci est les anciens jeux informatiques (ou autres logiciels), en particulier lorsque les jeux (applications) 32 bits sont émulés sur un ordinateur 64 bits moderne. En définissant l'affinité pour les anciens jeux en les limitant à seulement quatre cœurs, les plantages peuvent souvent être évités pour permettre aux jeux stubburn de démarrer. Certains moteurs de rendu utilisés par les anciens jeux, les éditeurs vidéo et les logiciels graphiques accélérés par le matériel ou les logiciels de CAO ne comprennent pas plus de quatre cœurs de processeur et se bloqueront lorsqu'ils seront lancés.

Je ne crée pas de compte juste pour poster ceci, pour me trouver google 'kieseyhow'

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.