Quel avenir le GPU ont en informatique? [fermé]

Question

Votre CPU peut être un quad-core, mais saviez-vous que certaines cartes graphiques ont aujourd'hui plus de 200 cœurs? Nous avons déjà vu ce GPU dans les cartes graphiques d'aujourd'hui peut faire quand il s'agit de graphiques. Maintenant, ils peuvent être utilisés pour des tâches non graphiques aussi bien, et à mon avis, les résultats ne sont rien d'étonnant. Un algorithme qui se prête bien au parallélisme a le potentiel d'être beaucoup, beaucoup plus rapide sur un GPU que cela pourrait jamais être sur une unité centrale de traitement.

Il y a quelques technologies qui rendent tout cela possible:

1). CUDA par NVidia. Il semble être le plus connu et bien documenté. Malheureusement, ça ne fonctionne que sur les cartes vidéo NVidia. J'ai téléchargé le SDK, essayé quelques-uns des échantillons, et il y a des trucs génial qui se fait dans CUDA. Mais le fait qu'il est limité aux cartes NVidia me fait remettre en question son avenir.

2). flux par ATI. l'équivalent d'ATI à CUDA. Comme on pouvait s'y attendre, il ne fonctionnera que sur les cartes ATI.

3) OpenCL -. Le Khronos Group a mis en place cette standard, mais il est encore à ses premiers balbutiements. J'aime l'idée de OpenCL bien. L'espoir est qu'il devrait être pris en charge par la plupart des fabricants de cartes vidéo et devrait faire du développement de la carte croisée vidéo beaucoup plus facile.

Mais que d'autres technologies pour la programmation GPU non graphiques viennent et ce qui est la plus prometteuse? Et voyez-vous ou souhaitez-vous voir ces technologies en cours de construction dans certains des cadres de développement grand public comme .NET-il beaucoup plus facile?

Answer 1

Je prévois que cette technologie deviendra populaire et grand public, mais il faudra un certain temps de le faire. Je pense est d'environ 5 à 10 ans.

Comme vous l'avez noté correctement, un obstacle majeur à l'adoption de la technologie est l'absence d'une bibliothèque commune qui fonctionne sur la plupart des cartes - ATI et nVidia. Tant que ce problème résolu à un niveau acceptable, la technologie ne sera pas entrer mainstream et rester dans le créneau des applications sur mesure qui fonctionnent sur du matériel spécifique.

En ce qui concerne l'intégration avec C # et d'autres langues gérées de haut niveau - cela prendra un peu plus longtemps, mais XNA démontre déjà que les shaders personnalisés et environnement géré peuvent mélanger - dans une certaine mesure. Bien sûr, le code shader est toujours pas en C #, et il y a plusieurs obstacles majeurs à le faire.

L'une des principales raisons pour l'exécution rapide du code GPU est qu'il a de sérieuses limites sur ce que le code peut et ne peut le faire, et il utilise VRAM au lieu de RAM habituelle. Cela rend difficile de réunir le code CPU et code GPU. Bien que des solutions de contournement sont possibles, ils annulerait pratiquement le gain de performance.

Une solution possible que je vois est de faire un sous-langage C # qui a ses limites, est compilé au code GPU et a une façon strictement définie de communiquer avec le code ususal C #. Cependant, ce ne serait pas très différent de ce que nous avons déjà - un peu plus à l'aise pour écrire en raison de sucre syntaxique et les fonctions de la bibliothèque standard. Pourtant, cela aussi est l'âge loin pour l'instant.

Answer 2

Je pense que vous pouvez compter le prochain DirectX comme une autre façon d'utiliser le GPU.

D'après mon expérience, les GPU sont extrêmement rapides pour les algorithmes qui sont faciles à paralléliser. Je récemment optimisé un algorithme de redimensionnement de l'image spéciale dans CUDA pour être plus de 100 fois plus rapide sur le GPU (pas même un haut de gamme une) d'un noyau de processeur Intel quad. Le problème a été trouvé les données vers le processeur graphique, puis extraire le résultat à la mémoire principale, les deux directions limitée par la vitesse memcpy () sur cette machine, qui est inférieure à 2 Go / s. En conséquence, l'algorithme a été légèrement plus rapide que la version CPU ...

