Je ne veux pas faire ce subjectif ...
Si des E / S et d'autres goulots d'étranglement liés à l'entrée / sortie ne sont pas préoccupants, alors avons-nous besoin d'écrire du code multithreadé? Théoriquement, le code fileté unique sera meilleur que cela obtiendra tous les cycles de la CPU. À droite?
JavaScript ou ActionScript a-t-il fait de mieux, avaient-ils été multipliés?
J'essaie simplement de comprendre le besoin réel de multithreading.
11 Réponses :
Je ne sais pas si vous avez prêté une attention particulière aux tendances du matériel récemment (5 dernières années), mais nous nous dirigeons vers un monde multicœur.
Un appel de réveil général était cette "Le déjeuner gratuit est terminé" article.
sur un PC Dual Core, une application à une seule-filetée obtiendra uniquement la moitié des cycles de la CPU. Et les CPU ne deviennent plus plus rapides, cette partie de la loi Moores est morte.
C'est la seule raison pour laquelle je puisse penser pourquoi le code devrait être multiplié. Suis-je correct dans mon hypothèse?
Pas vraiment, sur un seul noyau, vous utilisez le filetage pour faire des E / S parallèle. Sur les multicores, vous souhaitez également calculer en parallèle.
La loi de Moore ne concerne que la densité des transistors sur une puce. Il semblait s'appliquer à la vitesse car les transistors ont augmenté plus rapide car ils ont augmenté, jusqu'à ce que les retards d'interconnexion soient dominants. Plusieurs cœurs sont une augmentation du nombre de transistors, la loi de Moore est donc toujours en vigueur.
AW HENK! Maintenant, on dirait que je viens de copier votre réponse (concernant le "déjeuner gratuit") ... Je serai coincé avec une mauvaise réputation, je suppose :)
@HANK: Bon point. Les gens oublient que les périphériques d'E / S, qui pourraient même être considérés comme leurs propres "cœurs" (en particulier avec des GPU ces jours-ci peuvent bloquer un processus aussi bien qu'un autre processus pourrait.
@Mike Vous êtes très correct, formellement. Mais la loi Moores est fréquemment confondue avec l'augmentation de la vitesse.
@Mike je me trompe peut-être, mais n'est-ce pas votre premier commentaire contradictoire? Il y a une très grande différence entre le nombre et la densité.
"Sur un PC Dual Core, une application à une seule filetée n'aura que la moitié des cycles de la CPU." - Pas si vous exécutez plusieurs applications liées à la CPU. L'autre moitié de la CPU sera assez bien utilisée. Toutes les applications ne doivent pas être multipliées pour une bonne expérience utilisateur dans leur environnement s'ils fonctionnent plus d'une application à la fois.
@WildDuck: Lorsque vous gardez la zone constante, il existe une corrélation directe entre la densité et le nombre.
@JESSE: L'autre noyau (s) ne doit pas nécessairement être inactif, mais une application à une seule-filetée ne gagne définitivement que 1 / N des cycles (au mieux).
@JESSE: Cela n'aide pas lorsque vous souhaitez exécuter un processus particulier le plus rapidement possible. Le threading unique dans un environnement multicore peut fonctionner très bien sur un serveur, mais pas nécessairement sur un bureau.
Henk, combien de demandes du monde réel peuvent vraiment être blessées en obtenant seulement 50% des cycles de la CPU? (ou 1% des cycles du processeur?) La réponse: très peu. La plupart des applications sur mon PC sont UI ou IO-liées ou pire, leur performance est souvent limitée par des serrures mal utilisées ou un manque d'aptitudes ASYNC IO du développeur - ce qui ne les fait pas deux fois, mais comme mille fois moins réactif. De toutes les applications de consommation, je peux penser, seuls WinRar et Word SpellChecker pourraient bénéficier de manière intrinsèquement bénéfique d'un processeur supplémentaire.
@Pavel: Dans mes applications, 90% ou plus est également E / S ou utilisateur de l'utilisateur. Mais il y a des rapports et des pièces de calcul qui sont liées à la CPU et utilisées pour profiter, dans le passé, d'un matériel plus rapide. Maintenant, vous devrez utiliser le parallélisme.
Dans les mots de Herb Sutter Le déjeuner gratuit est terminé , c'est-à-dire Le chemin de performance futur pour l'informatique sera en termes de plus de noyaux pas d'horloges non supérieures. La chose est que l'ajout d'autres cœurs n'abordent généralement pas la performance du logiciel qui n'est pas multithreadé, et même il dépend entièrement de l'utilisation correcte des techniques de programmation multithreadées, d'où la multiplication est une grosse affaire.
Une autre raison évidente consiste à maintenir une interface graphique réactive, quand par ex. Un clic de bouton initie des calculs substantiels ou des opérations d'E / S pouvant prendre un certain temps, car vous soulignez vous-même.
Dans le passé, j'étais un peu plus curieux du matériel que je suis aujourd'hui. Je me souviens de la course entre AMD et Intel à la première puce de 1 GHz (compatible X86). C'était 2000 et 10 ans plus tard, il semble que nous sommes à 2 ou 3 GHz.
Les guerres des GHz ont assez fini lorsque l'Intel a trouvé (sur le Pentium 4) qui poussant à 4 GHz et au-delà n'en valait pas la peine. (Les seules personnes qui auraient pu utiliser un refroidissement liquide.) AMD pourrait obtenir des performances comparables à la moitié de la vitesse et moins de pouvoir en faisant simplement plus d'informations par cycle d'horloge. Il m'amuse que, aujourd'hui, les tables semblent avoir tournées, avec Intel étant plus efficace de pouvoir et les jetons d'AMD fonctionnent à 125 w ...
Sur le PC, je suppose également que la montée des GPU a fait son rôle dans l'obscurcissement des consommateurs moyens se concentre sur GHz.
J'ai un chasseur que, car les cœurs de la CPU continuent d'augmenter, GPU deviendra une chose du passé ... Après tout, ils sont fondamentalement des tonnes de noyaux supplémentaires avec leur propre mémoire.
@RMeAdor: Je suis en désaccord, les graphiques sont massivement parallèles et, d'où le GPU parallèle inhérent, continuera d'avoir l'avantage que je pense
@RMeAdor: Nah, GPU, il existera toujours bien qu'ils puissent être absorbés dans le noyau de la CPU lui-même et devenir une sorte de coprocesseur de vecteur de point flottant.
Une grande partie du multithreading se fait simplement pour faciliter le modèle de programmation lorsque vous effectuez des opérations de blocage tout en maintenant une concurrence dans le programme - Parfois, les langues / bibliothèques / API vous donnent peu d'autre choix, sinon les alternatives rendent le modèle de programmation trop difficile et évacué par erreur. .
Autre que le principal avantage de la multi-threading est de tirer parti de plusieurs processeurs / cœurs - un thread ne peut fonctionner que sur un processeur / noyau à la fois.
non. Vous ne pouvez pas continuer à gagner les nouveaux cycles de la CPU, car ils existent sur un noyau différent et le noyau que votre application à une seule fois filetée n'existe pas de ne pas être plus rapide. Une application multi-threadé, d'autre part, bénéficiera d'un autre noyau. Le code parallèle bien écrit peut aller jusqu'à 95% plus rapidement - sur un double noyau, qui est tous les nouveaux processeurs au cours des cinq dernières années. C'est le double que encore une fois pour un quad noyau. Donc, tandis que votre application à une seule fois fileté ne reçoit aucun cycles qu'il y a cinq ans, mon application quadriphe a quatre fois plus nombreuses et qui dépassent considérablement la vôtre en termes de temps de réponse et de performances.
Votre question serait valable si nous n'avions que des noyaux célibataires. Les choses sont cependant, nous avons principalement des CPU multicœurs ces jours-ci. Si vous avez un quadcore et écrivez un seul programme fileté, vous aurez trois noyaux qui ne sont pas utilisés par votre programme.
Donc, en fait, vous aurez au maximum 25% des cycles du processeur et non à 100%. Étant donné que la technologie doit aujourd'hui ajouter plus de noyaux et moins d'horloge, le filetage sera de plus en plus crucial pour la performance.
La principale raison que j'utilise multithreading ces jours-ci est de garder l'interface utilisateur réactive pendant que le programme fasse quelque chose de temps. Bien sûr, ce n'est pas de haute technologie, mais il garde les utilisateurs heureux: -)
+1, multi-threading est utile pour la même raison que multi-tâches entre les processus. Parfois, il est logique que les opérations se produisent en parallèle et que les utilisateurs n'aiment pas avoir leur travail interrompu s'ils peuvent continuer à faire des choses en attendant une opération de consommation de temps. Le fait que les processeurs multicœurs deviennent de plus en plus courants constituent une avantage secondaire supplémentaire, bien que cela ajoute également de nouvelles complications (car il permet de contourner les conditions de raccordement dans des conditions défectueuses de figurer qui étaient auparavant évitées sur les PC à une seule noyau.)
C'est un peu comme demander si un tournevis est nécessaire si je n'ai besoin que de conduire cet ongle. Multhreading est un autre outil dans votre boîte à outils à utiliser dans des situations pouvant en bénéficier. Ce n'est pas nécessairement approprié dans chaque situation de programmation.
La plupart des processeurs de ces jours sont multi-noyau. Mettre simplement, cela signifie qu'ils ont plusieurs processeurs sur la même puce.
Si vous n'avez qu'un seul thread, vous ne pouvez utiliser que l'un des cœurs - les autres noyaux seront inactifs ou être utilisés pour d'autres tâches qui fonctionnent. Si vous avez plusieurs threads, chacun peut fonctionner sur son propre noyau. Vous pouvez diviser votre problème en parties X et, en supposant que chaque pièce puisse fonctionner de manière indépendante, vous pouvez terminer les calculs à proximité de 1 / xème du temps qu'il faudrait normalement.
Par définition, l'algorithme le plus rapide en parallèle dépensera au moins autant de temps de processeur que l'algorithme séquentiel le plus rapide - c'est-à-dire que la parallélisation ne diminue pas la quantité de travail requise - mais le travail est distribué dans plusieurs unités indépendantes, menant à une diminution de la réalité consacrée à la résolution du problème. Cela signifie que l'utilisateur n'a pas à attendre aussi longtemps pour la réponse, et ils peuvent se déplacer plus rapidement.
Il y a 10 ans, lorsque Multi-Core n'était pas avéi, alors c'est vrai: vous ne gagneriez rien si nous ignorons les retards d'E / S, car il n'y avait qu'une seule unité pour effectuer l'exécution. Cependant, la course à augmenter les vitesses d'horloge s'est arrêtée; Et nous sommes plutôt en train de regarder multi-noyau pour augmenter la quantité de pouvoir informatique disponible. Avec des entreprises telles que Intel en regardant des processeurs de 80 cœurs, il devient de plus en plus important que vous examiniez la parallélisation afin de réduire le temps à résoudre un problème - si vous n'avez qu'un seul thread, vous ne pouvez utiliser qu'un noyau et l'autre 79 Les cœurs feront autre chose au lieu de vous aider à finir plus tôt.
Voici quelques réponses:
Donc en bref, oui, il existe des applications qui n'ont pas besoin de multithreading, mais elles sont assez rares et deviennent plus rares.
Premièrement, les processeurs modernes ont plusieurs cœurs, donc une seule arrache ne recevra jamais tous les cycles de la CPU. Sur un système Dualcore, un seul thread n'utilisera que la moitié de la CPU. Sur un processeur de 8 noyau, cela n'utilisera que 1 / 8ème.
Donc, d'un point de vue de performance brut, vous avez besoin de plusieurs threads pour utiliser la CPU.
Au-delà de cela, certaines tâches sont également plus faciles à exprimer à l'aide de multithreading.
Certaines tâches sont indépendantes de manière conceptuelle, et il est donc plus naturel de les coder comme des threads distincts fonctionnant en parallèle, que d'écrire une application singletéheadée qui entra les deux tâches et les commutateurs entre eux si nécessaire.
Par exemple, vous voulez généralement que l'interface graphique de votre application reste réactive, même si vous appuyez sur un bouton, un processus de travail lourd-lourd de la CPU pouvant aller pendant plusieurs minutes. À cette époque, vous voulez toujours que l'interface graphique fonctionne. Le moyen naturel d'exprimer ceci est de mettre les deux tâches dans des threads distincts.
La plupart des réponses ici font la conclusion Bien sûr, si les lignes d'exécution simultanées (threads ou procédés) doivent fonctionner sur les données communes, les threads ont un avantage. Mais c'est aussi la raison principale des maux de tête avec des threads. Un tel programme peut-il être conçu de sorte que les pièces soient aussi autonomes et indépendantes que possible, afin que nous puissions utiliser des processus? Encore une fois, un problème d'architecture logicielle.
Je spéculerais que le multi-threading est aujourd'hui ce que la gestion de la mémoire était à l'époque de C:
Enfin, vous pouvez trouver Cet article intéressant (suivez ce premier lien sur le page). J'avoue que je n'ai lu que l'abstrait, cependant. Multicore => Multhreading Inevitable. Cependant, il existe une autre façon d'utiliser plusieurs processeurs - multi-traitement . Sur Linux, surtout, où, afaik, les threads sont mis en œuvre comme des processus seulement avec certaines restrictions, et les processus sont peu coûteux, par opposition à Windows, il y a de bonnes raisons pour éviter des raisons multiples. Donc, il existe des problèmes d'architecture logicielle ici qui ne devraient pas être négligés.
Il existe un interprète JavaScript installé sur à peu près tous les ordinateurs consommateurs du monde. Vous pourriez faire valoir que c'est la langue la plus réussie jamais écrite. Il est difficile de voir comment cela pourrait avoir "taillé mieux".
L'argument à cela est plus de "politique d'adoption" que d'être la meilleure langue. Le premier moteur JavaScript expédié de Netscape était de loin inférieur à celui de «Text / Perl», mais ils ont réussi à l'obtenir dans le navigateur et de l'expédier en premier.
Vous réalisez que les ordinateurs modernes viennent à peu près avec plusieurs processeurs, non?
Liée à cette question Pourquoi la loi de Moore nécessite-t-elle l'informatique parallèle?