Les compilateurs supportant OpenACC.

Si CAPS Entreprise supporte le Xeon Phi d’Intel avec son compilateur source-à-source, ce n’est pas le cas de NVIDIA-PGI ou de Cray. Savez-vous pourquoi ?

En réalité, PGI a déjà démontré le support des trois accélérateurs NVIDIA, AMD et Intel. Je ne connais pas le planning de sortie officielle de leur compilateur pour Xeon Phi mais j’ai pu voir en une démonstration et donc je vous confirme qu’il existe. S’agissant de Cray, qui construit des systèmes avec les deux types d’accélérateurs, le besoin des clients est réel. Sachant qu’ils ne peuvent pas l’ignorer, il faudra leur poser la question…

Pouvez-vous évaluer l’état d’adoption d’OpenACC à ce jour ?

OpenACC est largement utilisé dans le monde académique et les organisations gouvernementales, pour différentes applications telles que la climatologie ou la météo, la modélisation moléculaire ou chimique, etc. Mais je n’ai pas de chiffres exacts concernant le nombre d’utilisateurs. Je fais partie du comité lié au standard mais je ne suis pas lié aux éditeurs de compilateurs, de sorte que je n’ai pas de liens directs avec les utilisateurs finaux. Je ne sais pas dans le détail comment ils achètent le compilateur et comment ils l’utilisent ensuite dans leurs codes de développement. Je dois d’ailleurs rester neutre et apprécier les efforts de tous les éditeurs. Il y a parfois des différences et je m’efforce à ne faire aucune comparaison entre eux. C’est avant tout à eux de se différencier.

Mais, pour aller au-delà de la question précédente, comment OpenACC peut-il accroître son nombre d’utilisateurs/développeurs ?

Nous menons un certain nombre d’actions pour développer l’usage d’OpenACC. Oscar Hernandez de l’ORNL, un des directeurs d’OpenACC, est en charge de son adoption auprès des développeurs. Nous avons par ailleurs pas mal de “membres académiques” – un statut facile à acquérir dans la mesure où le coût d’adhésion est négligeable. Parmi eux, certains possèdent leur propre compilateur de recherche. Ils s’en servent pour déterminer la meilleure utilisation possible des directives. Barbara Chapman, de l’université de Houston, par exemple, est impliquée dans ces standards depuis des années. Elle préside également cOMPunity, la communauté de chercheurs et de développeurs OpenMP du monde académique et industriel. Ils développent le compilateur OpenUH de l’université de Houston qui est un bon exemple d’outil Open Source académique. Ils ont également développé une suite de tests pour OpenACC et, avec PGI et Cray, ils contribuent à SPEC ACCEL, un benchmark de la suite SPEC, qui utilise maintenant OpenACC.

Mais puisque vous mentionnez les développeurs, il y a deux raisons essentielles qui nous poussent à les rencontrer. D’une part, ces rencontres sont utiles pour discuter du standard : comment le faire progresser afin d’adresser des sujets tels qu’un meilleur modèle de programmation des accélérateurs en C++, comment mesurer la performance des accélérateurs, quelles métriques de performance devraient utiliser des outils de profiling comme TAU ou Vampir… D’autre part, c’est aussi notre rôle que de les aider à déterminer comment porter leurs codes selon leur problématique. C’est ce que nous faisons au travers de workshops dédiés par exemple au climat ou aux recherches pétrolières, qui sont organisés chez nos partenaires académiques ou gouvernementaux.

Quelles sont les fonctions clés sur lesquelles le consortium travaille actuellement ?

La fonctionnalité la plus importante est le support du deep copy et de tous les types dérivés. Nous améliorons également le support de débogage de manière à ce que les débogueurs de clusters comme Allinea DDT et TotalView fonctionnent mieux. Comme je l’ai précisé lors d’une question précédente, nous avons aussi cet effort en cours avec GCC. J’aimerais pouvoir annoncer une nouvelle “version pour commentaires” en juin, à l’occasion d’ISC’14, mais je ne peux pas le confirmer tant ce travail dépend du comité technique. Ce qui est sûr c’est qu’elle sera publiée d’ici à la fin de l’année. Sachant que PGI, Cray et CAPS collaborent déjà avec Allinea, RogueWave et les équipes de Vampir et de TAU, il est possible pour eux de travailler sur des versions intermédiaires de leurs outils et d’en finaliser une avant que le standard ne sorte officiellement.

Quel peut être l’avenir d’OpenACC si les accélérateurs sont directement intégrés dans les puces comme c’est le cas pour le processeur Fusion d’AMD, c’est-à-dire sans qu’ils aient à gérer les mouvements de données ? OpenACC peut-il évoluer en un modèle distribuant les charges de calcul sur les cœurs avec des fonctions dévolues au placement des données ?

Oui, il y a matière à ce que le développeur puisse indiquer où les données doivent résider pour s’assurer qu’elles soient les plus proches possible des unités de calcul qui les traitent. Etant supposé portable, OpenACC se doit de supporter ces architectures avancées au même titre que les architectures x86 plus traditionnelles, qui sont toujours les plus utilisées.

A votre avis, OpenACC sera-t-il utilisé avec les prochaines machines exaflopiques ?

Bien sûr qu’il le sera. Mais la façon dont il le sera dépend la fenêtre de tir considérée. Supposez que, d’ici à quatre ans, les accélérateurs commencent à ressembler aux CPU. Il y aura alors moins de justification à ce que les deux standards – OpenACC et OpenMP, coexistent. Cela dit, la raison d’être d’OpenACC étant d’apporter de bonnes performances sur les accélérateurs, il se peut que les fonctionnalités développées dans les compilateurs OpenACC apportent toujours de meilleures performances. Vous savez, nous n’essayons pas d’être OpenMP. Pour toutes sortes de bonnes raisons, il est possible et restera possible de mixer OpenMP et OpenACC.