Donc, cela dépend vraiment. Si vous avez une application scientifique où vous pouvez garder la plupart des données sur le GPU, et tous les algorithmes associez à une implémentation GPU, alors tout va bien. Le reste j'attendre qu'il y ait une conduite plus rapide entre le CPU et le GPU, ou nous allons voir ce que ATI a retroussé leurs manches avec une puce combinée ...

A propos de la technologie à utiliser: Je pense qu'une fois que vous avez vos affaires en cours d'exécution dans CUDA, l'étape supplémentaire vers le port à OpenCL (ou une autre langue) n'est pas si grand. Vous avez fait tout le travail lourd par parallélisation vos algorithmes, et le reste est juste un autre « saveur »

Answer 3

Monte Carlo est honteusement parallèle, mais il est une technique de base en informatique financière et scientifique.

L'un des répondants est un peu inexact de dire que la plupart des défis du monde réel ne sont pas décomposable facilement dans ces types de tâches.

Une grande enquête scientifique tractible se fait en tirant parti de ce qui peut être exprimé d'une manière embarrassante parallèle.

Juste parce qu'il est nommé « honteusement » parallèle ne signifie pas qu'il est pas un domaine extrêmement important.

J'ai travaillé dans plusieurs maisons financières, et nous FORSEE que nous pouvons jeter les fermes de 1000 moteurs CARLO (de nombreuses piles de lames alignées ensemble) pour plusieurs grandes installations CUDA NVidia - puissance massivement décroissante et les coûts de la chaleur centre de données.

Un important avantage architectural est qu'il ya beaucoup moins de charge réseau aussi, car il y a beaucoup moins de machines qui ont besoin d'être nourris de données et de faire rapport de leurs résultats.

Fondamentalement cependant ces technologies sont à un niveau d'abstraction inférieur à un langage d'exécution géré tel que C #, nous parlons de périphériques qui exécutent leur propre code sur leurs propres processeurs.

L'intégration doit d'abord être fait avec Matlab, Mathematica je pense, ainsi que les API C bien sûr ...

Answer 4

Une autre technologie qui vient pour le traitement à base de GPU est des versions GPU des bibliothèques de calcul de haut niveau existants. Pas très flashy, je sais, mais il présente des avantages importants pour le code portable et la facilité de programmation.

Par exemple, Stream SDK 2.0 d'AMD comprend une version de leur bibliothèque BLAS (algèbre linéaire) avec certains des calculs mis en œuvre sur le GPU. L'API est exactement la même que leur version CPU uniquement de la bibliothèque qu'ils ont expédiés depuis des années et des années; tout ce qui est nécessaire est l'application re-lier, et il utilise le GPU et tourne plus vite.

De même, Dan Campbell à GTRI travaille sur une mise en œuvre de CUDA de la norme VSIPL pour le traitement du signal. (En particulier, le type de signal et de traitement d'image qui est commun dans les systèmes radar et des choses connexes comme l'imagerie médicale.) Encore une fois, qui est une interface standard, et les applications qui ont été écrites pour les implémentations de VSIPL sur d'autres processeurs peuvent simplement être recompilé avec celui-ci et utiliser la capacité du GPU, le cas échéant.

Dans la pratique, ces jours-ci déjà un certain nombre de programmes numériques de haute performance ne font pas leur propre programmation de bas niveau, mais comptent sur les bibliothèques. Sur le matériel Intel, si vous faites coup de chiffres, il est généralement difficile de battre les bibliothèques mathématiques Intel (MKL) pour la plupart des choses qu'elle met en œuvre - et en utilisant les moyens que vous pouvez obtenir les avantages de toutes les instructions vectorielles et trucs intelligents dans les nouveaux processeurs x86, sans avoir à se spécialiser votre code pour eux. Avec des choses comme GPUs, je soupçonne que cela deviendra encore plus répandu.

Je pense que la technologie à surveiller est le développement des bibliothèques à usage général qui forment des blocs de construction de base pour des applications dans des domaines spécifiques, de manière que les parties de capture de ces algorithmes qui peuvent être efficacement envoyés à la GPU tout en réduisant la quantité de non portable habileté spécifique GPU requise du programmeur.

