2010-05-25 6 views
2

Si j'ai des cœurs X sur ma machine et que je démarre des threads X. Supposons pour l'argument que chaque thread est complètement séparé en termes de mémoire, hdd, etc, il utilise. Est-ce que le système d'exploitation va savoir envoyer chaque thread à un noyau ou faire plus de temps sur un noyau pour plusieurs threads. La question se résume à, si j'ai des cœurs X et mon programme doit faire des calculs indépendants, devrais-je démarrer X threads, seront-ils chacun canalisé à un noyau, ou est la présomption que parce que j'ai X cœurs je peux commencer X discussions complètement faux? Je pense que c'est. Ceci est avec C# -Filetage et noyaux

+1

Dupliquer: http://stackoverflow.com/questions/32343/how-do-i-spawn-threads-on-different-cpu-cores. Et, vous n'obtenez pas nécessairement de meilleures performances en exécutant chaque thread sur son propre noyau car vous ne savez pas ce que les autres coeurs font (le système d'exploitation le sait). – Seth

+0

Je pense que l'idée serait de lancer un fil de discussion pour chaque partie de l'entreprise qui peut être exécutée indépendamment. Comment et pourquoi l'ordinateur décide quel noyau exécuter un thread dépend de toutes sortes de choses, et je vous recommande de ne pas essayer de micro-gérer cela. – overslacked

Répondre

2

Je vais dire non ...

L'équipe .NET a présenté le TPL à déléguer explicitement l'exécution des threads d'utiliser plusieurs cœurs. Windows Vista n'a pas intégré beaucoup d'intelligence pour prendre en charge le système d'exploitation délégant des threads à plusieurs cœurs. Je ne suis pas surpris de voir cette amélioration dans le framework .NET (4.0) considérant que Windows 7 a beaucoup amélioré le support pour plusieurs cœurs.

0

Je suppose que cela peut dépendre de la plate-forme et du système d'exploitation. D'après mon expérience, avec une application de console C++ sur Linux, l'utilisation de threads X sur des cœurs X est exactement la bonne chose si vous avez besoin d'extraire autant de performance que possible d'une machine. Cependant, notez que toute tâche simultanée (y compris l'interface graphique) ne consommera pas le temps CPU disponible pour votre programme. Mais sur un serveur dédié sans interface graphique, chaque core 99-100% était utilisé exclusivement par mon programme.

0

Depuis que C# utilise des threads natifs, je pense que je peux commenter, même si mon expérience est principalement avec Java (sur Windows). En général, le système d'exploitation essayera d'équilibrer la charge, donc si vous atteignez un noyau avec une tâche de calcul intensif sur un thread, alors peu de threads seront planifiés sur ce noyau.

J'ai récemment écrit du code multithread gourmand en ressources en utilisant un framework de tâches, où le travail est divisé en petites tâches et fourni à N files d'attente. Chaque file d'attente appartient à un thread. Je me suis accéléré linéairement en augmentant le nombre de threads de 1..X où X était le nombre de cœurs. Donc, en général, la réponse est oui, vous pouvez vous attendre à ce que le système d'exploitation fasse ce qu'il faut, en particulier lorsque le nombre de threads augmente et se rapproche du nombre de cœurs.

2

Cela dépend entièrement de la quantité de travail que chaque thread va faire. Si vous deviez démarrer 4 threads sur une machine à 4 cœurs et que vous exécutez simplement une boucle serrée, il est probable qu'elle consommera 100% du temps CPU total.

Sur la question plus générale de savoir si, étant donné k fils et k noyaux, le système d'exploitation programmera automatiquement chaque thread 0->k -1 sur le noyau 0->k -1, Cela ne peut pas être garanti. En général, une fois qu'un thread est sur le point d'être planifié, il sera alloué à la prochaine CPU disponible. Cependant, le système d'exploitation sera, je crois, intelligent, et essaiera de réutiliser le même noyau que le thread précédemment exécuté, étant donné que les données locales de thread risquent d'être mises en cache sur ce noyau. Cependant, cela dit, dans le monde actuel des caches de processeurs partagés, cela ne sera pas une condition préalable à une bonne programmation des threads.

Vous pouvez influencer l'affinité d'un thread pour un core donné en appelant la méthode SetProcessorAffinity(). Cependant, j'ai tendance à ne pas le faire, parce que le système d'exploitation est généralement assez bon pour obtenir vos discussions.

ATTENTION

Il y a quelques questions intéressantes avec accès mémoire non uniforme sur plusieurs threads qui cause des fils de bloquer l'autre, même lorsqu'il n'y a pas de blocage impliqué. Supposons que vous disposiez d'un grand nombre de valeurs et que vous souhaitiez que les threads n fonctionnent. Vous devez vous assurer que chaque thread accède aux données qui se trouvent sur une ligne de cache séparée aux données accédées par d'autres threads - un problème de bas niveau qui n'est pas quelque chose que les programmeurs .Net (mais ceux qui ont grandi sur des plates-formes C++ ou inférieures) traiter avec.

Le problème est parfaitement démontré dans this article du magazine MSDN. Cela fait une lecture fascinante.

0

Généralement, c'est au programmeur du système d'exploitation d'assigner les tâches aux cœurs en cours d'exécution. Soit N le nombre de tâches à exécuter et X le nombre de cœurs d'exécution.

Si N < X, les ressources de votre machine ne seront pas entièrement utilisées, sauf si d'autres tâches sont en cours d'exécution. si N> = X, c'est la «meilleure intention» du système d'exploitation de répartir la charge entre tous les cœurs disponibles. En réalité, vous ne pouvez pas garantir que toutes les tâches s'exécuteront sur des cœurs séparés à moins que vous n'appliquiez l'affinité sur chaque thread de tâche. Si l'ancien système d'exploitation ne comprend pas les processeurs SMT, il peut être trompé et peut allouer plusieurs tâches par cœur tandis que d'autres sont inactifs.