nproc
donne le nombre de cœurs de processeur/threads disponibles, par exemple 8 sur un processeur quadricœur prenant en charge SMT bidirectionnel.
Le nombre de travaux que vous pouvez exécuter en parallèle avec make
en utilisant le -j
l'option dépend d'un certain nombre de facteurs :
- la quantité de mémoire disponible
- la quantité de mémoire utilisée par chaque
make
travail - la mesure dans laquelle
make
les tâches sont liées aux E/S ou au CPU
make -j$(nproc)
est un point de départ décent, mais vous pouvez généralement utiliser des valeurs plus élevées, tant que vous n'épuisez pas votre mémoire disponible et que vous ne commencez pas à battre.
Pour les constructions vraiment rapides, si vous avez assez de mémoire, je vous recommande d'utiliser un tmpfs
, de cette façon, la plupart des travaux seront liés au processeur et make -j$(nproc)
fonctionnera aussi vite que possible.
Le moyen le plus simple consiste à utiliser nproc
comme ceci :
make -j`nproc`
La commande nproc
renverra le nombre de cœurs sur votre machine. En l'enveloppant dans les tiques, le nproc
la commande s'exécutera en premier, renverra un nombre et ce nombre sera passé dans make
.
Vous pouvez avoir une expérience anecdotique où faire core-count + 1 entraîne des temps de compilation plus rapides. Cela a plus à voir avec des facteurs tels que les retards d'E/S, d'autres retards de ressources et d'autres contraintes de disponibilité des ressources.
Pour ce faire avec nproc+1
, essayez ceci :
make -j$((`nproc`+1))
Malheureusement, même différentes parties de la même construction peuvent être optimales avec des valeurs de facteur j conflictuelles, selon ce qui est construit, comment, quelles ressources système sont le goulot d'étranglement à ce moment-là, ce qui se passe d'autre sur la machine de construction, ce qui se passe dans le réseau (si vous utilisez des techniques de construction distribuées), l'état/l'emplacement/les performances des nombreux systèmes de mise en cache impliqués dans une construction, etc.
Compiler 100 petits fichiers C peut être plus rapide que d'en compiler un seul énorme, ou vice versa. Construire un petit code hautement alambiqué peut être plus lent que construire d'énormes quantités de code simple/linéaire.
Même le contexte de la construction compte - l'utilisation d'un facteur j optimisé pour les constructions sur des serveurs dédiés, ajusté pour des constructions exclusives et sans chevauchement, peut donner des résultats très décevants lorsqu'il est utilisé par des développeurs construisant en parallèle sur le même serveur partagé (chaque construction de ce type peut prendre plus temps que tous combinés s'ils sont sérialisés) ou sur des serveurs avec des configurations matérielles différentes ou virtualisés.
Il y a aussi l'aspect de l'exactitude de la spécification de construction. Les builds très complexes peuvent avoir des conditions de concurrence provoquant des échecs de build intermittents avec des taux d'occurrence qui peuvent varier énormément avec l'augmentation ou la diminution du facteur j.
Je peux continuer encore et encore. Le fait est que vous devez réellement évaluer votre construire dans votre contexte même pour lequel vous souhaitez optimiser le facteur j. Le commentaire de @ Jeff Schaller s'applique :itérez jusqu'à ce que vous trouviez votre meilleur ajustement. Personnellement, je commencerais par la valeur nproc, j'essaierais d'abord vers le haut et vers le bas uniquement si les tentatives vers le haut montrent une dégradation immédiate.
Il peut être judicieux de mesurer d'abord plusieurs builds identiques dans des contextes supposés identiques juste pour avoir une idée de la variabilité de vos mesures - si elle est trop élevée, cela pourrait compromettre l'ensemble de votre effort d'optimisation (une variabilité de 20 % éclipserait complètement une amélioration de 10 %/ lecture de la dégradation dans la recherche du facteur j).
Enfin, à mon humble avis, il est préférable d'utiliser un jobserver (adaptatif) s'il est pris en charge et disponible au lieu d'un facteur j fixe - il fournit systématiquement de meilleures performances de construction dans des contextes plus larges.