Priorité des processus et affinité - Notion d'affinité

Les processeurs sont multicœurs (multi-cores) depuis 2001 chez IBM, 2003 chez Sun, 2004 chez HP et 2005 chez Intel et AMD (les architectures x86 des PC).

Mais, les applications... sont-elles multiprocessus ? Sont-elles capables, ou non, d'exploiter plusieurs processeurs simultanément, parallèlement ?

Si elles ont été écrites avant ou peu après l'émergence des processeurs multi-cores, leur code ne sait absolument pas exploiter plusieurs processeurs (plusieurs cœurs) parallèlement. Ces applications sont totalement et définitivement monoprocesseurs. Dans les réglages d'affinité, elles peuvent être affectées à un seul cœur. L'« overhead » de la « commutation de contexte » (« context switching ») peut leur être évité. L'application peut, dans certains cas favorables, s'exécuter plus rapidement (peu de processus actifs simultanément donc aucun context switching pour l'application monoprocesseur). Indiquer l'utilisation de plusieurs coeurs à ce type d'applications est totalement inutile et sans aucun effet.

Pour les applications plus récentes, elles ont certainement été écrites dans un langage dont le compilateur a produit un code qui s'exécute en parallèle sur plusieurs processeurs. Aucune information n'est donnée sur ces applications, et encore moins sur le nombre de processeurs optimal à leur attribuer. Windows se débrouille très bien tout seul. Si vous cherchez à savoir, lancez l'application et regardez les ressources employées - peut-être observerez-vous l'usage de 2, 3, 4 cœurs (cores) - dans ce cas, vous pourrez affecter des cœurs (cores) dédiés à cette application.

Donc, à quoi sert l'affinité ?

• Lorsque vous utilisez des applications qui sont totalement dépendantes de la vitesse, au combien lente, de vos petits doigts, et qui ne consomment donc quasiment aucun temps CPU, mettez toutes ces applications sur le même cœur (core). Typiquement, lorsque vous utilisez Microsoft Office Word et Excel, ou LibreOffice Writer et Calc, ces applications sont utilisées très lentement et une à la fois (c'est vous qui basculez d'une fenêtre à l'autre lorsque ces applications sont ouvertes simultanément). Une fonction de recherche/remplacement va consommer beaucoup de puissance CPU, mais brièvement.

• Lorsque vous utilisez une application extrêmement gourmande en temps CPU, mettez-la sur un cœur (core) bien à elle. Typiquement, une application d'encodage d'une vidéo, qui va consommer 100% du temps CPU et tourner sans aucune intervention durant des heures, doit être affectée à un cœur (core) bien à elle. Si vous utilisez, simultanément, une autre application très gourmande en temps CPU, par exemple Adobe Première pour faire du montage vidéo, affectez cette application à un autre cœur (core). Toutes les applications gourmandes en temps CPU et que vous lancez ensemble devraient être affectées à des cœurs (cores) séparés.

• Le cas des processus système est à part. N'y touchez pas. Windows sait parfaitement ce qu'il fait et le sait mieux que nous.

• Le cas des antivirus et suites de sécurité et simple : un seul cœur (core), bien qu'ils aient deux fonctionnements. Dito pour les pare-feu : un seul cœur (core).

  1. La quasi-totalité du temps, ils sont en attente d'un événement et ne font rien (ces applications disposent d'un « driver » [implanté en tant que « service de Windows »], avec les privilèges du « ring 0 », et crochètent [hook] certains appels au système pour s'interposer, en temps réel. C'est assez peu consommateur de temps CPU et l'analyse de l'objet intercepté consiste essentiellement en un calcul rapide de son hashcode [condensat] pour voir s'il figure quelque part). Ce fonctionnement « en vrai temps réel » est totalement indépendant de la priorité de l'application.
  2. De temps en temps, tels que planifiés par l'utilisateur, ils exécutent une analyse complète des zones à risque (ou de tous les fichiers de tous les supports). Cette fonction est très consommatrice de temps CPU et très longue (plusieurs heures selon les volumes à analyser et les paramètres d'analyse fixés par l'utilisateur). Il est préférable de lui allouer une priorité « inférieure à la normale ».

• Si un doute existe à propos d'un cœur (core), obligez une application à utiliser uniquement ce cœur (core) et lancez-la. Si elle ne se lance pas, c'est que le cœur (core) est mort. Il est temps de sortir sa carte bancaire et de changer de processeur (ou de carte mère, ou de PC, ou d'abandonner le PC et de retourner à la vraie vie... !)

Les processus héritent de l'affinité de leur parent

Si l'Explorateur Windows (Explorer.exe) a une affinité paramétrée, au lieu de le laisser réglé sur la valeur par défaut (« Tous les processeurs »), alors toutes les applications lancées à partir de l'Explorateur Windows auront la même affinité que lui. Comme l'Explorateur Windows est une application que l'on ouvre pour faire quelque chose (ouvrir un fichier, lancer du code exécutable, une application, etc.) et qui n'a pas besoin de rester active, autant la laisser réglée sur « Tous les processeurs » et la fermer après usage, de manière à ce qu'elle ne soit pas dans la commutation de contexte et son overhead, ni dans l'allocation de tranches de temps pour rien. D'une manière générale, toujours laisser tous les composants de Windows avec leurs réglages d'« usine (Microsoft) ».

Cœurs (cores) mis au parking (parked cores)

Sur une machine fonctionnant sur batterie et dotée d'un processeur à plusieurs cœurs (cores), lorsque vous ouvrez l'onglet du Moniteur de ressources de Windows, vous pouvez parfois voir que certains cœurs (cores) sont parqués et totalement inactifs.

C'est un dispositif automatique d'économie d'énergie de Windows qui se déclenche selon vos réglages d'économie d'énergie et selon que vous êtes sur secteur ou sur batterie. En cas de besoin ils seront activés. En cas d'inutilité, ils sont arrêtés.

Par exemple : Démarrer > Sélectionnez Paramètres > Système  > Alimentation et mise en veille > Paramètres d'alimentation supplémentaires > Créer un mode de gestion de l'alimentation > Sélection d'Utilisation normale ou Économiseur d'énergie (et non Performances élevées).

Documentation :

Quantifying The Cost of Context Switch (anglais, University of Rochester, pas daté)
Little micro-benchmark for Linux to test the cost of context switching and system calls (anglais, utilitaire open source, Linux)
How long does it take to make a context switch (anglais, 14.11.2010)