Pourquoi les gens utilisent-ils les GPU pour les calculs de haute performance au lieu d'une puce plus spécialisée ?

Plus précisément, les GPU ne sont pas des "cœurs" au sens du "parallélisme des tâches". La plupart du temps, ils se présentent sous la forme d'un "parallélisme de données". SIMD signifie "single instruction multiple data". Ce que cela signifie, c'est que vous ne feriez pas cela :

for parallel i in range(0,1024): c[i] = a[i] * b[i]

Cela signifie que vous avez 1024 pointeurs d'instruction qui effectuent tous des tâches distinctes progressant à des rythmes différents. Le SIMD, ou "calcul vectoriel", exécute des instructions sur des tableaux entiers en une seule fois, comme ceci :

c = a * b

Les "boucles" se trouvent dans les instructions "*" et "=", plutôt qu'en dehors des instructions. Ce qui précède le ferait pour tous les 1024 éléments en même temps, avec le MÊME pointeur d'instruction pour chacun d'entre eux. C'est comme avoir trois énormes registres pour a, b et c. Le code SIMD est extrêmement contraint et ne fonctionne bien que pour les problèmes qui ne sont pas excessivement "branchés".

Dans des cas réalistes, ces valeurs SIMD ne sont pas aussi grandes que 1024 éléments. Imaginez une variable qui est un groupe de int32 liés ensemble. Vous pouvez considérer la multiplication et l'affectation comme une véritable instruction machine.

int32_x64 c; int32_x64 b; int32_x64 a; c = b * a;

Les vrais GPU sont plus compliqués que les SIMD, mais c'est leur essence même. C'est pourquoi vous ne pouvez pas simplement jeter un algorithme aléatoire du CPU sur un GPU et espérer un gain de vitesse. Plus l'algorithme fait de branchements d'instructions, moins il est approprié pour un GPU.

Les autres réponses ici sont plutôt bonnes. Je vais également ajouter mon grain de sel.

L'une des raisons pour lesquelles les processeurs sont devenus si répandus est leur flexibilité. Vous pouvez les reprogrammer pour une variété infinie de tâches. De nos jours, il est moins cher et plus rapide pour les entreprises qui fabriquent des produits de placer une petite unité centrale ou un microcontrôleur dans un objet et de programmer sa fonctionnalité que de développer des circuits personnalisés pour effectuer la même tâche.

En utilisant le même appareil que les autres, vous pouvez profiter des solutions connues aux problèmes utilisant ce même appareil (ou un appareil similaire). Et à mesure que la plate-forme mûrit, vos solutions évoluent et deviennent très matures et optimisées. Les personnes qui codent sur ces appareils acquièrent également une expertise et deviennent très compétentes dans leur domaine.

Si vous deviez créer un nouveau type d'appareil à partir de zéro, une alternative au GPU, il faudrait des années pour que même les premiers utilisateurs sachent l'utiliser. Si vous attachez un ASIC à votre CPU, comment optimiser le déchargement des calculs sur ce dispositif ?

