combien de cœurs dois-je utiliser pour les calculs? #cores ou #cores -1?

J'ai un gros calcul à faire. Bien que je puisse utiliser tous les cœurs, j'ai pensé qu'il y avait une raison de ne pas utiliser 1 cœur et de ne pas l'utiliser. (calcul cpu seulement pas d'E / S). Ou est-ce que je sous-estime le système d'exploitation qu'il ne saurait pas gérer et effectuer un changement de contexte approprié même si j'utilise tous les cœurs?

Les principaux systèmes d'exploitation sont suffisamment matures pour savoir comment gérer les processus qui utilisent tous les cœurs disponibles. D'autres processus peuvent (et seront souvent) affectés, mais le calcul ne ralentira pas car vous avez utilisé tous les cœurs disponibles.

Le choix du nombre de cœurs dépend davantage de votre intention de faire autre chose pendant le calcul.

Si, sur une machine de bureau, vous voulez pouvoir utiliser votre navigateur Web ou regarder une vidéo pendant le calcul, vous feriez mieux de garder un cœur libre pour cela. De la même manière, si le serveur fait deux choses (comme faire des calculs et, en même temps, traiter et rapporter ses métriques), garder un noyau libre pour la tâche secondaire pourrait être une bonne idée.

En revanche, si votre priorité est de rendre le calcul le plus rapide possible, vous devez utiliser tous les cœurs.

Ça dépend.

Si la machine est dédiée à ce calcul, vous devez utiliser tous les cœurs - les ressources informatiques inutilisées n'accélèrent pas les choses .

Si vous utilisez un planificateur en temps réel, un planificateur non préemptif ou une affinité de processeur, vous devriez être un peu plus prudent, car il est facile de mettre accidentellement à plat d'autres processus à partir de toutes les ressources informatiques. Cependant, vous devrez modifier manuellement ces paramètres pour que quelque chose se passe mal, donc par défaut, il n'y a pas de problème ici sur la plupart des systèmes d'exploitation.

Si la machine n'est pas dédiée au calcul, donner 100% au calcul peut ne pas être idéal. Par exemple, si vous utilisez un navigateur Web pendant l'exécution du calcul. Parce que la charge de votre machine dépassera parfois 100%, elle se sentira lente. Les tâches axées sur le débit comme le calcul ne seront pas vraiment ralenties, mais les tâches sensibles à la latence comme les interfaces graphiques ne réagiront pas aussi rapidement. Il est alors judicieux de ne démarrer que les threads / processus NPROC-1 pour le calcul. Alternativement, l'utilisation explicite d'une priorité plus faible pour le calcul que pour les tâches normales pourrait résoudre ce problème, auquel cas le calcul devrait utiliser des processus NPROC pour ne pas gaspiller de ressources.

Je suis quelque peu circonspect à l'idée d'être d'accord avec @motoDrizzt, ci-dessous, en raison de ses votes négatifs :), mais c'est effectivement mon expérience réelle - plus c'est mieux, même au-delà du nombre réel de cœurs (mais pas des milliers). Par exemple, jetez un œil à http://www.forkosh.com/images/avoronoi.gif où chaque plan 2D de ce 3D-voronoi_diagram peut être généré indépendamment. Et le programme prend un attribut nfork = n query_string pour effectuer les calculs pour n plans "simultanément".

Avec un processeur à quatre cœurs, le temps (de l'utilisateur) pour terminer le diagramme diminue de façon assez linéaire avec nfork, jusqu'à environ nfork = 8 (quatre cœurs hyperthreadés). Mais au-delà de 8, le temps diminue encore, bien que plus lentement. Et au-delà d'environ 16, environ, aucune autre amélioration notable. Je n'ai pas analysé ce comportement du tout, mais l'attribue naïvement aux processus de jonglage os (linux slackware 14.2x64 dans ce cas) pour réduire encore plus le temps d'inactivité global.

Le meilleur choix dépend du système. Donc, ce que vous voulez faire, c'est d'exécuter les deux versions sur un système réel, puis de vérifier la réponse du système. Pouvez-vous toujours utiliser un navigateur, un éditeur de texte, d'autres choses sur votre système? Et les performances sont-elles meilleures lorsque vous utilisez n threads et non n-1? Que se passe-t-il si vous exécutez l'application avec une autre application qui essaie d'utiliser tous les processeurs?

Et puis vous devez envisager l'hyperthreading. Avec quatre cœurs plus l'hyperthreading, vous pouvez utiliser 8 cœurs ou 7 cœurs. Encore une fois, essayez la réactivité du système et le temps de terminer.

Et enfin, envisagez de diviser votre travail en plus de blocs que de threads. La raison en est que différents threads termineront le travail à des moments différents, et que vous souhaitez ensuite laisser du travail aux threads les plus rapides. Sinon, vous devrez attendre que le dernier thread soit terminé.

PS. "L'hyperthreading ne peut pas aider avec le code intensif FPU car il n'y a qu'un seul FPU". Absolument faux. Il est incroyablement difficile, même avec du code intensif FPU, d'utiliser pleinement le FPU en raison des latences. L'hyperthreading est utile car il existe deux fois plus d'opérations indépendantes disponibles pour la planification.

Je ne sais pas comment écrire ceci d'une manière qui ne sonne pas "mauvaise", alors prenez-le comme une remarque amicale, d'accord?

Étant donné qu'un PC moyen possède déjà généralement des milliers ou plus de threads, qu'est-ce qui vous fait penser que l'utilisation de 8 vs 7 fera une différence? :-)

Utilisez autant de threads que possible. Et si vous n'avez pas à vous soucier de la réponse du système d'exploitation et que vos threads fonctionnent assez longtemps (plus d'une seconde), vous pouvez même expérimenter en utilisant deux fois le nombre de cœurs.