Afin de terminer notre série de billets, voici quelques réflexions et perspectives que nous ressortons de l’étude.

Le modèle d’exécution sur FPGA possède des différences fondamentales avec le modèle d’exécution GPU. Le portage d’un kernel d’une architecture à l’autre n’est pas transparent et peut nécessiter un travail conséquent, notamment sur les phases d’optimisation.

Sur GPU, la méthodologie et les outils actuels permettent de converger progressivement vers un résultat meilleur que le précédent et ainsi cibler des bottlenecks successives: on est plutôt bien guidés. Sur FPGA, il est coûteux d’itérer sur un nouveau design, et le grand nombre d’optimisations possibles (différant par leur nature et paramètres) pose une difficulté. Cette dernière est en effet complexe de par notre position de découverte de l’environnement et notre manque d’expérience qui ne nous a pas encore permis de tirer le meilleur profit des outils du SDK. Il est difficile de tirer une méthodologie itérative d’optimisation dans ce contexte. Dans le premiers cas, l’équivalent de 3 jours-homme pour 3 experts semble permettre de se rapprocher des implémentations tirant le meilleur parti du GPU. Sur FPGA, l’équivalent de 20 jours-homme, incluant la découverte, n’a permis que de nous amener à une exploration partielle de l’ensemble des possibles, parfois orientée par des décisions arbitraires.

Nous avons laissé inexplorées beaucoup de pistes et de variantes, faisant face à un processus itératif de compilation coûteux et n’ayant probablement pas pu nous orienter au mieux grâce à la quantité d’informations produite par le SDK d’Altéra, au-delà de nos compétences actuelles. En particulier, nous n’avons pas obtenu un rapport de compilation tel que décrit dans le document Altera (donnant du feedback sur le succès ou non d’unrolling de boucles, de vectorisation de certaines instructions …) qui nous aurait été d’une grande aide.

Après l’ensemble de ces tests, munis d’une meilleure compréhension de l’architecture, l’envie est de continuer à itérer sur des design en extrayant le maximum d’informations du profiler. On a également envie d’essayer d’autres directions plus élaborées faisant appel à des fonctionnalités non évoquées dans ce document telles que l’expression de l’application en différents kernels single-workitem ou vectorisés liés par un channel / pipeline de données, sur cluster FPGA… Mais cet effort doit impérativement être mis au service d’une méthodologie pour lui permettre de naviguer efficacement dans l’univers des optimisations possibles. Le risque étant de s’enfermer dans un périmètre réduit d’optimisations et d’ignorer certaines pistes plus générales.

On regrette notamment de ne pas avoir réussi à obtenir plus d’aide de Bittware et Altera : ceci a eu un impact évident sur notre capital temps. Les documentations Altera sont bien fournies, mais sans méthodologie et bonne compréhension des outils du SDK, il reste difficile de s’orienter. Bittware nous a très souvent suggéré de s’adresser à Altera, dont les réponses à nos questions – souvent essentielles – proviennent des utilisateurs de leur forum.

Au-delà de ces points, le modèle d’exécution FPGA nous permet d’avoir une meilleure idée du type d’applications appropriées à cette architecture. Inversement, il suscite les questions suivantes, pertinentes pour beaucoup dans le calcul scientifique et parallèle :

• Les limites en ressources logiques et mémoire sont-elles prohibitives pour des applications de taille conséquentes? En particulier, les applications itératives dont le nombre d’itérations est élevé ou inconnu (critère d’arrêt/convergence) feront-elles un usage efficace du FPGA?
• Sur des applications parallèles à control flow non-trivial (pouvant rendre la vectorisation complexe sur FPGA), à quel point peut-on concurrencer les implémentations GPU, tirant naturellement parti des instructions SIMT? Cela vaut-il l’investissement en temps et argent?

Qu’en est-il de la performance des applications en flottants, avec les cartes FPGA récentes? Il serait particulièrement intéressant de regarder des applications parallèles du type Monte-Carlo sur des produits financiers non-triviaux, de la recherche d’optimum, ou encore à la résolution de problèmes d’EDP en temps et espace.

En outre, quelles sont les perspectives pour l’augmentation de la largeur des opérations SIMD ? La vectorisation est-elle réellement un point essentiel de la programmation FPGA ?

Enfin, nous nous sommes restreints à l’efficacité du kernel seul : mais on aurait aimé considérer un peu plus l’aspect I/O host-device (déjà prépondérant dans la pertinence de l’utilisation d’un GPU). Plus généralement, nous souhaiterions étudier l’impact du choix de l’architecture sur une application entière, peut-être même composée de plusieurs appels de kernels différents. En effet, les transferts de données et le temps d’initialisation du device jouent un rôle d’autant plus important que le kernel est efficace.

Merci de nous avoir suivi tout au long de ces – parfois très longs – billets. A bientôt !

Crédit : Damien DUBUC