Sur quel système d'exploitation la programmation threadée est-elle suffisante pour utiliser plusieurs cœurs ?

Question

Je voudrais utiliser mes compétences en programmation multithreading (j'en ai), mais je me rends compte que cela ne suffit pas. Mes threads peuvent toujours se disputer le même cœur si le système d'exploitation n'est pas conscient de ce potentiel. Quelle combinaison système d'exploitation/compilateur/librairie puis-je utiliser sur l'architecture Intel Xeon pour faire du threading sur les cœurs ?

Answer 1

Tous les systèmes d'exploitation modernes répartissent les threads sur tous les cœurs disponibles, mais plusieurs langages ou bibliothèques empêchent cette distribution :

• les threads verts. ils présentaient un avantage en termes de performances lorsque les processeurs multiples étaient rares et que les systèmes d'exploitation n'étaient pas suffisamment optimisés. quelques VM Java se sont vantées de cette fonctionnalité, qui s'est ensuite transformée en schéma M:N, et je pense que c'est maintenant N:N partout.

• GIL:Global Intepreter Lock. certains langages de script ont beaucoup d'états globaux dans la boucle de l'interpréteur, il y a donc un seul gros verrou (mutex) pour assurer la cohérence ; mais cela empêche deux threads du même 'espace' de fonctionner simultanément. Au moins Python et Lua ont ce problème. Dans ces cas, il est préférable d'utiliser des processus multiples plutôt que des threads multiples.

De plus, il est bon de se rappeler que le plus grand goulot d'étranglement dans la plupart des applications liées au processeur est la bande passante de la RAM, et généralement pas le processeur lui-même, donc avoir plusieurs threads qui se battent pour la même mémoire n'est pas forcément la meilleure conception. il est généralement bien mieux de refactoriser en plusieurs processus séparés qui communiquent via de petits messages.

Answer 2

Sur tous les systèmes d'exploitation. C'est à peu près la définition d'un fil de discussion.

Si vous créez une application qui lance deux threads, le système d'exploitation est capable de les placer sur deux cœurs distincts. Cela est vrai pour Windows, OSX, Linux et tout autre système d'exploitation auquel vous pouvez penser.

Answer 3

Puisque vous avez "acquis des compétences", je vais supposer que vous savez déjà que pratiquement tous les systèmes d'exploitation modernes exécuteront vos threads sur plusieurs cœurs s'ils sont disponibles et si vos threads n'ont pas de problème de verrouillage qui les rend effectivement séquentiels.

Je suppose donc que votre question est en fait de savoir comment lier vos threads aux cœurs afin qu'ils ne soient pas en concurrence les uns avec les autres. Cela se fait en définissant l'affinité du processeur du thread. Vous trouverez ci-dessous des liens vers des articles sur ce sujet pour Windows et Linux. Je suis sûr qu'il en existe d'autres pour d'autres versions d'Unix. Je note également que ce n'est généralement pas nécessaire, car en dehors de certains cas particuliers, le système d'exploitation sait mieux que vous où planifier les threads. Rappelez-vous, les systèmes d'exploitation modernes sont multiprocessus, donc vos threads ne sont pas seulement en compétition les uns avec les autres, ils sont en compétition avec les threads de tous les autres processus sur la machine. En fonction de la charge, limiter vos threads à un seul cœur peut en fait les rendre plus rapides.

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/core/fnef_mul_dnpl.mspx?mfr=true

http://www.ibm.com/developerworks/linux/library/l-affinity.html

Answer 4

Presque tous les systèmes d'exploitation modernes planifient les threads sur plusieurs cœurs, sans doute. Il est certain qu'aucune variante d'Unix avec laquelle j'ai joué n'a le moindre problème avec cela, et je suis presque certain que tous les Windows le gèrent bien. Le compilateur n'est pas un problème, car les threads natifs sont une chose au niveau du système d'exploitation, donc le compilateur transmet simplement le syscall vers le bas.

Il existe quelques langages (comme Ruby) qui n'utilisent pas de threads natifs, mais plutôt leurs propres threads "verts", qui sont implémentés dans l'interpréteur et ressemblent donc à un seul thread pour le système d'exploitation, mais ils sont l'exception plutôt que la règle, et la documentation explique généralement clairement ce qui se passe.

Answer 5

Faisons une petite distinction. Un logiciel qui est threadé ne va pas nécessairement fonctionner sur deux cœurs simultanément.

Vous devez écrire un code capable de fonctionner en multithreading simultané (SMT). La plupart des systèmes d'exploitation le supportent sans problème. La seule différence réelle réside dans la façon dont votre logiciel gère le verrouillage et les ressources. Si vos threads dépendent de la même mémoire ou des mêmes ressources, il y aura des conflits et des moments où l'un ou l'autre sera bloqué en attendant une ressource, une mémoire ou un autre verrouillage.

La plupart des langages de programmation qui intègrent le threading sont également capables de le faire. C'est au programmeur qu'il incombe de s'assurer que tout fonctionne simultanément.

Vous trouverez des informations sur la manière de procéder sous Windows avec Visual Studio C++ ici :

http://msdn.microsoft.com/en-us/library/172d2hhw.aspx

Il existe de nombreux tutoriels à ce sujet, notamment pour Windows (C#, C++, VB, etc.) - vous pouvez les trouver en effectuant une recherche :

http://www.google.com/search?q=simultaneous+multithreading+C%2B%2B

-Adam