Question Nombre optimal de threads en multitâche


Je sais que des questions similaires ont été posées mais je pense que mon cas est un peu différent.

Disons que j'ai un ordinateur avec 8 cœurs et une mémoire infinie avec un système d'exploitation Linux.

J'ai un logiciel de calcul appelé Gaussian qui peut tirer parti du multithreading. J'ai donc défini son nombre de threads à 8 pour un seul calcul de vitesse maximale. Cependant, je ne peux vraiment pas décider quoi faire lorsque je dois exécuter par exemple 8 calculs simultanément. Dans ce cas, dois-je définir le nombre de threads à 1 (total de 8 threads générés dans 8 processus) ou le conserver à 8 (total de 64 threads générés dans 8 processus) pour chaque job? Est-ce que ça compte vraiment beaucoup? Une question connexe est la suivante: le système d’exploitation effectue-t-il automatiquement le core-parking pour les cœurs différents pour chaque thread?

MODIFIER: Je sais que l'analyse comparative est la meilleure façon de savoir. Le fait est que les ordinateurs appartiennent à mon université, ils sont donc occupés tout le temps. En d'autres termes, sa charge de travail varie de manière incontrôlable car d'autres personnes utilisent ces ordinateurs pour leurs calculs, rendant l'expérience impossible. En outre, le logiciel est très coûteux (1500 $ ou quelque chose) et est autorisé pour chaque ordinateur, donc je ne peux pas simplement exécuter un benchmark sur mon ordinateur personnel ...


4
2017-10-24 01:37


origine


En respectant les réponses (correctes et exactes) données, il n’ya aucune garantie que le programme fonctionne mieux avec un nombre maximum de threads qu’avec un seul thread globalement, etc.), bien que s’il est programmé, il devrait. Comme le montre le consensus général, la meilleure chose à faire est de comparer chaque configuration avec un ensemble de tests limité. - Doktoro Reichard
Vous devriez juste le mesurer. - Der Hochstapler


Réponses:


Idéalement, le nombre total de threads pour tous les jobs doit correspondre au nombre de cœurs du système, sauf sur les systèmes prenant en charge l'hyper-threading, dans lesquels le nombre de cœurs doit être deux fois supérieur. Donc, si le système n'a pas d'hyper-threading, il y a 8 calculs en cours d'exécution, chacun devrait s'exécuter dans un thread.

De nombreux processeurs Intel sont dotés d'un hyper-threading, de sorte que chaque cœur peut prendre en charge deux threads. Par exemple, un système à 8 cœurs qui prend en charge l'hyper-threading devrait avoir 16 threads pour utiliser le système complètement.


5
2017-10-26 11:55





La réponse dépend de ce que fait le processus et de la programmation de son multi-threading, ce qui signifie que vous devrez expérimenter.

Si le processus utilise des sémaphores et d'autres mécanismes d'exclusion pour contention entre les threads sur les ressources communes (telles que la mémoire), le moins est le nombre de threads dans le processus, le moins est le nombre de conflits qui provoqueront des attentes.

Pendant une attente, le thread ne fait rien, donc les attentes auront un effet négatif sur le débit. Dans ce cas, plus de processus et moins de threads par processus amélioreront le débit, 8x8 aura donc de meilleures performances que 1x64.

Par contre, si chaque thread est totalement isolé et qu'il n'y a pas de commun partagé ressources, alors le système d'exploitation planifiera les threads sans aucune distinction entre les deux cas de 8x8 ou 1x64. Dans ce cas, seul le nombre total de threads est important pour le débit total, les deux cas sont donc de performance égale.


3
2017-10-26 17:54



Comme votre mise à jour dit que les ordinateurs sont très occupés, alors trop de threads auront l'effet contraire de ralentir l'ordinateur. La commutation du CPU entre les threads est une opération coûteuse. - harrymc


Le nombre correct dépend de combien de temps les processus passent bloqués sur IO.

Le livre "La concurrence dans la programmation sur la JVM" contient de bonnes informations à ce sujet:

