A l’ordre du jour :
• Les fondements d’OpenACC
• A propos de la fusion d’OpenACC avec OpenMP
• La performance portable des codes vs les spécificités des accélérateurs
• Les fonctionnalités clés de la prochaine spécification d’OpenACC

Propos recueillis par Stéphane Bihan

Monsieur Poole, pouvez-vous nous rappeler quels sont les fondements d’OpenACC ainsi que sa feuille de route?

OpenACC à démarré avec les travaux que nous réalisions en 2011 dans le cadre du sous-comité Accélérateurs d’OpenMP. Ces travaux, largement inspirés du compilateur PGI, étaient également basés sur les efforts de Cray au sein du laboratoire d’Oak Ridge. C’est durant cette période que nous nous sommes rendu compte que la publication d’extensions pour les accélérateurs par OpenMP allait prendre beaucoup de temps. Par ailleurs, nous n’étions pas satisfaits de la façon dont le problème était abordé, ce qui nous a conduits à rapidement ressentir le besoin de converger sans attendre OpenMP. En clair, il fallait que les développeurs commencent à utiliser un modèle. CAPS proposait un compilateur à base de directives depuis 2007 et PGI depuis 2008. Nous nous sommes alors groupés en association à but non lucratif et donnés pour mission d’unifier ces modèles en un seul, qui permette une programmation parallèle portable et performante. C’est de là, d’ailleurs, que vient le nom OpenACC.

NVIDIA, autre acteur important de l’équation, était alors principalement focalisé sur CUDA. Pourquoi ce virage vers les directives de programmation pour accélérateurs ?

L’utilisation de directives nécessite beaucoup moins de modifications des codes, ce qui les rend plus maintenables. Nous avions besoin d’offrir aux utilisateurs une autre manière d’utiliser les GPU. Il y avait les bibliothèques, il y avait CUDA et, entre ces deux modèles, nous avions tout simplement besoin d’offrir une alternative de programmation des GPU plus simple.

Comme vous le savez certainement, les directives OpenMP sont assimilées à des commentaires, en particulier en FORTRAN. Par conséquent, si vous compilez votre code avec un compilateur qui ne reconnaît pas ces directives, il les ignorera. C’est une excellente approche lorsque vous produisez des codes qui doivent s’exécuter sur plusieurs systèmes. OpenACC s’aligne parfaitement sur cet objectif : préserver la lisibilité et la portabilité tout en offrant la possibilité d’accéder à deux espaces mémoire, la mémoire du GPU étant distincte de celle du CPU. Ce modèle est sensiblement différent de celui que propose OpenMP, notamment pour ce qui est des mouvements de données mais aussi parce que les régions mémoires sont organisées différemment d’un accélérateur à un autre. Il est important de bien comprendre qu’un accélérateur se programme de manière différente, plus restreinte.

En quoi OpenACC se distingue-t-il d’OpenMP, et plus encore maintenant qu’OpenMP possède ses propres extensions pour accélérateurs ?

OpenMP permet de programmer les accélérateurs de deux façons différentes. Il y a d’une part le mode offload qui, une fois sur l’accélérateur, utilise les directives OpenMP standards. Cela pose problème dans le cas d’accélérateurs possédant plusieurs régions mémoire. D’autre part, NVIDIA a contribué (plus tard dans le développement d’OpenMP 4.0) à l’élaboration de la directive team qui offre un certain support pour exécuter du code sur tous types d’accélérateurs. Ce travail est toujours en développement et, parce que la plupart des membres d’OpenACC font aussi partie du comité technique d’OpenMP, OpenACC supporte également cet effort. En pratique, beaucoup de sujets sont discutés deux fois. Une première fois, plus orientée performance, au sein d’OpenACC et une deuxième fois au sein d’OpenMP. Mais OpenACC offre des fonctionnalités qui correspondent environ à deux années d’avance sur OpenMP, parce que les gens d’OpenMP mettent plus de temps à les développer. Pour vous donner une idée, nous travaillons aujourd’hui sur de nouvelles fonctionnalités intéressantes qui permettent d’améliorer les performances d’OpenACC notamment en C++. C’est un domaine qui focalise beaucoup notre attention actuellement.

Les utilisateurs peuvent-ils s’attendre à une fusion des deux modèles ? Et dans le cas contraire, OpenACC est-il appelé à devenir un standard de fait ?

Le modèle OpenACC est déjà un standard de fait ! Il suffit de regarder les nombreuses sessions qui lui sont consacrées [NDLR : à GTC’14]. Certaines de ces sessions discutent des différences entre les deux modèles, d’autres traitent de l’écriture de codes performants avec OpenACC et certains intervenants abordent nos travaux sur le C++ et le deep copy. Enfin, un nombre important d’autres sessions démontrent l’utilisation d’OpenACC dans différents types de codes, en particulier pour la modélisation du climat.

Et donc, pas de fusion ?

Il y a plusieurs façons de répondre à cette question. L’une est de dire qu’il ne doit pas y avoir de fusion parce qu’OpenMP regarde ce que fait OpenACC et choisit ensuite les fonctionnalités à intégrer – ce en quoi nous les aidons, soit dit en passant. D’un autre point de vue, GCC est en train de supporter OpenACC. Ce support sera implémenté dans la même branche de développement que celle qui supporte OpenMP. Il y a donc beaucoup de réutilisation de code entre les deux approches et, de ce fait, nous pouvons estimer qu’il existe déjà une fusion potentielle entre ces deux implémentations.