Threading vs parallélisme, en quoi diffèrent-ils?
Quelle est la différence entre le filetage et le parallélisme?
Lequel a l'avantage sur l'autre?
Daniel Moth (un ancien de mes collègues) - Threading/Concurrency vs Parallelism article explique tout.
Cité:
Pour tirer parti de plusieurs cœurs de notre logiciel, les threads doivent finalement être utilisés. De ce fait, certains développeurs tombent dans le piège d'assimiler le multithreading au parallélisme. Ce n'est pas précis ... Vous pouvez avoir le multithreading sur une machine à un seul cœur, mais vous ne pouvez avoir le parallélisme que sur une machine à plusieurs cœurs
Le test rapide: si vous utilisez des threads sur une machine à cœur unique et que cela est parfaitement logique pour votre scénario, alors vous ne faites pas du parallélisme, vous faites simplement du multithreading.
Le parallélisme est une technique générale consistant à utiliser plus d'un flux d'instructions pour effectuer un calcul. L'aspect critique de toutes les techniques parallèles est de communiquer entre les flux pour collaborer à une réponse finale.
Le threading est une implémentation spécifique du parallélisme. Chaque flux d'instructions reçoit sa propre pile pour conserver un enregistrement des variables locales et des appels de fonction, et communique implicitement avec les autres flux par mémoire partagée.
Un exemple pourrait être d'avoir un thread simplement mettre en file d'attente les demandes de disque et les transmettre à un thread de travail, parallélisant efficacement le disque et le processeur. La méthode traditionnelle des tubes UNIX consiste à les diviser en deux programmes complets, par exemple "cat" et grep dans la commande:
cat /var/log/Xorg.0.log | grep "EE"
Le thread pourrait réduire les coûts de communication de la copie des E/S disque du processus cat vers le processus grep.
Le threading est généralement appelé à avoir plusieurs processus fonctionnant en même temps sur un seul processeur (enfin, vous ne pensez pas qu'ils le font, mais ils basculent très rapidement entre eux).
Le parallélisme consiste à faire fonctionner plusieurs processus en même temps sur plusieurs processeurs.
Les deux ont leurs avantages et leurs inconvénients en fonction du planificateur utilisé par votre système d'exploitation. Habituellement, le coût de calcul de la création d'un thread est beaucoup plus bas que celui de la création d'un processus sur un autre processeur, mais avoir un processeur `` entier '' pour vous-même augmente la vitesse globale de ce processus. Mais là encore, si ce processus a besoin de communiquer avec un autre processus sur un autre processeur, vous devez résoudre le problème IPC (communication inter processus)) qui pourrait être une telle surcharge qu'il est effectivement préférable de simplement utiliser un thread sur le même processeur.
La plupart des systèmes d'exploitation sont conscients de la présence de plusieurs processeurs/cœurs et peuvent les utiliser, mais cela rend le planificateur généralement assez complexe.
Si vous programmez dans un langage qui utilise un VM (machine virtuelle), sachez qu'ils doivent implémenter leur propre planificateur (le cas échéant). Python) = par exemple utilise un GIL, qui dit à peu près que tout ce qui tourne dessus VM reste toujours sur le même CPU. Bien que certains OS soient capables de migrer un processus lourd vers un autre CPU qui n'est pas t tellement occupé pour le moment, ce qui signifie bien sûr que l'ensemble du processus doit être interrompu pendant qu'il le fait.
Certains systèmes d'exploitation comme DragonFlyBSD adoptent une approche totalement différente de la planification, puis ce qui est actuellement l'approche "standard".
Je pense que cette réponse vous donne suffisamment de mots-clés pour rechercher plus d'informations :-)
Voici la meilleure réponse pour dissiper les doutes de quiconque concernant le parallélisme et le threading.
Les threads sont une construction logicielle. Je peux démarrer autant de pthreads que je veux, même sur un ancien processeur monocœur. Le multi-threading n'est donc pas forcément parallèle: il n'est parallèle que si le matériel peut le supporter. Donc, si vous avez plusieurs cœurs et/ou l'hyperthreading, votre multi-threading devient parallèle. Et ces jours-ci, c'est en fait la plupart du temps.
La concurrence concerne les activités qui n'ont pas d'ordre temporel clair. Donc, encore une fois, si le matériel le prend en charge, ils peuvent être effectués en parallèle, sinon, non.
Ainsi, traditionnellement, le multi-threading est presque synonyme de concurrence. Et les deux ne deviennent parallèles que si le matériel le prend en charge. Même dans ce cas, vous pouvez démarrer beaucoup plus de threads que le matériel ne prend en charge, et vous vous retrouvez avec la concurrence.
Le threading est une technologie, le parallélisme est un paradigme qui peut être implémenté en utilisant le threading (mais qui pourrait tout aussi facilement être réalisé en utilisant des threads uniques sur plusieurs processeurs)
Il existe deux types de concurrence d'accès:
- Threading: le processeur bascule très rapidement entre les différents threads, ce qui donne un mensonge de concurrence. Keypoint: n seul thread est en cours d'exécution à un moment donné. Lorsqu'un thread est en cours d'exécution, les autres sont bloqués. Vous pourriez penser, en quoi est-ce utile que de simplement exécuter une procédure? Eh bien, pensez-y comme une file d'attente prioritaire. Les discussions peuvent être planifiées. Le planificateur de processeur peut donner à chaque thread un certain temps pour s'exécuter, les mettre en pause, transmettre des données à d'autres threads, puis leur donner différentes priorités à exécuter ultérieurement. C'est un must pour pas les processus instantanés qui interagissent les uns avec les autres. Il est largement utilisé dans les serveurs: des milliers de clients peuvent demander quelque chose en même temps, puis obtenir ce qu'ils ont demandé plus tard (si cela est fait de manière procédurale, un seul client peut être servi à la fois). Philosophie: faire différentes choses ensemble. Cela ne réduit pas le temps total (point discutable pour le serveur, car un client ne se soucie pas du nombre total de demandes des autres clients).
- Parallélisme: les threads fonctionnent en parallèle, généralement dans différents cœurs de processeur, véritable concurrence. Keypoint: plusieurs threads sont en cours d'exécution à un moment donné. C'est utile pour les calculs lourds, processus très longs. Même chose avec un parc de machines monocœur, divisez les données en sections pour chaque machine à calculer, regroupez-les à la fin. Différentes machines/cœurs sont difficiles à interagir les uns avec les autres. Philosophie: faites une chose en moins de temps.
Comme vous pouvez le voir, ils résolvent des types de problèmes totalement différents.
Si nous pensons CPU en tant qu'entreprise et threads en tant que travailleurs alors, cela nous aide à comprendre plus facilement le threading et le parallélisme.
Tout comme une entreprise compte de nombreux travailleurs, le processeur comporte également de nombreux threads.
De plus, il peut y avoir plus d'une entreprise et donc il peut y avoir plus d'un processeur.
Par conséquent, lorsque les workers (threads) travaillent dans une entreprise (CPU), cela s'appelle threading.
Et lorsque deux ou plusieurs entreprises (CPU) travaillent indépendamment ou ensemble, cela s'appelle parallélisme.
Comment définissez-vous le "parallélisme"? Le multithreading est une implémentation concrète du concept d'exécution de programme parallèle.
L'article auquel RichardOD a lié semble se préoccuper principalement de savoir si les threads sont réellement exécutés en parallèle sur une machine à béton.
Cependant, votre question semble voir le multithreading et le parallélisme comme des opposés. Voulez-vous peut-être dire des programmes qui utilisent plusieurs processus plutôt que plusieurs threads? Si tel est le cas, les différences sont:
- Les threads sont beaucoup moins chers à créer que les processus. C'est pourquoi l'utilisation de threads plutôt que de processus a entraîné une énorme accélération des applications Web - cela s'appelait "FastCGI".
- Plusieurs threads sur la même machine ont accès à la mémoire partagée. Cela rend la communication entre les threads beaucoup plus facile, mais aussi très dangereuse (il est facile de créer des bogues comme des conditions de concurrence qui sont très difficiles à diagnostiquer et à corriger).