Quels types d'applications doivent être multi-threadées?
Quels sont quelques exemples concrets des applications qui doivent être multi-threadées, ou n'ont pas besoin de l'être, mais sont beaucoup mieux de cette façon?
les réponses seraient meilleures si sous la forme d'une application par poste de cette façon le plus applicable flottera vers le haut.
14 réponses
Il n'y a pas de réponse dure et rapide, mais la plupart du temps vous ne verrez aucun avantage pour les systèmes où le flux de travail/calcul est séquentiel. Si toutefois le problème peut être décomposé en tâches qui peuvent être exécutées en parallèle (ou le problème lui-même est massivement parallèle [comme certains problèmes mathématiques ou analytiques sont]), vous pouvez voir de grandes améliorations.
si votre matériel cible est un processeur/cœur unique, vous ne verrez probablement aucune amélioration avec des solutions multi-threadées (comme il y a un seul thread à la fois de fonctionner de toute façon!)
écrire du code multi-threadé est souvent plus difficile car vous pourriez avoir à investir du temps dans la création de la logique de gestion de thread.
Quelques exemples
- traitement D'Image peut souvent être fait en parallèle (par exemple, diviser l'image en 4 et faire le travail en 1/4 du temps) mais cela dépend de l'algorithme exécuté pour voir si cela a du sens.
- Rendu de l'animation (à partir de 3DMax, etc.) est massivement parallèle car chaque image peut être rendue indépendamment à d'autres -- ce qui signifie que 10 ou 100 ordinateurs peuvent être enchaînés ensemble pour aider.
- GUI la programmation aide souvent à avoir au moins deux threads quand on fait quelque chose de lent, par exemple le traitement d'un grand nombre de fichiers - cela permet à l'interface de rester réactive pendant que le travailleur fait le travail dur (en C# le BackgroundWorker est un exemple de cet)
les interfaces graphiques sont un domaine intéressant car la "réactivité" de l'interface peut être maintenue sans multi-threading si l'algorithme worker garde l'interface graphique principale "vivante" en lui donnant du temps, en termes D'API Windows (avant .NET, etc) cela pourrait être réalisé par une boucle primitive et pas besoin de threading:
MSG msg;
while(GetMessage(&msg, hwnd, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
// do some stuff here and then release, the loop will come back
// almost immediately (unless the user has quit)
}
Serveurs sont typiquement multi-threadés (serveurs web, serveurs radius, serveurs e-mail, n'importe quel serveur): vous voulez généralement être capable de traiter plusieurs requêtes simultanément. Si vous ne voulez pas attendre une demande à la fin avant de commencer à traiter une nouvelle demande, alors vous avez essentiellement deux options:
- Exécuter un processus avec plusieurs threads
- Exécuter plusieurs processus
le lancement d'un processus exige habituellement plus de ressources que de lancer un thread (ou d'en choisir un dans un thread-pool), les serveurs sont généralement multi-threadés. De plus, les fils peuvent communiquer directement puisqu'ils partagent le même espace mémoire.
le problème avec les threads multiples est qu'ils sont généralement plus difficiles à coder à droite que les processus multiples.
il y a vraiment trois catégories de raisons pour lesquelles la lecture multiple serait appliquée:
- Exécution de la Simultanéité pour améliorer les performances de calcul: si vous avez un problème qui peut être décomposé en morceaux et que vous avez aussi plus d'une unité d'exécution (noyau du processeur) disponible, alors l'envoi des morceaux en threads séparés est le chemin pour pouvoir utiliser simultanément deux ou plusieurs cœurs à la fois.
- simultanéité de CPU et IO Les opérations: ceci est similaire dans la pensée à la première mais dans ce cas l'objectif est de maintenir le CPU occupé et aussi les opérations IO (I/O de disque) se déplaçant en parallèle plutôt qu'en alternance entre elles.
- conception du programme et réactivité: de nombreux types de programmes peuvent profiter du filetage comme avantage de conception de programme pour rendre le programme plus sensible à l'utilisateur. Par exemple, le programme peut interagir via L'interface graphique et aussi faire quelque chose fond.
Exemples Concrets:
- Microsoft Word: modifiez le document pendant que la grammaire d'arrière-plan et le correcteur orthographique fonctionnent pour ajouter tout le grincement vert et rouge souligne.
- Microsoft Excel: recalcul automatique de l'arrière-plan après modification des cellules
- Navigateur Web: envoi de plusieurs threads pour charger chacune des plusieurs références HTML en parallèle lors d'un chargement de page unique. Vitesse page charge et maximise le débit de données TCP/IP.
de nos jours, la réponse devrait être Toute application qui peut être.
la vitesse d'exécution pour un seul thread a atteint un sommet il y a à peu près des années - les processeurs ont été plus rapides en ajoutant des noyaux, pas en augmentant les vitesses d'horloge. Il y a eu quelques améliorations architecturales qui font une meilleure utilisation des cycles d'horloge disponibles, mais vraiment, l'avenir profite de filetage.
Il y a une tonne de recherches en trouvant des moyens de paralléliser des activités que nous n'avons pas l'habitude de mettre en parallèle. Même quelque chose d'aussi simple que trouver un substrat dans une chaîne peut être parallélisé.
fondamentalement, il y a deux raisons à la multi-thread:
pouvoir effectuer des tâches de traitement en parallèle. Cela ne s'applique que si vous avez plusieurs cœurs/processeurs, sinon sur un seul noyau/ordinateur processeur vous ralentirez la tâche par rapport à la version sans threads.
I/O qu'il s'agisse d'une entrée/sortie en réseau ou d'une entrée/sortie en fichier.Normalement, si vous appelez une entrée/sortie de blocage, le processus doit attendre que l'appel soit terminé. Depuis le processeur / mémoire sont plusieurs ordres de grandeur plus rapide qu'un lecteur de disque (et un réseau est encore plus lent) cela signifie que le processeur sera en attente un long moment. L'ordinateur travaillera sur d'autres choses, mais votre application ne fera aucun progrès. Cependant, si vous avez plusieurs threads, l'ordinateur va programmer votre application et les autres threads peuvent exécuter. Une utilisation courante est une application GUI. Alors pendant que l'application fait I/O le fil GUI peut garder rafraîchissant le écran sans ressembler à l'application est gelée ou ne répond pas. Même sur un seul processeur mettre l'E/S dans un thread différent aura tendance à accélérer l'application.
l'alternative filetée simple à 2 est d'utiliser des appels asynchrones où ils reviennent immédiatement et vous continuez à contrôler votre programme. Ensuite, vous devez voir quand l'E/S complète et gérer l'utilisation. Il est souvent plus simple d'utiliser juste un thread pour faire l'e/s en utilisant les appels synchrones comme ils tendent pour être plus facile.
la raison d'utiliser des threads au lieu de processus séparés est que les threads devraient être capables de partager des données plus facilement que plusieurs processus. Et parfois, passer d'un filetage à l'autre coûte moins cher que de passer d'un processus à l'autre.
comme autre note, pour #1, les threads Python ne fonctionneront pas car en Python, une seule instruction python peut être exécutée à la fois (connue sous le nom de Gil ou Global Interpreter Lock). Je l'utilise comme exemple mais vous devez vérifier autour de votre langue. En python si vous voulez faire des calculs parallèles, vous devez faire des processus distincts.
de nombreux cadres GUI sont multi-threadés. Cela vous permet d'avoir une interface plus réactive. Par exemple, vous pouvez cliquer sur le bouton "Annuler" à tout moment pendant qu'un long calcul est en cours.
notez Qu'il existe d'autres solutions pour cela (par exemple le programme peut suspendre le calcul toutes les demi-secondes pour vérifier si vous avez cliqué sur le bouton Annuler ou non), mais elles n'offrent pas le même niveau de réactivité (L'interface graphique peut sembler geler pendant quelques secondes pendant qu'un fichier est lu ou qu'un calcul est fait).
toutes les réponses jusqu'à présent se concentrent sur le fait que le multi-threading ou le multi-processing sont nécessaires pour faire le meilleur usage du matériel moderne.
il y a cependant aussi le fait que le multithreading peut rendre la vie beaucoup plus facile au programmeur. Au travail, je programme des logiciels pour contrôler les équipements de fabrication et d'essai, où une seule machine se compose souvent de plusieurs positions qui fonctionnent en parallèle. Utiliser plusieurs threads pour ce type de logiciel est un ajustement naturel, les fils parallèles modèlent assez bien la réalité physique. Les threads n'ont généralement pas besoin d'échanger des données, de sorte que le besoin de synchroniser les threads est rare, et de nombreuses raisons pour lesquelles le multithreading est difficile ne s'appliquent donc pas.
Edit:
il ne s'agit pas vraiment d'une amélioration de la performance, car les fils (peut-être 5, peut-être 10) dorment tous la plupart du temps. Il s'agit toutefois d'une amélioration considérable pour la structure du programme lorsque les différents processus parallèles peut être codé comme des séquences d'actions qui ne se connaissent pas. J'ai de très mauvais souvenirs de L'époque des fenêtres de 16 bits, quand je créais une machine d'État pour chaque position de machine, m'assurer que rien ne prendrait plus de quelques millisecondes, et passer constamment le contrôle à la machine d'état suivante. Quand il y avait des événements matériels qui devaient être révisés à temps, et aussi des calculs qui ont pris un certain temps (comme FFT), alors les choses devenaient laides très vite.
ne répondant pas directement à votre question, je crois que dans un avenir très proche, presque toutes les applications devront être multithreaded. La performance CPU ne croît pas aussi vite ces jours-ci, ce qui est compensé par le nombre croissant de noyaux. Ainsi, si nous voulons que nos applications restent au niveau de la performance supérieure, nous aurons besoin de trouver des moyens d'utiliser tous les CPU de votre ordinateur et de les garder occupés, ce qui est un travail assez difficile.
ceci peut être fait via raconter vos programmes de quoi faire plutôt que de leur dire exactement comment. Maintenant, c'est un sujet que je trouve personnellement très intéressant récemment. Certains langages fonctionnels, comme F#, sont capables de paralléliser très facilement de nombreuses tâches. Eh bien, pas si facilement, mais encore sans l'infrastructure nécessaire nécessaire dans des environnements plus procéduraux.
veuillez considérer cela comme une information supplémentaire à prendre en considération, et non comme une tentative de répondre à votre question.
Le genre d'applications que besoin pour être enfilée sont ceux où vous voulez le faire plus d'une chose à la fois. À part cela, aucune application ne doit être multi-threadée.
Applications avec une charge de travail importante qui peut être facilement rendue parallèle. Il ne faut pas sous-estimer la difficulté d'accepter votre demande et de le faire. Il est facile quand vos données que vous manipulez ne dépend pas d'autres données mais v. difficile de programmer le travail de thread croisé quand il y a une dépendance.
quelques exemples que j'ai faits qui sont de bons candidats multithread..
- scénarios courants (par exemple, prix des dérivés d'actions), les statistiques)
- mise à jour en bloc des fichiers de données (par exemple, ajout d'une valeur / entrée à 10 000 enregistrements)
- autres procédés mathématiques
modifier: utiliser plusieurs processus est la même chose. La technique à utiliser dépend de la plateforme et de la façon dont vous allez communiquer au sein de votre programme, etc.
bien que frivoles, les jeux, en général, deviennent de plus en plus filetés chaque année. Au travail notre jeu utilise environ 10 fils faisant la physique, AI, animation, redering, réseau et IO.
je veux juste ajouter que la prudence est de mise avec les treads si votre partage de ressources peut conduire à un comportement très étrange, et que votre code ne fonctionne pas correctement ou même que les threads se bloquent mutuellement.
mutex vous y aidera car vous pouvez utiliser les serrures mutex pour les régions de code protégées, un exemple de régions de code protégées serait la lecture ou l'écriture à la mémoire partagée entre les threads.
juste mes 2 cents.
le but principal de la multithreading est pour séparer les domaines temporels. Si les utilisations sont partout où vous voulez plusieurs choses dans leurs propres distinctes temps de domaines.