CUDA ou FPGA pour des calculs graphiques 3D spécifiques?
https://stackoverflow.com/questions/317731
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je développe un produit avec des calculs graphiques 3D lourds, dans une large mesure, les recherches de points et de plages les plus proches . Une optimisation matérielle serait utile. Bien que je sache peu de choses à ce sujet, mon patron (qui n’a aucune expérience en logiciel) préconise le FPGA (car il peut être adapté), tandis que notre développeur junior préconise le GPGPU avec CUDA, car c’est peu coûteux, chaud et ouvert. Même si j’estime que je manque de jugement sur cette question, je pense que CUDA est la voie à suivre également parce que je suis inquiet pour la flexibilité, notre produit est toujours en plein développement.
Donc, pour reformuler la question, y a-t-il des raisons d’opter pour le FPGA? Ou existe-t-il une troisième option?
La solution
J'ai étudié la même question il y a quelque temps. Après avoir discuté avec des personnes qui ont travaillé sur les FPGA, voici ce que je comprends:
- Les FPGA sont parfaits pour les systèmes temps réel, où même 1 ms de retard peut être trop long. Cela ne s'applique pas dans votre cas.
- Les FPGA peuvent être très rapides, en particulier pour des utilisations bien définies du traitement du signal numérique (par exemple, les données radar), mais les bonnes sont beaucoup plus coûteuses et spécialisées que même les GPGPU professionnels;
- Les FPGA sont assez difficiles à programmer. Étant donné qu’il faut compiler un composant de configuration matérielle, cela peut prendre des heures. Il semble être plus adapté aux ingénieurs en électronique (qui sont généralement ceux qui travaillent sur les FPGA) qu'aux développeurs de logiciels.
Si vous pouvez utiliser CUDA pour vous, c’est probablement la meilleure option pour le moment. Ce sera certainement plus flexible qu'un FPGA.
Brook propose également ATI, mais jusqu'à ce que quelque chose de grave se produise, il n'est tout simplement pas aussi bien adopté que CUDA. Après cela, il reste toutes les options HPC traditionnelles (grappes de x86 / PowerPC / Cell), mais elles coûtent toutes assez cher.
L’espoir que cela aide.
Autres conseils
Nous avons fait des comparaisons entre FPGA et CUDA. CUDA a une chose en son pouvoir si vous pouvez vraiment formuler votre problème de manière SIMD ET pouvoir accéder à la mémoire fusionnée. Si les accès à la mémoire ne sont pas fusionnés (1) ou si vous avez un flux de contrôle différent dans différents threads, le processeur graphique peut perdre considérablement ses performances et le FPGA peut le surpasser. Une autre chose est que lorsque votre opération est réelle, vous en avez une quantité énorme. Mais vous ne pouvez pas (par exemple, en raison de la synchronisation) ne pas le démarrer en boucle dans un noyau, vos temps d’appel pour le noyau GPU dépassent le temps de calcul.
De plus, la puissance du FPGA pourrait être meilleure (dépend de votre scénario d’application, c’est-à-dire que le GPU n’est que meilleur marché (en termes de Watts / Flop) lorsqu’il est constamment en train de fonctionner).
Bien sûr, le FPGA présente aussi quelques inconvénients: IO peut en être un (nous avions ici une application où nous avions besoin de 70 Go / s, pas de problème pour le GPU, mais pour obtenir cette quantité de données dans un FPGA, vous avez besoin d’une conception classique plus broches que disponibles). Un autre inconvénient est le temps et l'argent. Un FPGA est beaucoup plus cher que le meilleur GPU et les temps de développement sont très élevés.
(1) Les accès simultanés de différents threads à la mémoire doivent être adressés à des adresses séquentielles. C'est parfois très difficile à réaliser.
J'irais avec CUDA.
Je travaille dans le traitement d'images et j'essaie des add-ons matériels depuis des années. Nous avons d’abord eu i860, puis Transputer, puis DSP, puis le FPGA et la compilation directe vers le matériel.
Ce qui est inévitablement arrivé, c’est qu’au moment où les cartes matérielles étaient réellement déboguées et fiables et que le code leur avait été transféré - les processeurs normaux avaient évolué pour les vaincre, ou l’architecture de la machine d’hébergement avait été modifiée et nous ne pouvions plus utiliser les anciennes cartes. les fabricants du conseil ont fait faillite.
En vous en tenant à quelque chose comme CUDA, vous n'êtes pas lié à un petit fabricant spécialisé de cartes FPGA. Les performances des GPU s’améliorent plus rapidement que les processeurs et sont financées par les joueurs. Il s’agit d’une technologie traditionnelle qui fusionnera probablement à l’avenir avec des processeurs multicœurs et protégera ainsi votre investissement.
FPGA
- Ce dont vous avez besoin:
- Apprenez le VHDL / Verilog (et croyez-moi, vous ne le ferez pas)
- Acheter hw à des fins de test, licences sur les outils de synthèse
- Si vous choisissez un bon cadre (par exemple: RSoC )
- Développer le design (et cela peut prendre des années)
- Si vous ne le faites pas:
- DMA, pilote hw, outils de synthèse ultra coûteux
- des tonnes de connaissances sur les bus, la cartographie de la mémoire, la synthèse hw
- construisez le hw, achetez les cœurs ip
- Développer le design
- Par exemple, une carte de puce FPGA avec une puce Xilinx virtex-6 coûte plus de 3000 $
- Résultat:
- Si vous n'êtes pas payé par le gouvernement, vous n'avez pas assez de fonds.
GPGPU (CUDA / OpenCL)
- Vous devez déjà tester hw.
- Comparez aux éléments FPGA:
- Tout est bien documenté.
- Tout n'est pas cher
- Tout fonctionne
- Tout est bien intégré aux langages de programmation
- Il existe également un nuage GPU.
- Résultat:
- Vous devez simplement télécharger sdk et vous pouvez commencer.
Une solution basée sur le FPGA coûtera probablement beaucoup plus cher que CUDA.
De toute évidence, cette question est complexe. La question pourrait également inclure le processeur de cellule. Et il n’ya probablement pas une seule réponse qui soit correcte pour d’autres questions connexes.
Selon mon expérience, toute implémentation réalisée de manière abstraite, c'est-à-dire compilée avec un langage de haut niveau par rapport à une implémentation au niveau machine, aura inévitablement un coût en performances, en particulier dans une implémentation d'algorithme complexe. Ceci est vrai pour les FPGA et les processeurs de tous types. Un FPGA conçu spécifiquement pour implémenter un algorithme complexe donnera de meilleurs résultats qu'un FPGA dont les éléments de traitement sont génériques, lui permettant un degré de programmabilité à partir de registres de contrôle d’entrée, de données d’entrée / sortie, etc.
Un autre exemple général dans lequel un FPGA peut être beaucoup plus performant est celui des processus en cascade où les sorties de processus deviennent les entrées d’un autre et ne peuvent pas être effectuées simultanément. Les processus en cascade dans un FPGA sont simples et peuvent réduire considérablement les exigences d'E / S de la mémoire, tandis que la mémoire du processeur sera utilisée pour mettre en cascade au moins deux processus dans lesquels des dépendances de données existent.
On peut dire la même chose d’un GPU et d’un CPU. Les algorithmes implémentés en C s'exécutant sur une CPU développée sans tenir compte des caractéristiques de performance inhérentes à la mémoire cache ou au système de mémoire principale ne fonctionneront pas aussi bien que celui implémenté. Accordé, sans tenir compte de ces caractéristiques de performance simplifie la mise en œuvre. Mais à un coût de performance.
N'ayant pas d'expérience directe avec un processeur graphique, mais connaissant les problèmes de performances inhérents au système de mémoire, celui-ci sera également soumis à des problèmes de performances.
Ceci est un ancien fil de discussion lancé en 2008, mais il serait bon de raconter ce qui est arrivé à la programmation FPGA depuis lors: 1. C to Gates in FPGA est le développement courant de nombreuses entreprises avec un gain de temps énorme par rapport à Verilog / SystemVerilog HDL. En C to Gates La conception au niveau du système est la partie difficile. 2. OpenCL sur FPGA existe depuis plus de 4 ans, y compris virgule flottante et "cloud". déploiement par Microsoft (Asure) et Amazon F1 (API Ryft). Avec OpenCL, la conception du système est relativement simple en raison du modèle de mémoire et de l’API très bien définis entre les périphériques hôte et informatique.
Les développeurs de logiciels ont juste besoin d’apprendre un peu plus sur l’architecture FPGA pour pouvoir faire des choses qui NE SONT PAS POSSIBLES avec les GPU et les CPU, à la fois parce qu’ils sont fixes et n’ont pas d’interface large bande (100Gb +) avec le monde extérieur. Réduire la géométrie des puces n'est plus possible, ni extraire plus de chaleur de l'emballage à puce unique sans la faire fondre, de sorte que cela ressemble à la fin de la route pour les puces à emballage unique. Ma thèse est que l'avenir appartient à la programmation parallèle de systèmes multi-puces et que les FPGA ont de grandes chances d'être en avance sur leur temps. Si vous avez des doutes sur les performances, consultez http://isfpga.org/ .
CUDA a une base de code assez substantielle d’exemples et un SDK , y compris < a href = "http://www.nvidia.com/content/cudazone/cuda_sdk/Linear_Algebra.html" rel = "nofollow noreferrer"> un back-end BLAS . Essayez de trouver des exemples similaires à ceux que vous faites, en consultant peut-être également le GPU Gems , pour évaluer dans quelle mesure CUDA s'adaptera à vos applications. D’un point de vue logistique, je dirais que CUDA est plus facile à travailler et beaucoup moins cher que n’importe quelle boîte à outils de développement FPGA professionnelle.
À un moment donné, j’ai examiné CUDA pour la modélisation de la simulation des réserves. Il existe une assez bonne série de conférences reliées au site Web pour apprendre. Sous Windows, vous devez vous assurer que CUDA s'exécute sur une carte sans afficheur, car le sous-système graphique dispose d'un minuteur de surveillance qui annule tout processus exécuté pendant plus de 5 secondes. Cela ne se produit pas sous Linux.
Tous les ordinateurs dotés de deux emplacements PCI-e x16 devraient le supporter. J'ai utilisé un HP XW9300, que vous pouvez récupérer à moindre coût sur eBay. Si vous le faites, assurez-vous qu’il dispose de deux processeurs (et non d’un processeur double cœur), car les logements PCI-e reposent sur des bus Hypertransport distincts et que vous avez besoin de deux processeurs sur la machine pour activer les deux bus.
Je suis un développeur CUDA avec très peu d'expérience en FPGA: s, mais j'ai essayé de faire des comparaisons entre les deux.
Ce que j'ai conclu jusqu'à présent:
Les performances maximales du GPU sont de loin supérieures (accessibles) Son rapport FLOP / watt est plus favorable. C'est moins cher Il se développe plus rapidement (très bientôt, vous aurez littéralement un "vrai" TFLOP disponible). Il est plus facile de programmer (lire l'article sur cette opinion non personnelle)
Notez que je dis réel / accessible pour distinguer des chiffres que vous verrez dans une publicité GPGPU.
MAIS le gpu n’est pas plus favorable lorsque vous devez effectuer des accès aléatoires à des données. Nous espérons que cela changera avec la nouvelle architecture Nvidia Fermi qui dispose d’un cache optionnel l1 / l2.
mes 2 cents
Les FPGA ne privilégieront pas les FPGA car ils doivent apprendre un HDL ou au moins comprendre SystemC.
Pour ceux qui ont un biais matériel, le FPGA sera la première option considérée.
En réalité, vous devez bien maîtriser les deux. alors une décision objective peut être prise.
OpenCL est conçu pour fonctionner à la fois sur FPGA & amp; Le processeur graphique, même CUDA, peut être porté en FPGA.
FPGA & amp; Les accélérateurs GPU peuvent être utilisés ensemble
Donc, il ne s'agit pas de savoir ce qui est meilleur l'un ou l'autre. Il y a aussi le débat sur CUDA vs OpenCL
Encore une fois, sauf si vous avez optimisé & amp; référencé à la fois pour votre application spécifique, vous ne pouvez pas savoir avec une certitude à 100%.
Beaucoup vont simplement avec CUDA à cause de sa nature commerciale & amp; Ressources. D'autres opteront pour openCL en raison de sa polyvalence.
Sur quoi déployez-vous? Qui est ton client? Sans même connaître les réponses à ces questions, je n’utiliserais pas un FPGA si vous ne construisez pas un système en temps réel et n’avez que des ingénieurs en électricité / informatique de votre équipe qui connaissent les langages de description de matériel tels que VHDL et Verilog. Il y a beaucoup à faire et cela nécessite un état d'esprit différent de celui de la programmation conventionnelle.
Les FPGA ont perdu la faveur du secteur HPC car ils sont une horreur à programmer. CUDA fait partie du programme, car il est beaucoup plus agréable de programmer et vous donnera quand même de bonnes performances. Je voudrais aller avec ce que la communauté HPC est allé avec et le faire dans CUDA. C'est plus facile, c'est moins cher, c'est plus facile à maintenir.
D'autres ont donné de bonnes réponses, voulaient simplement ajouter une perspective différente. Voici mon enquête article publié dans ACM Computing Surveys 2015 (son permalink est
- Les FPGA sont plus parallèles que les GPU, par trois ordres de grandeur. Bien qu'un bon GPU comporte des milliers de cœurs, le FPGA peut avoir des millions de portes programmables.
- Alors que les cœurs CUDA doivent faire des calculs très similaires pour être productifs, les cellules FPGA sont réellement indépendantes les unes des autres.
- Les FPGA peuvent être très rapides avec certains groupes de tâches et sont souvent utilisés lorsqu'une milliseconde est déjà perçue comme une longue durée.
- Le cœur du processeur graphique est bien plus puissant que la cellule FPGA et beaucoup plus facile à programmer. C’est un noyau capable de diviser et de multiplier sans problème lorsque la cellule FPGA n’est capable que d’une logique booléenne assez simple.
- Comme le coeur du GPU est un noyau , il est efficace de le programmer en C ++. Même s’il est également possible de programmer un FPGA en C ++, il est inefficace (juste "productif"). Des langues spécialisées telles que VDHL ou Verilog doivent être utilisées - elles sont difficiles et difficiles à maîtriser.
- La plupart des instincts vrais et éprouvés d'un ingénieur en logiciel sont inutiles avec le FPGA. Vous voulez une for loop avec ces portes? De quelle galaxie es-tu? Pour comprendre ce monde, vous devez changer d’esprit d’ingénieur en électronique.
au plus tard aux GTC'13, de nombreux membres du HPC ont convenu que CUDA est là pour rester. Les FGPA sont encombrants, CUDA devient de plus en plus mature et supporte Python / C / C ++ / ARM.
Programmer un GPU dans CUDA est vraiment plus facile. Si vous n'avez pas d'expérience dans la programmation de FPGA en HDL, le défi sera sans doute trop difficile pour vous, mais vous pouvez toujours les programmer avec OpenCL, qui est un peu similaire à CUDA. Cependant, il est plus difficile à mettre en œuvre et probablement beaucoup plus coûteux que de programmer des GPU.
Lequel est le plus rapide?
Le processeur graphique s'exécute plus rapidement, mais le FPGA peut être plus efficace.
Le processeur graphique peut potentiellement fonctionner à une vitesse supérieure à celle que le FPGA peut atteindre. Mais uniquement pour les algorithmes spécialement adaptés à cela. Si l'algorithme n'est pas optimal, le processeur graphique perdra beaucoup de performances.
D’un autre côté, les FPGA sont beaucoup plus lents, mais vous pouvez implémenter un matériel spécifique au problème qui sera très efficace et vous permettra d’obtenir des résultats plus rapidement.
C'est un peu comme manger sa soupe avec une fourchette très rapidement ou la manger plus lentement avec une cuillère.
Les deux appareils basent leurs performances sur la parallélisation, mais de manière légèrement différente. Si l'algorithme peut être fragmenté en un grand nombre d'éléments exécutant les mêmes opérations (mot clé: SIMD), le processeur graphique sera plus rapide. Si l'algorithme peut être implémenté comme un long pipeline, le FPGA sera plus rapide. De plus, si vous voulez utiliser une virgule flottante, le FPGA n'en sera pas très content:)
J'ai consacré toute ma thèse à ce sujet.
