J'ai trouvé une publi scientifique sur le site IEEE intitulé "A design Case study: CPU vs GPGPU vs FPGA" écrit par Daniel L. Rosenband. Bon je ne peux la mettre en ligne car l'accès au site IEEE est payant... (Je sais, ce n'est pas une bonne preuve)
Pour ceux qui ont un accès IEEE: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05185380
Cependant je m'appuie cette fois-ci non seulement sur mes connaissances mais sur les connaissances d'un chercheur du MIT (donc il est loin d'être idiot...).
Dans cet article est décrit l'utilisation des CPU et GPU ainsi que des FPGAs.
Le but de son calcul est de transformer chaque point d'une grille cartésienne en grille polaire (si j'ai bien compris), bref c'est juste le calcul qui est fait et qui n'importe peu.
Ses résultats montre que les GPU (NVIDIA GTX285) sont nettement meilleur que le CPU (Intel core i7 3.2GHz).
Il utilise 2 FPGAs : le Virtex II Pro et le Virtex 5. Le Virtex 5 possède nettement plus de logique, plus de mémoire dédié, plus de blocs de calcul et des rocket I/O pour le transfert rapide que ne dispose pas le Virtex II pro.
Résultat... Bon le Virtex II Pro (Qui doit avoir 8 ans) est à la ramasse 10 fois plus lent que le CPU. Mais en revanche le VIRTEX 5 STX est 2 fois meilleur que le GPU sauf au niveau du temps de transfert dans la mémoire et 6 fois plus rapide que le CPU... Pour le temps de transfert, il est normal qu'il soit plus long dans un FPGA, ceci est du aux temps transfert entre les blocs logique (interconnexions) à l'intérieur de celui-ci.
En regardant de plus près on s'aperçoit pourtant que la fréquence de fonctionnement du GPU est 2 fois plus petite que celle du CPU et 3 fois plus grande que celle du FPGA... Et toc dans les dents les pro de l'overclocking qui s'amuse à augmenter les fréquences!!!
Donc l'évolution du CPU est le GPU... et l'évolution du GPU est le FPGA... 
Je me suis trompé hier : C'est pas 3To/s mais 3Tflops. Bref même en divisant par 8, toujours supérieur et un CPU x86 haut de gamme développe dans les 100Gflops environ (petit exemple à l'appui). En tout cas j'insisterai sur les 2 points en rouge.
Bien sûr que OUI, le type de calcul est important et ce que tu utilises aussi (c'est ce qu'on appelle l'optimisation). Sur du calcul en texel (calcul par rasterisation) : Un CPU atteint les 5 GT/s, là où un GPU équivalent atteint les 50GT/s. Soit 10 fois supérieur, c'est loin du 3 fois plus que tu annonces pour l'écart entre CPU et GPU.
Mis à part cet exemple, il y a aussi les calculs arithmétiques simples, les calculs en virgule flottante (quelle limite on prend ? 32/64/128 bits ?) et surement d'autres que j'oublie.
Sur calcul en virgule flottante on est à presque 30 fois supérieur (presque 3Tflops par les unités de shaders pour le GPU et 100Gflops pour le CPU). Encore une fois, c'est loin du 3 fois plus que tu annonces.
D'autres part, une GTX285 est clairement pas un bon choix pour ce genre de test en calcul arythmétique. Même NV ne met pas ce genre de GPU dans les supercalculateurs (car très orienté calcul sur textures) et même les Tesla (GPU NV pour supercalculateur) n'ont pas l'étoffe pour avoir un bon rendement par GPU. Le seul point pour lequel e GPU a été choisi est essentiellement qu'il supporte CUDA, manière la plus simple d'éviter le langage assembleur quand on y connait rien.
Voici les petites erreurs que j'ai noté sur le matériel. Maintenant passons au logiciel. Pour mesurer, ces différences je suppose que le mec a utilisé un programme de test qui fait office de benchmark. Est ce que le FPGA possède les registres suffisants pour supporter un programme en langage C ? Le GPU choisi supporte CUDA (plus connu sous le langage Cg, qui est une librairie d'extension du C englobant les instructions assembleurs). Quoiqu'il en soit le programme d'exécution ne sera pas le même sur CPU, GPU et FPGA. Quand à dire que CUDA est fiable (matériellement comme logiciellement), aujourd'hui il est grandement remis en cause puisque PhysX semble partir aux oubliettes dans beaucoup d'applications. Cela devient donc injustifié de dire :
This result was reached after a short design-cycle of 2 man-days, which indicates that the NVIDIA CUDA platform allows for rapid development and optimization of applications that make substantial use of all available GPGPU computing resources
En plus, développer en 2 jours avec toutes les optimisations nécessaires et toutes les réflexions sur le plan matériel comme logiciel que la conception de ce genre de test amène, c'est vraiment n'importe quoi (raison de plus s'il est au MIT).
Attention Flo je parle de rapidité (temps de calcul) et non de quantité de calcul!!
Attention encore : Sur un FPGA le nombre de calcul/s dépend du design que tu mets dans le FPGA, prenons un petit exemple si je prends le même FPGA que lui (480I/O). Je design 1 signal d'entrée 479 sorties, avec à l'intérieur 479 porte NON=> Résultat j'ai 479 bits calculés/ cycle d'horloge!!! Et là j'explose ton nombre de Tflop/s sans forcé sur l'horloge!
Je dis que peu importe la complexité du calcul, tant que tu compares la même chose. Je suis conscients que suivant le type de calcul (signed, unsigned, FFT, multiplication, racine, puissance...) on obtiendra des résultats différents en fonction du composant. Pourquoi??? Son architecture et la façon dont il a été conçu (en dur sur le silicium)!!
Ensuite tu parles du composant de Nvidia, bon là j'avoue que je ne suis pas comme vous, je ne regarde pas les classements meilleurs chipsets graphique... A vrai dire je m'en fou un peu!!
Cependant tu m'indiques que le GPU utilisé par le chercheur n'est pas le meilleurs (apparemment loin de là)... Maintenant voici ma réponse, l'article à été écrit en mi-2009, le temps de penser à la manip, la concevoir... minimum 6 mois. Il a du prendre les composants qu'il connaissait sur le marché!
Tu te plains des perfs de ton GPU, laisse moi me plaindre alors du choix du FPGA! Pourquoi il n'a pas prit la version supérieur (voir premier message qui à ouvert ce sujet de discussion). Fréquence 3x plus élevé, plus de logique, plus de blocs mathématiques, plus de mémoire!!!!
Maintenant passons à ta réponse pour le logiciel! Bon j'avoue je ne suis pas un dieu en programmation...
Mmmmh qu'appelles tu registres pour le langage C? Parce que là moi je suis perdu!
J'ignorais devoir rappeler que le langage de programmation (peu importe le langage), celui ci est traduit en assembleur qui lui est traduit en données numériques... Bizarrement quand tu lances: if (A==0 AND B!=A) dans le pipeline tel quel. Je ne sais pas pourquoi mais si tu ne le traduis pas, il n'y arrive pas!! Grand scoop pour tous les informaticiens!!!
Effectivement il a prit ce composant car il peut le programmer facilement et franchement avec un langage assembleur (ou presque) par composant on se rend vite compte que l'on ne peut pas toujours programmer en assembleur! Perso je connais une dizaine de processeurs mais seulement 3 langages assembleur... Parce que la différence avec toi c'est que nous ne sommes pas payer uniquement pour programmer, on doit faire tout ce qu'il y a autour!!
Tu dis que le code sera différent en fonction du composant, sans blague!! et pourquoi? Mince je l'ai dit juste au dessus (pas le même langage assembleur).
Voir même si l'on se débrouille bien avec le FPGA on a même pas besoins de code assembleur! Bon le hic c'est que l'on sera bloqué pour faire les mêmes calculs tout le temps... Enfin après on peut parler de reconfiguration dynamique qui consiste à reconfigurer une partie du FPGA alors qu'il est en fonctionnement (technique difficile à maitriser)...
