Nous avons fait une comparaison entre FPGA et CUDA. Une chose où CUDA brille si vous pouvez vraiment formuler votre problème de manière SIMD et accéder à la mémoire coalesced. Si les accès à la mémoire ne sont pas coalescés(1) ou si vous avez un flux de contrôle différent dans différents threads, le GPU peut perdre considérablement ses performances et le FPGA peut le surpasser. Une autre chose est quand votre opération est realtive petite, mais vous avez une énorme quantité de celui-ci. Mais vous ne pouvez pas (par exemple en raison de la synchronisation) pas de démarrage dans une boucle dans un noyau, alors vos temps d'invocation pour le noyau GPU dépassent le temps de calcul.

Aussi la puissance du FPGA pourrait être meilleure (dépend de votre scenarion d'application, ie. le GPU est seulement moins cher (en termes de Watts/Flop) lorsque son calcul tout le temps).

Offcourse le FPGA a aussi quelques inconvénients: IO peut être un (nous avions ici une application si nous avions besoin de 70 GB / s, pas de problème pour le GPU, mais pour obtenir cette quantité de données dans un FPGA vous avez besoin pour conventionnel concevoir plus de broches que disponible). 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 à des adresses séquentielles. C'est parfois très difficile à obtenir.

J'irais avec CUDA.
Je travaille dans le traitement d'image 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 directe compiliation-à-matériel.
Ce qui est arrivé de façon inné, c'est qu'au moment où les cartes matérielles étaient vraiment déboguées et fiables et que le code leur avait été porté - les processeurs réguliers avaient avancé pour les battre, ou l'architecture de la machine d'hébergement avait changé et nous ne pouvions pas utiliser les anciennes cartes, ou les fabricants de la carte a fait faillite.

En adhérant à quelque chose comme CUDA, vous n'êtes pas lié à un petit fabricant spécialisé de cartes FPGA. La performance des GPU s'améliore plus rapidement que les CPU et est financée par les joueurs. C'est une technologie grand public et donc va probablement fusionner avec les processeurs multi-core à l'avenir et ainsi protéger votre investissement.

FPGA

• ce dont vous avez besoin:
  • Apprenez VHDL / Verilog (et croyez-moi, vous ne le ferez pas)
  • Acheter hw pour les tests, licences sur les outils de synthèse
  • Si vous choisissez un bon cadre (par exemple. : RSoC )
    • Développer la conception ( 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 l'ip noyaux
    • Développer la conception
• par exemple, la carte PCIE FPGA moyenne avec puce Xilinx virtex-6 coûte plus de 3000 $
• résultat:
  • Si vous n'êtes pas payé par le gouvernement, vous n'avez pas suffisamment de fonds.

GPGPU (Cuda / OpenCL)

• vous avez déjà hw à tester.
• comparer aux trucs FPGA:
  • Tout est bien documenté .
  • Tout est bon marché
  • Tout travaux
  • Tout est bien intégré aux langages de programmation
• Il y a aussi GPU cloud.
• résultat:
  • vous devez simplement télécharger sdk et vous pouvez commencer.

La solution basée sur FPGA est susceptible d'être beaucoup plus chère que CUDA.

CUDA a une base de code assez importante d'exemples et un SDK , y compris un back-end BLAS. Essayez de trouver des exemples similaires à ce que vous faites, peut-être aussi en regardant la série de livresGPU Gems , pour évaluer à quel point CUDA s'adaptera à vos applications. Je dirais d'un point de vue logistique, CUDA est plus facile à utiliser et beaucoup, beaucoup moins cher que n'importe quelle boîte à outils de développement FPGA professionnelle.

À un moment donné, j'ai regardé dans CUDA pour la réserve de réclamation modélisation de simulation. Il y a tout à fait une bonne série de conférences liées sur le site web pour l'apprentissage. Sous Windows, vous devez vous assurer que CUDA fonctionne sur une carte sans affichage, car le sous-système graphique dispose d'une minuterie de surveillance qui nuke tout processus en cours d'exécution pendant plus de 5 secondes. Cela ne se produit pas sous Linux.

Tout mahcine avec deux slots PCI-e x16 devrait supporter cela. J'ai utilisé un HP XW9300, que vous pouvez ramasser sur ebay à moindre coût. Si vous le faites, assurez-vous qu'il a deux CPU (pas un CPU dual-core) comme les slots PCI-e vivent sur des bus Hypertransport séparés et vous avez besoin de deux CPU dans la machine pour avoir les deux bus actifs.

, Évidemment, c'est une question complexe. La question peut également inclure le processeur de cellules. Et il n'y a probablement pas une seule réponse qui soit correcte pour d'autres questions connexes.

D'après mon expérience, toute implémentation faite de manière abstraite, c'est-à-dire un langage de haut niveau compilé par rapport à l'implémentation au niveau de la machine, aura inévitablement un coût de performance, en particulier dans une implémentation d'algorithme complexe. Cela est vrai des FPGA et des processeurs de tout type. Un FPGA conçu plus précisément, mettre en œuvre un algorithme complexe fonctionnera mieux qu'un FPGA dont les éléments de traitement sont génériques, ce qui lui permet un degré de programmabilité à partir de registres de contrôle d'entrée, d'e/s de données, etc.

Un autre exemple général où un FPGA peut être beaucoup plus performant est dans les processus en cascade où les sorties du processus deviennent les entrées d'un autre et elles 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 mémoire tout en la mémoire du processeur sera utilisée pour cascader efficacement deux processus ou plus où il existe des dépendances de données.

La même chose peut être dite 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é qui le fait. Certes, ne pas tenir compte de ces caractéristiques de performance simplifie la mise en œuvre. Mais lors d'une représentation coût.

N'ayant aucune expérience directe avec un GPU, mais connaissant ses problèmes de performance inhérents au système de mémoire, il sera également soumis à des problèmes de performance.

Je suis un développeur CUDA avec une expérience très littel avec FPGA: s, mais j'ai essayé de trouver des comparaisons entre les deux.

Ce que j'ai conclu jusqu'à présent:

Le GPU a des performances de pointe ( accessibles ) de loin plus élevées Il a un rapport FLOP/watt plus favorable. Il 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 faire des accès aléatoires aux données. Cela va, espérons-le, changer avec la nouvelle architecture NVIDIA Fermi qui dispose d'un cache L1/L2 optionnel.

Mes 2 cents

C'est un vieux fil commencé en 2008, mais il serait bon de raconter ce qui est arrivé à la programmation FPGA depuis lors: 1. C to gates dans FPGA est le développement courant pour de nombreuses entreprises avec un gain de temps énorme par rapport à Verilog / SystemVerilog HDL. En C à la conception de niveau de système de portes est la partie difficile. 2. OpenCL sur FPGA est là pour les années 4+, y compris le déploiement en virgule flottante et "cloud" par Microsoft (Asure) et Amazon F1 (API Ryft). Avec la conception du système OpenCL est relativement facile en raison de très modèle de mémoire bien défini et API entre l'hôte et les périphériques de calcul.

Les utilisateurs de logiciels ont juste besoin d'en apprendre un peu plus sur L'architecture FPGA pour pouvoir faire des choses qui ne sont même pas possibles avec les GPU et les processeurs pour des raisons à la fois de silicium fixe et de ne pas avoir d'interfaces haut débit (100Gb+) au monde extérieur. Réduire la géométrie de la puce n'est plus possible, ni extraire plus de chaleur du paquet de puce unique sans le faire fondre, donc cela ressemble à la fin de la route pour un seul paquet de chips. Ma thèse ici est que l'avenir appartient à la programmation parallèle des systèmes multi-puces, et les FPGA ont une grande chance d'être en avance sur le jeu. Vérifier http://isfpga.org/ Si vous avez des préoccupations au sujet de la performance, etc.

Sur quoi déployez-vous? Qui est votre client? Sans même connaître les réponses à ces questions, je n'utiliserais pas de FPGA à moins que vous ne construisiez un système en temps réel et que vous ayez des ingénieurs électriques/informatiques dans votre équipe qui connaissent les langages de description du matériel tels que VHDL et Verilog. Il y a beaucoup à cela et il faut un État d'esprit différent de la programmation conventionnelle.

Les FPGA sont tombés en disgrâce dans le secteur du HPC parce qu'ils sont une horreur à programmer. CUDA est parce qu'il est beaucoup plus agréable à programmer et vous donnera toujours de bonnes performances. J'irais avec ce que la communauté HPC a fait et le faire dans CUDA. C'est plus facile, c'est moins cher, c'est plus maintenable.

D'autres ont donné de bonnes réponses, je voulais juste ajouter une perspective différente. Voici mon enquête papier publié dans ACM Computing Surveys 2015 (son permalien est ici), qui compare GPU avec FPGA et CPU sur l'efficacité énergétique métrique. La plupart des documents rapportent: FPGA est plus économe en énergie que GPU, qui, à son tour, est plus économe en énergie que CPU. Étant donné que les budgets de puissance sont fixes (en fonction de la capacité de refroidissement), L'efficacité énergétique du FPGA signifie que l'on peut faire plus de calculs dans le même budget de puissance avec FPGA, et ainsi obtenir de meilleures performances avec FPGA qu'avec GPU. Bien sûr, tenez également compte des limitations de FPGA, comme mentionné par d'autres.

FPGA ne sera pas favorisée par ceux qui ont un biais logiciel car ils ont besoin d'apprendre un HDL ou au moins comprendre systemC.

Pour ceux qui ont un biais matériel FPGA sera la première option considérée.

En réalité, une compréhension ferme des deux est requise et une décision objective peut alors être prise.

OpenCL est conçu pour fonctionner à la fois sur FPGA et GPU, même CUDA peut être porté sur FPGA.

Les accélérateurs FPGA et GPU peuvent être utilisés ensemble

Donc ce n'est pas un cas de ce qui est mieux l'un ou l'autre. Il y a aussi le débat sur CUDA vs OpenCL

Encore une fois, sauf si vous avez optimisé & benchmarked à la fois à votre application spécifique, vous ne pouvez pas savoir avec certitude à 100%.

Beaucoup iront simplement avec CUDA en raison de sa nature commerciale et de ses ressources. D'autres iront avec openCL en raison de sa polyvalence.

Au plus tard GTC ' 13 beaucoup de gens de HPC ont convenu que CUDA est là pour rester. Les FGPA sont encombrants, CUDA devient beaucoup plus mature en supportant Python/C / C++ / ARM.. de toute façon, c'était une question datée

• les FPGA sont plus parallèles que les GPU, de trois ordres de grandeur. Bien que le bon GPU dispose de milliers de cœurs, 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 vraiment indépendantes les unes des autres.
• FPGA peut être très rapide avec certains groupes de tâches et sont souvent utilisés où une milliseconde est déjà considérée comme une longue durée.
• GPU core est beaucoup plus puissant que FPGA cellulaire, et beaucoup plus facile à programmer. Il est un noyau, peut diviser et multiplier aucun problème lorsque la cellule FPGA est seulement capable de logique booléenne plutôt simple.
• comme GPU core est un core , Il est efficace de le programmer en C++. Même il est également possible de programmer FPGA en C++, il est inefficace (juste "productif"). Des langages spécialisés comme VDHL ou Verilog doivent être utilisés - ils sont difficiles et difficiles à maîtriser.
• la plupart des instincts vrais et éprouvés d'un ingénieur logiciel sont inutiles avec FPGA. Vous voulez un pour la boucle, avec ces portes? Qui galaxy êtes-vous? Vous devez changer dans l'état d'esprit de l'ingénieur en électronique pour comprendre ce monde.

La programmation D'un GPU dans CUDA est certainement plus facile. Si vous n'avez aucune expérience avec la programmation de FPGA en HDL, ce sera presque sûrement 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 cher que la programmation des GPU.

Lequel est le plus Rapide?

GPU fonctionne plus vite, mais FPGA peut être plus efficace.

GPU a le potentiel de fonctionner à un vitesse plus élevée que FPGA peut jamais atteindre. Mais seulement pour les algorithmes qui sont spécialement adaptés pour cela. Si l'algorithme n'est pas optimal, le GPU perdra beaucoup de performances.

FPGA d'autre part fonctionne beaucoup plus lentement, mais vous pouvez implémenter du matériel spécifique au problème qui sera très efficace et faire des choses en moins de temps.

C'est un peu comme manger votre soupe avec une fourchette très rapide vs manger avec une cuillère plus lentement.

Les deux appareils basent leurs performances sur parallélisation, mais chacun d'une manière légèrement différente. Si l'algorithme peut être granulé en un grand nombre de pièces qui exécutent les mêmes opérations (mot-clé: SIMD), le GPU sera plus rapide. Si l'algorithme peut être implémenté comme un long pipeline, le FPGA sera plus rapide. Aussi, si vous voulez utiliser le point flottant, FPGA ne sera pas très heureux avec elle:)

J'ai consacré toute ma thèse de maîtrise à ce sujet. accélération de L'algorithme sur FPGA avec OpenCL