(disclaimer Bias: Mon entreprise a également travaillé sur un port CUDA de notre VSIPL ++ bibliothèque, donc je suis enclin à penser que c'est une bonne idée)

En outre, dans une direction tout à fait différente, vous pouvez vérifier quelques-unes des choses que RapidMind fait. Leur plate-forme a été initialement conçu pour les systèmes de type CPU multi-cœurs, mais ils ont fait un bon peu de travail l'étendant aux calculs GPU ainsi.

Answer 5

À peu près tout ce qui peut être mis en parallèle peut être en mesure de bénéficier. Des exemples plus spécifiques seraient SETI @ home, Folding @ home, et d'autres projets distribués ainsi que le calcul scientifique.

Surtout des choses qui dépendent fortement de l'arithmétique à virgule flottante. En effet, les GPU ont des circuits spécialisés qui est très rapide à opérations en virgule flottante. Cela signifie que son pas aussi polyvalent, mais il est très bon à ce qu'il fait.

Si vous voulez regarder le traitement du GPU dédié plus, consultez GPU Nvidia Tesla . Il est un GPU, mais il n'a pas fait une sortie moniteur!

Je doute que nous verrons trop de traitement du GPU sur le bureau commun, ou au moins pendant un certain temps, parce que tout le monde a une CUDA ou carte graphique compatible similaire, si elles ont même une carte graphique du tout. Il est également très difficile de faire plus parallèle des programmes. Jeux pourraient utiliser cette puissance supplémentaire, mais il sera très difficile et ne sera probablement pas trop, car tous les calculs graphiques sont la plupart du temps déjà sur le GPU et l'autre travail est sur la CPU et a être sur la CPU en raison des jeux d'instructions.

traitement du GPU, au moins pendant un certain temps, sera pour les marchés de niche très spécifiques qui ont besoin de beaucoup de calcul à virgule flottante.

Answer 6

Il est important de garder à l'esprit que même les tâches qui sont par nature série peuvent bénéficier de parallélisation si elles doivent être effectuées plusieurs fois indépendamment.

Aussi, gardez à l'esprit que chaque fois que quelqu'un rapporte l'accélération d'une mise en œuvre du GPU à une implémentation du processeur, il est presque jamais une comparaison équitable. Pour être vraiment juste, il faut d'abord les implémenteurs passer le temps de créer une mise en œuvre du processeur parallèle vraiment optimisé. Un seul processeur Intel Core i7 965 XE CPU peut atteindre environ 70 gigaflops en double précision aujourd'hui. GPUs actuels haut de gamme peuvent faire 70-80 gigaflops en double précision et environ 1000 en simple précision. Ainsi, un gain de vitesse de plus de 15 peut impliquer une mise en œuvre du processeur inefficace.

Une mise en garde importante avec le GPU Computing est qu'il est actuellement « petite échelle ». Avec un centre de calcul intensif, vous pouvez exécuter un algorithme parallélisé sur des centaines, voire des milliers de cœurs de processeurs. En revanche, les GPU « clusters » sont actuellement limités à 8 processeurs graphiques connectés à une machine. Bien sûr, plusieurs de ces machines peuvent être combinés ensemble, mais cela ajoute une complexité supplémentaire que les données doivent passer non seulement entre les ordinateurs, mais aussi entre les processeurs graphiques. En outre, il n'y a pas encore d'équivalent MPI qui permet aux processus échelle transparente à plusieurs processeurs graphiques sur plusieurs machines; il doit être mis en oeuvre manuellement (éventuellement en combinaison avec MPI).

Mis à part ce problème de l'échelle, l'autre limitation majeure des GPU pour le calcul parallèle est la restriction sévère sur les modes d'accès mémoire. accès mémoire aléatoire est possible, mais l'accès mémoire soigneusement planifiée entraînera de nombreuses fois de meilleures performances.

Peut-être le candidat le plus prometteur à venir est Larrabee d'Intel. Il a beaucoup plus facilement accès à la CPU, la mémoire système, et peut-être plus important encore, la mise en cache. Cela devrait donner des avantages considérables avec de nombreux algorithmes. Si elle ne peut pas correspondre à la bande passante mémoire massive sur les GPU actuels, cependant, il peut être retard par rapport à la concurrence pour les algorithmes qui utilisent de façon optimale cette bande passante.

La génération actuelle de matériel et logiciel nécessite beaucoup d'efforts de développement pour obtenir des performances optimales. Cela inclut souvent des algorithmes de restructuration pour utiliser efficacement la mémoire du GPU. Il implique souvent aussi expérimenter avec différentes approches pour trouver le meilleur.

Notez également que l'effort requis pour obtenir une performance optimale est nécessaire pour justifier l'utilisation du matériel GPU. La différence entre une mise en œuvre naïve et une mise en œuvre optimisée peut être un ordre de grandeur ou plus. Cela signifie qu'un impelemntation CPU optimisé sera probablement aussi bon ou mieux encore qu'une implémentation GPU naïve.

Les gens travaillent déjà sur les liaisons .NET pour CUDA. Voir . Cependant, avec la nécessité de travailler à un niveau bas, je ne pense pas que l'informatique GPU est prêt pour les masses encore.

Answer 7

Je l'ai beaucoup entendu parlé de transformer ce qui aujourd'hui sont GPU en plus d'usage général « unités proceesor tableau », pour une utilisation avec any problème de mathématiques de la matrice, plutôt que le traitement graphique. Je ne l'ai pas vu beaucoup de venir encore bien.

La théorie était que les processeurs matriciels pourraient suivre à peu près la même trajectoire que les processeurs flottent points ont suivi quelques décennies auparavant. A l'origine des processeurs à virgule flottante sont des options complémentaires coûteuses pour PC qui a pas beaucoup de gens pris la peine d'acheter. Finalement, ils sont devenus si importantes qu'elles ont été mis dans le CPU lui-même.

Answer 8

Je vais répéter la réponse que je donnais ici.

à long terme, je pense que le GPU cessera d'exister, car les processeurs à usage général évoluent de prendre en charge ces fonctions. Larrabee d'Intel est la première étape. L'histoire a montré que les paris contre x86 est une mauvaise idée.

Answer 9

GHC (Haskell) chercheurs (travaillant pour Microsoft Research) sont l'ajout du support pour les données Nested Parallélisme directement à un usage général langage de programmation. L'idée est d'utiliser plusieurs cœurs et / ou processeurs graphiques sur l'arrière exposer encore de données des réseaux parallèles comme un type natif dans la langue, quel que soit le moteur d'exécution l'exécution du code en parallèle (ou en série pour la fallback simple CPU).

http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

En fonction du succès de ce dans les prochaines années, j'attendre à voir d'autres langues (C # en particulier) revenir sur l'idée, ce qui pourrait amener ces sortes de capacités à un public plus mainstream. Peut-être en ce moment la bande passante CPU-GPU et les problèmes pilotes seront résolus.

Answer 10

processeurs graphiques fonctionnent bien dans les problèmes où il y a un niveau élevé de données Niveau Parallélisme , ce qui signifie essentiellement il existe un moyen pour diviser les données à traiter de telle sorte qu'ils peuvent tous être traités.

processeurs graphiques ne sont pas par nature aussi vite à un niveau de vitesse d'horloge. En fait, je suis relativement sûr que la vitesse d'horloge sur les shaders (ou peut-être qu'ils ont un terme plus GPGPU pour eux ces jours?) Est assez lent par rapport à l'UMM sur un processeur de bureau moderne. La chose est, un GPU a une quantité absolument énorme de ces shaders, en tournant le GPU dans un très grand processeur de SIMD. Avec la quantité de shaders sur une Geforce moderne, par exemple, il est possible pour un GPU de travailler sur plusieurs centaines (milliers?) Nombres à virgule flottante à la fois.

Bref, un GPU peut être incroyablement rapide pour des problèmes où vous pouvez partitionner les données correctement et traiter les partitions indépendamment. Ce n'est pas si puissant Tâche (fil) Niveau Parallélisme .

Answer 11

Un gros problème avec la technologie GPU est que si vous avez beaucoup de capacité de calcul là-dedans, l'obtention de données dans (et hors de celui-ci) est terrible (sage-performance). Et surveiller attentivement les points de repère de comparaison ... ils comparent souvent gcc (avec optimisation minimale, pas vectorisation) sur un seul système de traitement au GPU.

Un autre gros problème avec ce GPU est que si vous ne pensez pas ATTENTIVEMENT sur la façon dont vos données sont organisées, vous subissez une réelle performance due en interne (dans le GPU). Cela implique souvent la réécriture du code très simple dans un tas d'ordures alambiqué.

Answer 12

Je suis très excité à propos de cette technologie. Cependant, je pense que cela ne fera qu'exacerber le véritable défi des grandes tâches parallèles, l'une de la bande passante. Ajout de plusieurs noyaux augmentera seulement pour la mémoire contention. OpenCL et d'autres bibliothèques d'abstraction GPGPU ne proposent pas d'outils pour améliorer la situation.

Toute plate-forme matérielle de calcul haute performance sera généralement conçu avec la question de la bande passante soigneusement planifiée dans le matériel, le débit d'équilibrage, la latence, la mise en cache et le coût. Tant que le matériel des produits de base, CPU et GPU, sont conçus de manière isolée les unes des autres, avec une bande passante optimisée seulement pour leur mémoire locale, il sera très difficile d'améliorer ce pour les algorithmes qui en ont besoin.

Answer 13

Il est vrai que les GPU peut atteindre de très nombres salut de performance dans des situations de parallélisme au niveau des données, comme beaucoup ici mentionnés. Mais comme je le vois, il n'y a pas grand-chose à utiliser dans l'espace utilisateur maintenant. Je ne peux pas le sentiment d'aide que toute cette propagande GPGPU vient des fabricants de GPU, qui veulent juste trouver de nouveaux marchés et utilise pour leurs produits. Et c'est ok absolutelly. Avez-vous déjà demandé pourquoi intel / amd na pas inclure certains noyaux mini-x86 en plus les standards (permet de dire - modèle avec quatre cœurs x86 et 64 mini-x86-cœurs), pour amplifier au niveau des données capabilties de paralelism? Ils pourraient certainement le faire, si on le souhaite. Je pense que l'industrie juste ne besoin de ce genre de puissance de traitement dans les machines de bureau régulières / serveur.

Answer 14

GPUs peut ou ne peut pas rester aussi populaires qu'ils sont maintenant, mais l'idée de base est en train de devenir une approche plutôt populaire pour le traitement de haute puissance. Une tendance qui est à venir est maintenant le « accélérateur » externe pour aider le CPU avec les grands travaux à virgule flottante. Un GPU est un seul type d'accélérateur.

Intel lance un nouvel accélérateur appelé Xeon Phi , qu'ils espèrent peut remettre en question le GPU comme accélérateur HPC. a adopté une approche similaire, ayant un processeur principal pour effectuer des tâches générales, et déchargeant des tâches intensives à calculer d'autres éléments de traitement, la réalisation des vitesses impressionnantes.

Accélérateurs en général semblent être d'intérêt pour le moment, donc ils devraient être autour pendant un certain temps au moins. Si oui ou non le GPU reste que l'accélérateur de facto reste à voir.

Answer 15

Votre perception que les GPU sont plus rapides que les processeurs est basée sur l'idée fausse créée par quelques applications embarassingly parallèles appliquées aux goûts de la PS3, le matériel NVIDIA et ATI.

http://en.wikipedia.org/wiki/Embarrassingly_parallel

La plupart des défis du monde réel ne sont pas décomposable facilement dans ces types de tâches. La CPU de bureau est beaucoup mieux adapté à ce type de défi à la fois un point de vue ensemble des fonctionnalités et des performances.

Answer 16

Je pense les mêmes choses que les processeurs sont utilisés pour?

Je veux dire que cela semble être un truc pour moi. Je hésite à dire « que ça ne va nulle part » en ce qui concerne la technologie, mais GPUs principale fonction est rendu graphique et la fonction primaire est CPUs tout autre traitement. Avoir le GPU fait autre chose semble juste whacky.