voici quelques Pour / Contre que j'ai inventé.

Multiprocessing

Pros

• espace de mémoire séparé
• Code est généralement simple
• tire avantage de plusieurs CPU et cœurs
• evites Gil limitations for cPython
• élimine la plupart des besoins pour les primitives de synchronisation sauf si vous utilisez la mémoire partagée (au lieu de cela, c'est plutôt un modèle de communication pour la CIB)
• les processus enfants sont interruptibles /tuables
• Python multiprocessing module comprend utile abstractions avec une interface un peu comme le threading.Thread
• Un must avec de disponible pour le PROCESSEUR de traitement liés

Cons

• IPC un peu plus compliqué avec plus de frais généraux (modèle de communication vs partagé mémoire / objets)
• large memory footprint

Threading

Pros

• léger-faible encombrement mémoire
• mémoire partagée - facilite l'accès à l'État à partir d'un autre contexte
• vous permet de facilement faire UIS responsive
• les modules d'extension de cPython C qui libèrent correctement la GIL seront exécutés en parallèle
• Excellente option pour les e/S des applications

Cons

• disponible - sous réserve de l'GIL
• non interruptible / killable
• si l'on ne suit pas un modèle de pompe à commandes/messages (en utilisant le module Queue ), alors l'utilisation manuelle de primitives de synchronisation devient une nécessité (des décisions sont nécessaires pour la granularité du verrouillage)
Le Code
• est généralement plus difficile à comprendre et à corriger - le potentiel pour les conditions de course augmente de façon spectaculaire

la tâche de Threading est de permettre aux applications d'être réceptives. Supposons que vous ayez une connexion à une base de données et que vous ayez besoin de répondre à l'entrée de l'utilisateur. Sans filetage, si la connexion à la base de données est occupée, l'application ne pourra pas répondre à l'utilisateur. En séparant la connexion de la base de données en un thread séparé, vous pouvez rendre l'application plus réactive. Aussi parce que les deux threads sont dans le même processus, ils peuvent accéder aux mêmes structures de données - une bonne performance, plus un conception de logiciel flexible.

notez qu'en raison de la GIL l'application ne fait pas deux choses à la fois, mais ce que nous avons fait est de mettre le verrou des ressources sur la base de données dans un thread séparé de sorte que le temps CPU peut être commuté entre elle et l'interaction de l'utilisateur. Le temps CPU est rationné entre les fils.

Multiprocessing est pour les temps où vous voulez vraiment plus d'une chose à faire à un moment donné. Supposons que votre application doit connectez-vous à 6 bases de données et effectuez une transformation matricielle complexe sur chaque ensemble de données. Mettre chaque tâche dans un thread séparé pourrait aider un peu parce que quand une connexion est inutilisée une autre connexion pourrait obtenir un certain temps CPU, mais le traitement ne serait pas fait en parallèle parce que la GIL signifie que vous utilisez seulement les ressources d'un CPU. En mettant chaque tâche dans un processus de Multiprocessing, chacun peut exécuter sur son propre CPU et exécuter à pleine efficacité.

Le principal avantage est l'isolement. Un processus qui s'écrase ne détruira pas d'autres processus, alors qu'un fil qui s'écrase fera probablement des ravages avec d'autres fils.

une autre chose qui n'est pas mentionnée, c'est que cela dépend du système D'exploitation que vous utilisez en ce qui concerne la vitesse. Dans les processus Windows sont coûteux de sorte que les threads seraient meilleurs dans windows, mais dans les processus unix sont plus rapides que leurs variantes de windows, donc l'utilisation de processus dans unix est beaucoup plus sûr et rapide à pondre.

D'autres réponses se sont davantage concentrées sur l'aspect multithreading vs multiprocessing, mais en Python Global Interpreter Lock ( GIL ) doit être pris en compte. Lorsque plus de nombre (dites k ) de threads sont créés, généralement ils n'augmenteront pas la performance de k fois, car il sera encore en cours d'exécution comme une seule application filetée. GIL est une serrure globale qui bloque tout et ne permet qu'un seul thread exécution utilisant un seul noyau. La performance augmente dans les endroits où les extensions C comme numpy, Network, I/O sont utilisées, où beaucoup de travail de fond est fait et GIL est libéré.

Ainsi, lorsque threading est utilisé, il n'y a qu'un seul thread au niveau du système d'exploitation alors que python crée des pseudo-threads qui sont entièrement gérés par threading lui-même mais qui sont essentiellement exécutés comme un seul processus. La préemption a lieu entre ces pseudo threads. Si le CPU fonctionne à la capacité maximale, vous pouvez passer à multiprocesseur.

Maintenant, en cas d'instances autonomes d'exécution, vous pouvez opter pour pool. Mais en cas de chevauchement de données, vous souhaitez processus communiquant, vous devez utiliser multiprocessing.Process .

comme mentionné dans la question, Multiprocessing en Python est le seul moyen réel pour atteindre le vrai parallélisme. multicouche ne peut pas atteindre cet objectif car le GIL empêche les fils de fonctionner en parallèle.

par conséquent, le threading peut ne pas toujours être utile en Python, et en fait, peut même entraîner des performances plus mauvaises selon ce que vous essayez de réaliser. Par exemple, si vous sont en train d'effectuer une tâche liée au CPU telle que la décompression de fichiers gzip ou le rendu 3D (quelque chose d'intensif en CPU), alors le filetage peut en fait nuire à vos performances plutôt qu'aider. Dans un tel cas, vous voudriez utiliser Multiprocessing car seule cette méthode fonctionne réellement en parallèle et aidera à distribuer le poids de la tâche en main. Il pourrait y avoir des frais généraux à cela puisque Multiprocessing implique la copie de la mémoire d'un script dans chaque sous-processus qui peut causer des problèmes pour les applications de plus grande taille.

Toutefois, Multithreading devient utile lorsque votre tâche est IO-lié . Par exemple , si la plus grande partie de votre tâche consiste à attendre API-calls , vous utiliserez Multithreading parce que pourquoi ne pas démarrer une autre requête dans un autre thread pendant que vous attendez, plutôt que de laisser votre CPU en attente.

TL; DR

• Multithreading est concomitante et est utilisé pour IO-lié tâches
• Multiprocessing atteint un vrai parallélisme et est utilisé pour CPU-bound tasks

peut avoir plusieurs threads. Ces fils peuvent partager de la mémoire et sont les unités d'exécution au sein d'un processus.

fonctionnent sur le CPU, donc les threads résident sous chaque processus. Les processus sont des entités individuelles qui fonctionnent indépendamment. Si vous souhaitez partager des données ou un État entre chaque processus, vous pouvez utiliser un outil de stockage en mémoire tel que Cache(redis, memcache) , Files , ou un Database .