211service.com
Visuels de superordinateur sans puces graphiques
Avant l'apparition des puces de traitement graphique spécialisées, les pionniers dans le domaine de la visualisation utilisaient des superordinateurs multicœurs pour réaliser des données en trois dimensions. Aujourd'hui, cependant, la vitesse à laquelle les superordinateurs peuvent traiter les données dépasse rapidement la vitesse à laquelle ils peuvent entrer et sortir ces données. Les clusters de traitement graphique deviennent obsolètes.

Effondrement du noyau : Cette image – étape 1492 d'une simulation d'une supernova à effondrement du cœur – a été générée sur le super ordinateur du Laboratoire national d'Argonne, Intrepid, sans l'utilisation d'un cluster graphique.
Des chercheurs du Laboratoire national d'Argonne et d'ailleurs travaillent sur une solution. Plutôt que de déplacer des ensembles de données massifs vers un cluster de traitement graphique spécialisé pour le rendu, comme c'est le cas actuellement, ils écrivent un logiciel qui permet aux milliers de processeurs d'un superordinateur de faire eux-mêmes la visualisation.
Tom Peterka et Rob Ross, informaticiens au Argonne National Laboratory, et Hongfeng Yu et Kwan-Liu Ma de l'Université de Californie à Davis, ont écrit un logiciel pour Intrepid, un superordinateur IBM Blue Gene/P, qui contourne le cluster de traitement graphique. entièrement. Cela nous permet de [visualiser les expériences] dans un endroit plus proche de l'endroit où résident les données, sur la même machine, explique Peterka. La solution de son équipe évite d'avoir à déplacer les données de l'endroit où elles ont été générées vers un cluster d'ordinateurs secondaire.
Les données de test de Peterka, obtenues à partir de Jean Blondin de l'Université d'État de Caroline du Nord et Anthony Mezzacappa du Laboratoire national d'Oak Ridge, représentent 30 étapes séquentielles dans la mort explosive simulée d'une étoile et sont typiques du type d'informations qu'un superordinateur comme celui d'Argonne pourrait traiter. Le plus grand test de Peterka avec les données a atteint une résolution tridimensionnelle de 89 milliards de voxels (pixels tridimensionnels) et a donné des images bidimensionnelles de 4 096 pixels de côté. Le traitement des données nécessitait 32 768 des 163 840 cœurs d'Intrepid. Des images bidimensionnelles ont été générées avec un algorithme de rendu de volume parallèle, une approche classique pour créer un instantané bidimensionnel d'un ensemble de données tridimensionnel.
Normalement, la visualisation et le post-traitement des données générées par Intrepid, qui, avec 557 téraflops, est le septième superordinateur le plus rapide au monde, nécessite une unité de traitement graphique distincte appelée Eureka. (Un téraflop équivaut à mille milliards de calculs par seconde.) Construit à partir de GPU NVIDIA Quadro Plex S4 (unités de traitement graphique), Eureka fonctionne à 111 téraflops. Les supercalculateurs plus puissants, de l'ordre du pétaflop, présentent des défis encore plus importants.
Plus nous allons gros, plus le problème est limité par [les vitesses d'entrée/de sortie], dit Peterka. Le simple fait d'écrire sur le disque la quantité de données produites par une simulation exécutée sur un supercalculateur pétaflopique pourrait prendre un temps déraisonnable. La raison est simple : d'une génération de supercalculateur à l'autre, la capacité de stockage et la bande passante de stockage n'augmentent pas aussi vite que la vitesse de traitement.
Cette disparité signifie que les futurs centres de calcul intensif pourraient tout simplement ne pas être en mesure de se permettre des unités de traitement graphique distinctes. À pétaéchelle, [les unités de traitement graphique séparées] sont moins rentables, selon Hank Childs , ingénieur en systèmes informatiques et expert en visualisation au Lawrence Berkeley National Laboratory. Childs souligne qu'un cluster de visualisation dédié, comme celui du supercalculateur Intrepid d'Argonne, coûte souvent environ 1 million de dollars, mais à l'avenir, ce coût pourrait être multiplié par 20.
Pat McCormick, qui travaille sur la visualisation sur le supercalculateur le plus rapide au monde, l'AMD Opteron et le Roadrunner IBM Cell-powered au Laboratoire national de Los Alamos, déclare que le travail de Peterka sur la visualisation directe des données est essentiel car ces machines deviennent si grosses que vous ne pas le choix. Les méthodes de visualisation existantes basées sur GPU continueront de ne convenir que pour certains types de simulations, dit McCormick.
Si vous allez consommer un supercalculateur entier avec des calculs, je ne pense pas que vous ayez le choix, dit McCormick. Si vous travaillez à cette échelle, vous devrez faire le travail sur place, car cela prendrait une éternité pour le déplacer, et où d'autre pourrez-vous traiter autant de données ?
Peterka, McCormick et Childs envisagent un avenir dans lequel les superordinateurs effectueront ce que l'on appelle un traitement in situ, dans lequel les simulations sont visualisées au fur et à mesure de leur exécution, plutôt qu'après coup.
L'idée derrière le traitement in-situ est de contourner complètement les E/S, explique Childs. Vous n'écrivez jamais rien sur le disque. Vous prenez des routines de visualisation et les liez directement au code de simulation et générez une image au fur et à mesure.
Cette approche n'est cependant pas sans embûches. D'une part, il faudrait une seconde entière ou plus pour rendre chaque image, excluant la possibilité d'interagir avec des modèles tridimensionnels de manière naturelle. Un autre écueil est le fait qu'interagir avec les données de cette manière brûle des cycles sur les mainframes les plus chers du monde.
Les superordinateurs sont des ressources incroyablement précieuses, note Childs. Que quelqu'un fasse une simulation, puis interagisse avec les données pendant une heure, c'est une ressource très coûteuse à prendre en otage pendant une heure.
Alors que les ordinateurs de bureau suivent les superordinateurs et les GPU dans le monde des cœurs multiples et du traitement massivement parallèle, Peterka spécule qu'il pourrait y avoir une tendance à s'éloigner des processeurs spécialisés pour des fonctions particulières. Déjà, AMD propose la bibliothèque de code OpenCL, qui permet d'exécuter du code conçu pour un GPU sur n'importe quelle puce x86 – et vice versa.
Xavier Cavin, fondateur et PDG de Scalable Graphics, une entreprise qui conçoit des logiciels pour les plus grandes unités de traitement graphique utilisées par les entreprises, souligne que le tout premier algorithme de rendu de volume parallèle fonctionnait sur les processeurs d'un supercalculateur. Après cela, les gens ont commencé à utiliser des GPU et des clusters de GPU pour faire la même chose, dit Cavin. Et maintenant, cela revient aux processeurs. La boucle est bouclée.