Stampede, votre navire amiral, est classé numéro 7 dans le dernier classement Top500. Il est aussi l’une des plus puissantes machines basées sur Xeon Phi. Pourquoi avoir choisi cette architecture ?

Nous avons imaginé Stampede comme un système complet. Ce choix répond en partie au RFP (Request For Proposal) de la NSF qui contenait deux exigences. L’une était de proposer une machine de base qui réponde le plus largement possible aux besoins de la communauté HPC aux Etats-Unis ; l’autre était de proposer un système innovant permettant d’expérimenter sur un plan technologique. C’est pour ces deux raisons que nous avons choisi Xeon Phi. A l’époque, nous devions remplacer deux systèmes en cours de déclassement qui répondaient chacun à des exigences différentes de la part des utilisateurs : Ranger au TACC et Kraken au National Institute for Computational Sciences.

Ainsi, concrètement, Stampede est la combinaison de deux sous-systèmes. Le premier est une architecture à l’échelle de Ranger (un environnement familier pour la plupart de nos utilisateurs) constitué de 100 000 cœurs Xeon traditionnels pour environ 2,2 Pflops. Le second est un sous-système accéléré de 7,4 Pflops. Une telle dualité permettait à la fois la production et l’expérimentation – ce qui n’était pas le cas avec Ranger. Et par ailleurs, nous avons conçu les nœuds de telle sorte qu’ils contiennent beaucoup de mémoire – jusqu’à 1 To – car il s’agissait d’un besoin exprimé par nos utilisateurs.

Nous avons aussi intégré à l’intérieur de ce système des GPU pour pouvoir faire de la visualisation sans avoir à déplacer les données. Et, bien évidemment, nous nous sommes efforcés de créer un système de fichiers solide parce que certaines applications en sont très dépendantes.

Pour revenir à Xeon Phi plus spécifiquement, la question centrale aujourd’hui pour la plupart des systèmes HPC est la puissance électrique requise. Comme tout le monde, nous avions besoin d’un système qui se caractérise à la fois par une meilleure capacité de calcul et par une meilleure efficacité énergétique. Nous avons donc étudié dans le détail un grand nombre d’options, notamment les GPU et les solutions à base de FPGA, et c’est la solution Xeon Phi qui nous a semblée la plus prometteuse compte tenu du temps qui nous était imparti et de notre capacité de financement. Au même titre que les GPU, Xeon Phi impacte très favorablement la courbe de puissance, avec un modèle énergétique plus efficace. De plus, Xeon Phi préserve le modèle de programmation d’un grand nombre de nos utilisateurs. Il y a certes des efforts à fournir pour utiliser pleinement ses ressources, tout comme pour les GPU d’ailleurs, mais les langages et outils de programmation – pour nous principalement OpenMP avec Phi – sont très semblables à ceux que nous incitons notre communauté à utiliser. Un système de base avec des Xeon représentait ainsi une sorte de progression naturelle. Nous savions que nos utilisateurs pourraient l’utiliser dès le premier jour et profiter ensuite de l’autre sous-système à base de Xeon Phi pour préparer la migration de leurs codes sur les futurs systèmes.

A combien de nœuds sont connectés les Xeon Phi ?

Nous avons un Xeon Phi connecté à chacun des 6400 nœuds du système de base, mais 440 de ces nœuds contiennent deux accélérateurs. Au total, cela représente 6840 Xeon Phi en service – plus quelques-uns supplémentaires en réserve.

Au regard de votre expérience, quels sont les avantages et les inconvénients de Xeon Phi ? Et, d’un autre point de vue, pourquoi avez-vous préféré Xeon Phi aux GPU ?

L’avantage premier est évidemment le fort potentiel de performance. Nous avons quelques applications où, par rapport à la taille du système, le niveau de performance est tout simplement stupéfiant. L’autre avantage est que Xeon Phi permet de préserver le modèle de programmation traditionnel OpenMP et MPI. Le fait qu’il soit plus facile de démarrer sur Xeon Phi est un avantage considérable pour nos utilisateurs. Migrer puis exécuter du code sur Xeon Phi est finalement assez rapide.

