Nombre optimal de threads par noyau

Question

Disons que j'ai un PROCESSEUR 4 cœurs, et je veux lancer un processus dans le minimum de temps. Le processus est idéalement parallélisables, donc, je peux utiliser des morceaux de celui-ci sur un nombre infini de fils et chaque thread prend la même quantité de temps.

Depuis que j'ai 4 coeurs, je n'ai pas s'attendre à une accélération en cours d'exécution de plus de threads que de cœurs, car un seul core est seulement capable d'exécuter un seul thread à un moment donné. Je ne sais pas beaucoup sur le matériel, si ce n'est qu'une supposition.

Est-il un avantage à utiliser une parallélisables processus sur plus de threads que de cœurs? En d'autres termes, mon processus de finition plus rapide, plus lent, ou dans environ la même quantité de temps si je l'exécute à l'aide de 4000 threads plutôt que 4 threads?

Answer 1

Si votre fils de ne pas faire d'e/S, synchronisation, etc., et il n'y a rien d'autre en cours d'exécution, 1 thread par core permettra d'obtenir le meilleur rendement. Cependant que très probablement pas le cas. L'ajout de plus de threads permet habituellement, mais après un certain point, ils provoquent une dégradation des performances.

Il n'ya pas longtemps, je faisais des tests de performance sur un 2 quad-core de la machine de l'exécution d'une ASP.NET application sur Mono sous un assez décent de charge. Nous avons joué avec le minimum et le nombre maximum de threads et à la fin, nous avons constaté que pour une application particulière dans cette configuration le meilleur débit se situe entre 36 et 40 threads. Rien à l'extérieur de ces limites effectué pire. Leçon apprise? Si j'étais vous, je voudrais tester avec différents nombre de threads jusqu'à ce que vous trouver le bon numéro pour votre application.

Une chose est sûre: 4k fils va prendre plus de temps. C'est beaucoup de changements de contexte.

Answer 2

Je suis d'accord avec @Gonzalo de réponse. J'ai un processus qui ne fait pas de I/O, et voici ce que j'ai trouvé:

Notez que tous les threads de travail sur un tableau, mais les différentes gammes (les deux fils n'ont pas accès au même indice), de sorte que les résultats peuvent différer si ils ont travaillé sur les différents tableaux.

Le 1.86 machine est un macbook air avec un SSD. Les autres mac est un iMac avec un HDD normal (je pense que c'est un 7200 tr / min). Les fenêtres de la machine dispose également d'un 7200 tr / min disque dur.

Dans ce test, le nombre optimal est égal au nombre de cœurs de la machine.

Answer 3

Je sais que cette question est un peu vieux, mais les choses ont évolué depuis 2009.

Il y a deux choses à prendre en compte: le nombre de cœurs, et le nombre de threads qui peuvent s'exécuter à l'intérieur de chaque cœur.

Avec les processeurs Intel, le nombre de threads est définie par la fonction Hyperthreading, qui est à seulement 2 (lorsque disponible). Mais l'Hyperthreading réduit votre temps d'exécution par deux, même lorsque vous n'utilisez pas 2 fils! (c'est à dire 1 pipeline partagé entre deux processus -- ce est bon quand vous avez plus de processus, mais pas autrement. Plus de core est définitivement mieux!)

Sur d'autres processeurs, vous pouvez avoir 2, 4 ou même 8 threads. Donc, si vous avez 8 cœurs de chacun de soutien 8 threads, vous pourriez avoir 64 processus s'exécutant en parallèle, sans changement de contexte.

"Pas de changement de contexte" n'est évidemment pas vrai, si vous exécutez un système d'exploitation standard qui va faire le changement de contexte pour toutes sortes d'autres choses hors de votre contrôle. Mais c'est l'idée principale. (Note bien que certains Systèmes d'exploitation vous permettent d'allouer des processeurs de sorte que seul votre application a accès ou à l'utilisation dudit processeur!)

De ma propre expérience, si vous avez beaucoup d'I/O, plusieurs threads est bon. Si vous avez de très lourds de la mémoire de travail intensif (lire la source 1, lecture de la source 2, rapide calcul, écriture) puis avoir plus de threads n'aide pas. Encore une fois, cela dépend de la quantité de données en lecture/écriture simultanément (si vous utilisez de l'ESS 4.2 et lire 256 valeurs de bits, qui s'arrête tous les threads dans leur démarche... en d'autres mots, 1 thread est probablement beaucoup plus facile à mettre en œuvre et sans doute à peu près aussi rapide sinon plus rapide. Cela dépendra de votre processus de la mémoire et de l'architecture, certains serveurs d'avancées de gérer des plages de mémoire pour séparer les noyaux afin de séparer les fils sera plus rapide en supposant que vos données sont correctement classés,... c'est pourquoi, sur certaines architectures, 4 processus sera exécuté plus rapidement que 1 processus avec 4 fils.)

Answer 4

La performance réelle dépendra du rendement volontaire de chaque thread. Par exemple, si les threads ne font AUCUNE E / S et n'utilisent aucun service système (c'est-à-dire qu'ils sont liés à 100% à un CPU), 1 thread par core est optimal. Si les threads font quelque chose qui nécessite d'attendre, vous devrez expérimenter pour déterminer le nombre optimal de threads. 4000 threads entraîneraient une surcharge de planification importante, ce qui n'est probablement pas optimal non plus.

Answer 5

4000 threads en même temps est assez élevé.

La réponse est oui et non. Si vous faites beaucoup de blocage I/O dans chaque thread, alors oui, vous pouvez afficher des accélérations significatives faire jusqu'à probablement 3 ou 4 threads par logique de base.

Si vous ne faites pas beaucoup de bloquer les choses mais dans ce cas, les frais généraux supplémentaires avec filetage, va juste le rendre plus lent. Il faut donc utiliser un générateur de profils et de voir où les goulets d'étranglement dans chacun parallèle pièce. Si vous faites de lourds calculs, plus de 1 thread par CPU ne va pas aider. Si vous faites beaucoup de transfert de mémoire, il ne va pas aider non plus. Si vous faites beaucoup d'I/O, mais comme pour les accès disque ou d'accès à internet, alors oui plusieurs threads vont aider jusqu'à un certain point, ou au moins de rendre l'application plus réactive.