La communauté de l'architecture informatique s'est emparée de cette idée depuis plusieurs années (elle a évidemment été populaire auparavant, mais elle a récemment connu une renaissance). Ces "accélérateurs" (c'est leur terme) sont reprogrammables à des degrés divers. Le problème est de savoir dans quelle mesure vous définissez l'étendue du problème que votre accélérateur peut résoudre. J'ai même parlé à des personnes qui travaillaient à la création d'un accélérateur utilisant des circuits analogiques avec des op-amps pour calculer des équations différentielles. Excellente idée, mais portée extrêmement étroite.

Une fois que vous avez un accélérateur qui fonctionne, ce sont les forces économiques qui vont décider de votre sort. L'inertie du marché est une force incroyable. Même si l'idée est géniale, est-il économiquement possible de remanier vos solutions existantes pour utiliser ce nouveau dispositif ? Peut-être, peut-être pas.

Les GPU sont en fait horribles pour certains types de problèmes, si bien que de nombreuses personnes/entreprises travaillent sur d'autres types de dispositifs. Mais les GPU sont déjà si bien implantés que leurs dispositifs deviendront-ils un jour économiquement viables ? Nous verrons bien.

Edit : Je développe un peu ma réponse, maintenant que je ne suis plus dans le bus.

Le projet Larrabee d'Intel constitue une étude de cas édifiante. Il s'agissait au départ d'un dispositif de traitement parallèle capable de réaliser des graphiques dans le logiciel ; il ne disposait pas de matériel graphique spécialisé. J'ai parlé avec quelqu'un qui a travaillé sur le projet, et une raison majeure pour laquelle ils ont dit qu'il a échoué et a été annulé (en plus de la politique interne horrible) était qu'ils ne pouvaient tout simplement pas obtenir le compilateur de produire un bon code pour lui. Bien sûr, il produisait du code fonctionnel, mais si le but de votre produit est d'obtenir des performances maximales, il vaut mieux avoir un compilateur qui produit un code optimal. Cela me ramène à mon commentaire précédent sur le fait que le manque d'expertise en matière de matériel et de logiciel pour votre nouvel appareil est un gros problème.

Certains éléments de la conception de Larrabee ont été intégrés dans le Xeon Phi/Intel MIC. Ce produit a effectivement été commercialisé. Il était entièrement axé sur la parallélisation des calculs scientifiques et autres calculs de type HPC. Il semble que ce soit un échec commercial à l'heure actuelle. Une autre personne avec qui j'ai parlé chez Intel a laissé entendre qu'ils n'étaient tout simplement pas compétitifs en termes de prix et de performances par rapport aux GPU.

Des personnes ont essayé d'intégrer la synthèse logique pour les FPGA dans les compilateurs, de sorte que vous puissiez générer automatiquement du code pour vos accélérateurs FPGA. Cela ne fonctionne pas très bien.

L'un des endroits qui semble être un sol vraiment fertile pour les accélérateurs, ou d'autres alternatives aux GPU, est le cloud. L'économie d'échelle qui existe dans ces grandes entreprises comme Google, Amazon et Microsoft fait qu'il vaut la peine d'investir dans des systèmes de calcul alternatifs. Quelqu'un a déjà mentionné les unités de traitement tensor de Google. Microsoft dispose de FPGA et d'autres éléments dans ses infrastructures Bing et Azure. Même chose pour Amazon. C'est absolument logique si l'échelle peut compenser votre investissement en temps, en argent et en larmes d'ingénieur.

En résumé, la spécialisation est en contradiction avec beaucoup d'autres choses (économie, maturité de la plateforme, expertise en ingénierie, etc.) La spécialisation peut améliorer considérablement vos performances, mais elle réduit le champ d'application de votre dispositif. Ma réponse s'est concentrée sur un grand nombre de points négatifs, mais la spécialisation présente également une tonne d'avantages. Elle doit absolument être poursuivie et étudiée, et comme je l'ai mentionné, de nombreux groupes la poursuivent de manière assez agressive.

Désolé, je modifie à nouveau : Je pense que votre prémisse initiale est fausse. Je pense qu'il s'agissait moins de rechercher des sources supplémentaires de puissance de calcul que de reconnaître une opportunité. La programmation graphique est très lourde en algèbre linéaire, et le GPU a été conçu pour effectuer efficacement des opérations courantes comme la multiplication de matrices, les opérations vectorielles, etc. Des opérations qui sont également très courantes dans le calcul scientifique.

L'intérêt pour les GPU a commencé au moment où les gens ont commencé à reconnaître que les promesses faites par le projet EPIC d'Intel/HP étaient largement exagérées (fin des années 90, début des années 2000). Il n'existait pas de solution générale pour la parallélisation des compilateurs. Ainsi, plutôt que de dire "où trouver plus de puissance de traitement, oh nous pourrions essayer le GPU", je pense que c'était plutôt "nous avons quelque chose qui est bon pour les calculs parallèles, pouvons-nous le rendre plus généralement programmable". Beaucoup de personnes impliquées faisaient partie de la communauté de l'informatique scientifique, qui disposait déjà de code Fortran parallèle qu'ils pouvaient exécuter sur des machines Cray ou Tera (Tera MTA avait 128 threads matériels). Peut-être y avait-il un mouvement dans les deux sens, mais je n'ai entendu parler des origines de GPGPU que dans ce sens.

Un ASIC (silicium personnalisé) est très rapide, mais sa conception et sa fabrication sont très coûteuses. Auparavant, les ASIC avaient un usage spécifique et l'unité centrale de traitement était une approche qui permettait de "programmer" les ordinateurs afin que les tâches informatiques puissent être exécutées par des logiciels. Les premiers CPU ont permis aux gens de profiter de la puissance de l'ASIC sans le coût énorme en programmant la puce sur le terrain. Cette approche a connu un tel succès qu'elle a donné naissance à l'ordinateur (très) rapide que vous utilisez actuellement.

Alors pourquoi les GPU ?

Au milieu des années 90, 3DFX a réalisé que les tâches de rendu 3D étaient si spécifiques qu'un ASIC personnalisé serait BEAUCOUP plus performant qu'un CPU. Ils ont créé un coprocesseur informatique qui déchargeait les tâches de rendu 3D du CPU vers ce coprocesseur, qu'ils ont baptisé "GPU". La concurrence et la demande du marché ont poussé l'innovation dans ce domaine jusqu'à ce que les GPU effectuent des calculs BEAUCOUP plus rapidement que les CPU. La question s'est alors posée : "Pourquoi ne puis-je pas utiliser le GPU pour calculer mes chiffres au lieu du CPU ?". Les fabricants de GPU y ont vu une demande et un moyen de gagner plus d'argent, ils ont donc commencé à modifier leurs plateformes pour permettre aux développeurs d'utiliser leur matériel. Mais le matériel était tellement spécifique qu'il y avait, et qu'il y a toujours, des limites à ce que l'on peut demander au GPU de faire. Je n'entrerai pas dans les détails de ces limitations ici.

Alors pourquoi n'y avait-il pas plus de silicium spécifique ? Pourquoi JUSTE le graphisme ?

Deux raisons : 1) Le prix. Les GPU avaient un bon marché, et pouvaient le justifier, mais même à l'époque, c'était un risque énorme. Personne ne savait vraiment si 3DFX pouvait faire des bénéfices (il s'est avéré qu'ils ne le pouvaient pas et qu'ils ont disparu). Même maintenant, avec la taille du marché des GPU, il n'y a vraiment que 3 concurrents. 2) Les CPU répondaient en fait au besoin de "silicium personnalisé" avec des extensions d'instructions. Repensez à MMX - c'était en fait la tentative d'Intel d'accélérer les graphiques dans le CPU au moment même où 3DFX prenait de la vitesse. Depuis lors, le jeu d'instructions x86 est devenu assez massif avec toutes ces extensions personnalisées. Beaucoup de ces extensions avaient un sens à l'époque (comme MMX), mais ne sont plus qu'un poids mort dans le processeur. Vous ne pouvez pas les supprimer, cependant, parce que cela casse les logiciels existants. C'est en fait l'un des arguments de vente de l'ARM - l'ARM est un jeu d'instructions dépouillé. Il n'y a pas autant d'extensions d'instructions, mais cela rend le silicium plus petit et moins cher à fabriquer.