L’inconvénient est que, comme tous les coprocesseurs ou accélérateurs, Phi est beaucoup plus sensible à la qualité de codage. Pour s’exécuter efficacement, le code doit être bien vectorisé. Par ailleurs, si vous utilisez Phi en mode natif, c’est à dire comme un nœud à part entière, alors le problème devient la quantité limitée de mémoire RAM embarquée sur la carte. Les 8 Go de RAM pour 61 cœurs de processeur constituent un ratio auquel nos utilisateurs ne sont pas habitués.

L’autre problème est la connexion au bus PCI. Cela rend la conception du réseau d’interconnexion plus complexe et le système de fichiers plus compliqué à mettre en place. Pour faciliter cela, nous avons construit plusieurs systèmes de fichiers directs, avec pour conséquence que les performances sur le nœud hôte ne sont pas exactement les mêmes. L’option alternative est d’utiliser le mode offload pour éviter le problème de la taille de la mémoire RAM ou celui des accès aux systèmes de fichiers différents. Dans ce mode, une partie du code s’exécute sur le nœud hôte et une autre partie sur le Xeon Phi, selon le même modèle qu’avec les GPU. Et bien sûr, l’inconvénient est ici tout le travail nécessaire pour obtenir un code capable de s’exécuter efficacement à distance. Il faut penser aux transferts de données entre le nœud hôte et l’accélérateur et vice versa, mais aussi traiter le partitionnement du code entre le segment qui s’exécute sur le nœud hôte et celui qui s’exécute sur l’accélérateur. Voilà, grosso modo, les inconvénients actuels de Xeon Phi et des GPU : les difficultés d’exécution à distance, la mémoire limitée et le positionnement du mauvais côté du bus PCI.

À votre avis, quelles améliorations conduiraient à une utilisation plus efficace de Xeon Phi ? En d’autres termes, quels sont les obstacles que vous aimeriez voir sauter dans les générations à venir ?

Nous sommes dans une sorte de transition avec tous ces systèmes hybrides. Le mode accélérateur sur PCI est une façon de démarrer et de déployer rapidement cette technologie. Mais les prochaines années – tous les grands fournisseurs l’ont déjà annoncé – vont voir émerger un modèle où cette l’accélération sera directement intégrée au processeur.

Les accélérateurs à mémoire limitée rattachés au processeur hôte par le bus PCI vont disparaître d’ici une à deux générations de systèmes. Il en découlera la disparition de toutes ces barrières que sont le chargement et le téléchargement du code et des données, la limitation mémoire et les systèmes de fichiers complexe. Tout cela va disparaître au fur et à mesure que nous irons vers une conception plus propre, non hybride, des systèmes.

La question sera alors de savoir d’où provient le maximum d’efficacité énergétique et où situer le curseur entre complexité logicielle et complexité matérielle. En revanche, ce qui est clair c’est qu’avec tous ces processeurs, nous aurons toujours plus de cœurs et des vecteurs plus longs. Les comparaisons entre technologies seront à la fois plus fines et plus faciles une fois que tout sera intégré, qu’on pourra booter directement un nœud Xeon Phi, un nœud Xeon, un GPU, un nœud AMD Fusion, le nouveau nœud Array Micron ou n’importe quelle autre proposition technique. On n’aura plus à gérer tous ces artifices issus des systèmes hybrides qui ralentissent les performances. J’encourage d’ailleurs tous ceux qui codent aujourd’hui à intégrer l’idée qu’on disposera bientôt de plus de cœurs, de plus de threads et de vecteurs plus longs. C’est probablement ce à quoi ressembleront les systèmes dans deux à trois ans.

Pensez-vous qu’il soit possible d’extraire autant de parallélisme des applications ?

Dans de nombreux cas, oui. Ce n’est certainement pas trivial et toutes les applications ne passeront certainement pas à l’échelle du demi-million ou du million de threads. Mais si vous regardez l’histoire du parallélisme et remontez plusieurs décennies en arrière lorsque les clusters ont vraiment démarré, quand on comparait les gros processeurs aux processeurs parallèles, la machine vectorielle Cray au processeur Cray massivement parallèle, les débats étaient exactement les mêmes, et ce d’autant que les applications étaient surtout séquentielles et très peu parallèles. Résultat, après plus de 25 ans d’existence, les clusters ont démontré qu’il y avait en réalité beaucoup de parallélisme potentiel. La vectorisation n’était pas la seule alternative, le multithreading aussi était possible. A chaque fois qu’un vrai virage technologique se profile, on affirme un peu trop facilement qu’il ne profitera qu’à peu d’applications. Au final, il s’avère que les gens sont plus intelligents et qu’ils trouvent finalement des solutions pour appliquer ces nouvelles technologies à un très grand nombre d’applications.