"Détermination du nombre de threads". Pour un problème important, nous souhaitons avoir au moins autant de threads que le nombre de cœurs disponibles. Cela garantira que le nombre de cœurs disponibles pour le processus est utilisé pour résoudre notre problème ...

Le nombre minimum de threads est donc égal au nombre de cœurs disponibles. Si toutes les tâches exigent un calcul intensif, c'est tout ce dont nous avons besoin. Avoir plus de threads sera effectivement pénalisant dans ce cas car les cœurs changeraient de contexte entre les threads quand il y a encore du travail à faire. Si les tâches sont intensives, nous devrions avoir plus de threads.

Lorsqu'une tâche effectue une opération IO, son thread est bloqué. Le processeur modifie immédiatement le contexte pour exécuter d'autres threads éligibles. Si nous avions seulement autant de threads que le nombre de cœurs disponibles, même si nous avons des tâches à effectuer, elles ne peuvent pas être exécutées car nous ne les avons pas programmées sur les threads pour que les processeurs les détectent.

Si les tâches sont bloquées à 50%, le nombre de threads doit être deux fois supérieur au nombre de cœurs disponibles. S'ils passent moins de temps à être bloqués, c'est-à-dire qu'ils nécessitent un calcul intensif, nous devrions avoir moins de threads, mais pas moins que le nombre de cœurs. S'ils passent plus de temps à être bloqués - c'est-à-dire qu'ils sont intensifs en IO - alors nous devrions avoir plus de threads, en particulier plusieurs multiples du nombre de cœurs.

Nous pouvons donc calculer le nombre total de threads dont nous avons besoin comme suit:

Nombre de threads = Nombre de cœurs disponibles / (1 - Coefficient de blocage)

Si vous devez exécuter plusieurs calculs simultanément, vérifiez peut-être s'il est possible de les exécuter dans un processus avec un pool de threads de taille appropriée.

Sinon, si vous avez le nombre optimal de threads pour un calcul, puis exécutez 8 à la fois, vous pouvez en avoir trop.

La meilleure solution consiste à la tester expérimentalement.

Je ne suis pas tout à fait sûr de ce que vous entendez par parking de base, mais le processeur aura tendance à continuer à exécuter le même thread sur un noyau donné pour des raisons de cache, même s'il le déplacera parfois pour différentes raisons. Vous pouvez étudier cela en utilisant un outil tel que htop.


2
2017-10-29 21:09



Le truc, c'est que les ordinateurs appartiennent à mon université, donc il est occupé tout le temps. En d'autres termes, sa charge de travail varie de manière incontrôlable pour moi, car d'autres personnes utilisent également ces ordinateurs pour leurs calculs, rendant l'expérience impossible. - theGD
I / O est loin d'être la seule ressource partagée entre les threads. - harrymc


Vous avez répondu à la question vous-mêmes. "les ordinateurs appartiennent à mon université, ils sont donc occupés tout le temps"

En fait, vous ne recevez qu'une partie des processeurs. Pour que le travail soit effectué de la manière la plus efficace possible, il convient de minimiser la surcharge liée à la commutation des tâches et au multiplexage, ainsi que les ressources en attente.

Le multithreading est toujours moins efficace lorsqu'il est calculé en fonction de la "puissance de traitement" en raison de la surcharge de changement de contexte. Cela ne fait qu'accélérer les problèmes d'utilisation de toutes les ressources inoccupées «libres». idée: utilisez 8 ordinateurs pour résoudre un problème probablement 7,9 fois plus vite, ce qui ne peut jamais être supérieur à 8.

Si tout cela vous est dédié, faites-le simplement en parallèle pour accélérer, sinon garder le fil unique et laisser les autres utiliser le noyau restant pour d'autres travaux.

Soit dit en passant, de façon égoïste, il existe des outils qui appellent une grille qui peut vous séparer de tout le Linux sur le campus. (> 200). Il va tourner si vite, ne vous laissez pas prendre, car cela ralentira tout le monde. ou utilisez les anciens outils, mathlab parallel.


1
2017-10-31 13:41