Il me semble que vous pourriez gagner beaucoup d'argent si vous pouviez réduire le coût du silicium personnalisé. Personne ne travaille sur ce sujet ?

Il existe une technologie appelée FPGA (field programmable gate array), qui existe depuis les premiers jours de l'informatique. Il s'agit essentiellement d'une micro-puce que vous pouvez concevoir "sur le terrain" à l'aide d'un logiciel. C'est une technologie très cool, mais toute la structure nécessaire pour rendre la puce programmable occupe BEAUCOUP de silicium et fait que les puces fonctionnent à des vitesses d'horloge beaucoup plus faibles. Les FPGA PEUVENT être plus rapides que les CPU, si vous avez suffisamment de silicium sur la puce ET si vous pouvez paralléliser efficacement la tâche. Mais ils sont limités dans la quantité de logique que vous pouvez y mettre. Tous les FPGA, sauf les plus chers, étaient plus lents que les GPU pour les premiers minages de bitcoins, mais leurs équivalents ASIC ont effectivement mis fin à la rentabilité des minages par GPU. D'autres crypto-monnaies ont utilisé des algorithmes spécifiques qui ne peuvent pas être parallélisés, de sorte que les FPGA et les ASIC ne sont pas assez performants par rapport aux CPU et aux GPU pour justifier leur coût.

La principale limite des FPGA est la taille du silicium - quelle quantité de logique peut-on faire tenir sur la puce ? Le second est la vitesse d'horloge, car il est difficile d'optimiser des éléments tels que les points chauds, les fuites et la diaphonie dans un FPGA. Les nouvelles méthodes de fabrication ont permis de minimiser ces problèmes. Intel s'est associé à Altera pour fournir un FPGA qui peut être utilisé par les ingénieurs pour tirer parti des avantages du "silicium personnalisé" en tant que coprocesseur dans un serveur. C'est donc une réalité, dans un sens.

Les FPGA remplaceront-ils un jour les CPU et les GPU ?

Probablement pas de sitôt. Les derniers processeurs et GPU sont énormes et le silicium est très bien réglé pour les performances thermiques et électriques. Il est impossible d'optimiser les FPGA de la même manière qu'un ASIC personnalisé. À moins d'une technologie révolutionnaire, le CPU restera probablement le cœur de votre ordinateur avec des coprocesseurs FPGA et GPU.

En effet, il existe des cartes spécialisées pour le calcul à grande vitesse, par exemple Xilinx a une liste de 178 cartes PCI-e utilisant leurs FPGA, et environ un tiers de ces cartes sont des "croqueurs de chiffres" avec une ou plusieurs puces FPGA puissantes et beaucoup de mémoire DDR embarquée. Il existe également des cartes DSP hautes performances ( exemple ) visant les tâches de calcul à haute performance.

Je pense que la popularité des cartes GPU est due au fait qu'elles visent un groupe de clients plus large. Il n'est pas nécessaire d'investir dans du matériel spécial pour jouer avec Nvidia CUDA. Ainsi, lorsque vous aurez une tâche nécessitant du matériel spécial, les GPU Nvidia auront un avantage concurrentiel, car vous saurez déjà comment les programmer.

Je pense que la réponse à votre question dépend de la façon dont on définit le calcul à haute performance.

En général, la performance du calcul est liée au temps de calcul. Dans ce cas, j'aime bien partager le lien de grappe de calcul haute performance .

Le lien est spécifié la raison de l'utilisation du GPU ; L'utilisation de cartes graphiques (ou plutôt de leurs GPU) pour effectuer des calculs pour le calcul en grille est beaucoup plus économique que l'utilisation de CPU, bien qu'elle soit moins précise.