Ce qui est intéressant, c’est que, de nouveau, nous voilà à vectoriser sur Xeon Phi. Mais on oublie que dans les années quatre-vingt, la plupart des codes allaient dans le sens de la vectorisation plutôt que de la parallélisation. Aujourd’hui, la plupart de ces codes sont parallèles mais seraient prétendument moins vectorisables. En réalité, je ne pense pas que les fondements mathématiques aient beaucoup changé dans cet intervalle. Il est vrai qu’il y a des limites à la parallélisation de petits problèmes. S vous faites par exemple un assemblage de génome, il y a tellement de petits fragments à assembler que vous n’avez pas besoin d’une machine à un millions de processeurs. Des centaines voire des milliers suffisent. Nous sommes quasiment arrivés aux machines à un millions de cœurs aujourd’hui mais nous avons besoin d’un million de threads pour programmer la plupart des dix premières machines du Top 500.

Toutes les applications n’atteindront probablement pas l’échelle du million de threads mais, pour la plupart d’entre elles, vous pouvez arriver à la centaine de threads et pour quelques-unes vous pourrez utiliser ces nœuds massivement parallèles. Cela nécessitera un effort certain et il y aura toujours des applications à la traine, mais je pense que c’est tout à fait faisable.

Aujourd’hui, les architectures hybrides (CPU + GPU) semblent être la panacée de la communauté, et ce pour un certain nombre de raisons dont l’universalité et l’efficacité énergétique. Quelle est votre opinion à ce sujet ?

L’efficacité énergétique est vraiment ce qui nous a poussé vers ces modèles hybrides mais, comme je vous le disais plus haut, la définition actuelle d’hybride, celle où vous avez un processeur principal et un accélérateur sur du PCI, est temporaire. C’est une manière d’explorer ces nouvelles technologies à efficacité énergétique améliorée. Attention, ce travail exploratoire est très utile. Mais à son terme, la notion d’hybride actuelle va disparaître. Je serais vraiment surpris si en 2017 ou en 2018 les grands systèmes qui seront déployés soient hybrides au sens d’aujourd’hui.

L’aspect hybride continuera à exister mais au niveau du silicium. Il y aura des traitements parallèles de type GPU dans le silicium avec des unités de prétraitement, ou peut-être aussi un mélange sur la même puce de cœurs très rapides avec des cœurs moins rapides mais hautement parallèles. En tout cas, il n’y aura qu’un seul type de processeur, qu’une seule sorte de nœud. Nous n’aurons plus cette complexité hétérogène avec tous les déséquilibres qu’elle engendre. D’ici deux voire trois ans, nous devrons utiliser des sockets plus parallèles avec plus de concurrence et moins de complexité pour baisser la consommation électrique, ce qui est vraiment le créneau sur lequel sont positionnés Xeon Phi et les GPU. Le code devra alors être bien écrit parce que tous les mécanismes matériels pour parer au mauvais codage doivent disparaître si on veut pouvoir abaisser le nombre de transistors.

Pensez-vous que les processeurs tels que le Fusion d’AMD ou le Tegra de NVIDIA, bien qu’ils soient dédiés aux systèmes mobiles, pourraient être utilisés dans les systèmes HPC ?

L’objectif pour AMD et NVIDIA est d’aller dans cette direction. Intel a également annoncé que la prochaine génération de Xeon Phi s’exécutera de manière autonome. Chacun cherche à tout intégrer sur la même puce pour offrir des nœuds à la fois moins onéreux et capables de changer la courbe énergétique des processeurs traditionnels. La bonne nouvelle est que tout le travail que nous accomplissons aujourd’hui sur nos codes pour extraire un grand nombre de threads, pour allonger la taille des vecteurs et pour trouver du parallélisme, tout cet effort de migration sur des GPU ou sur des Xeon Phi sera bénéfique pour les futurs systèmes.