✎ developpement:activites:qualification:c4140[CBP]

✎ developpement:activites:qualification:c4140
Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Le C4140 : la puissance de 1 baie dans 1U, et de quoi effacer les autres C41 ======

{{ :developpement:activites:qualification:surveyc4140_fp3264.png?600|}}

{{ :developpement:activites:qualification:surveyc4140_applications.png?600|}}

===== Introduction =====

Tester toute à la fois la successeure de la Nvidia Tesla P100 et le nouveau "noeud" GPU de Dell, tel était l'objectif de cette mise à disposition par l'intégrateur. Nous verrons que la Tesla V100 est bien le "monstre" que certains ont déjà pu manipuler en France depuis 2 ans. Cependant, avec son intégration dans le C4140 qui en héberge 4, c'est un sacré budget qu'il faut débourser pour s'offrir la machine la plus puissante qu'il m'ait été donné de tester. Encore faut-il en avoir l'usage face aux autres solutions du marché. C'est ce que nous allons explorer...

===== Un peu d'histoire =====

Généralement, lorsqu'une première est un mauvais souvenir, chaque nouvelle expérience distille au début une certaine appréhension, surtout lorsque la suivante n'a pas été non plus très concluante. En matière de matériel informatique, quand il s'agit d'intégration, chaque présentation enthousiasmante laisse au mieux perplexe, au pire suspicieux. C'est effectivement l'expérience que j'avais des matériels Dell commençant par C41... 

==== Le C410X, la "fausse bonne idée" ====

Il y a 6 ans, je recevais en test pour la première fois un C410X et son fidèle Robin (ou Batman, tout dépend de quel côté on se place) C6100. La machine était impressionnante : dans 3U, la possibilité de mettre 16 GPGPU. A l'époque, Nvidia, dans sa génération Fermi, "offrait" 3 solutions : les Tesla M2050, Tesla M2070 et Tesla M2090. Des cartes comparables, essentiellement différentes par le nombre de cudacores (448 pour les deux premières) et 512 pour la dernière, des fréquences légèrement différentes également (de 1150 à 1300 MHz). Déjà, à l'époque, nous avions pu "juger" de l'opacité des tarifs de Nvidia (3GB de RAM à 400$). 

Le C410X était un boitier à l'alimentation autonome, effroyablement bruyant, disposant de 8 entrées/sorties PCIe. Dans la lignée du S0170 de Nvidia et sa liaison PCI Express sortante, Dell souhaitait offrir à ses clients une solution polyvalente permettant d'associer des GPGPU à des serveurs, pour tirer profit des (rares) codes de l'époque supportant le multi-gpu. Au final et malgré de nombreux tests, je n'ai disposé que de systèmes particulièrement instables, aux connecteurs très sensibles, avec souvent la nécessité, en cas de plantage d'un serveur avec un GPU, de redémarrer l'ensemble des 4 serveurs pour à nouveau réinitialiser toutes les cartes. Certes, Le matériel mis à disposition avait beaucoup voyagé, avait été largement démonté (voire dépouillé) de certains composants. Cependant, après de longues heures de mise à jours de tous les composants, il était possible de disposer d'un système exploitable, mais uniquement avec des cartes M2070 et M2090.

L'effroyable point faible du C410X ne nous fut révélé que quelques mois plus tard lorsque Nvidia sortit ses premiers circuits Kepler pour le calcul, avec les séries K20 et K40. Alors qu'il était tout à fait possible de rendre opérationnelle une Tesla K20 dans un logement de C410X, ce fut malheureusement la dernière. La K40 de format comparable n'était pas reconnue et la K80 ne disposait pas de l'alimentation suffisante. Autre souci de taille, la concurrence : déjà, à l'époque, certains codes de calcul se satisfaisaient "très bien" de la simple précision ; ainsi, les cartes de Gamer (GTX 780 en tête) offraient un rapport performance/prix très supérieur aux modèles Tesla (de l'ordre de 5 pour 1). Pour finir sur le bilan du C410X, il y avait une limitation qui, finalement, balayait tout l'intérêt de l'objet : la possibilité de pouvoir associer tel au tel GPGPU à telle ou telle machine. En fait, la matrice d'association noeud/GPGPU n'offre que quelques possibilités et cela passe nécessairement par une arrêt complet et un redémarrage de toute l'infrastructure : IPMI devient alors le commis indispensable pour son exploitation.

Après 6 ans et une escapade grenobloise, le C410x et son fidèle C6100 sont revenus au Centre Blaise Pascal. Longtemps équipé de seulement deux Tesla K20 et deux faux jumeaux M2070 et M2090, elle s'est vue amendée de 4 nouvelles cartes déclassées par le centre de calcul. Sa stabilité reste précaire mais suffisante pour de petites tâches, tant que les circuits Fermi les supportent.

==== Le C4130, et le malheur du Xeon Phi ====

Conscient que les liens externes PCIe ne posaient que des difficultés, et que le contrôle de la matrice noeud/GPU n'était pas assez "granulée", Dell a proposé son C4130 : une machine bi-socket, 1U, équipée directement de 4 GPU (ou 4 Xeon Phi Knight Corner). J'ai alors reçu en test la version équipée de (seulement) 2 Xeon Phi. Evidemment, l'intégration ne permettait aucune fantaisie sur les accélérateurs possibles : la matrice de compatibilité était d'une pauvreté assez accablante. Dans cette approche, la difficulté de prise en main était plutôt à imputer à Intel et son accélérateur si difficilement exploitable qu'il en devient inutilisable. Pour exploiter un Xeon Phi, il fallait déjà installer un environnement spécifique permettant de démarrer un OS sur la carte accélératrice. Une fois cet environnement démarré, 3 options s'offraient à l'utilisateur pour exploiter le Xeon Phi : cross-compiler son code et l'exécuter nativement sur l'accélérateur. C'est là que beaucoup ont découvert que 60 veaux à 1.25GHz sont moins efficaces que des double Sandy Bridge 8 coeurs à 3 GHz. Il y avait aussi, avec OpenMP4 (et évidemment le compilateur Intel), la possibilité d'exploiter le mode "offload" et la "décharge" d'un calcul sur l'accélérateur. Intéressant mais exigeant un régime de parallélisme optimal supérieur à 960 (16*60, comme c'est bizarre)... La troisième option, que j'ai largement exploitée, consistait à utiliser l'implémentation OpenCL fournie par Intel. Très efficace, tellement que c'est avec elle que j'ai obtenu, avec mes tests "maison", les meilleures performances. Le Xeon Phi était même, du temps des IvyBridge et des Kepler, supérieur à ces derniers si le régime de parallélisme était entre 1000 et 2000. Encore fallait-il s'y intéresser... Pour en revenir au C4130, il fallait donc, pour l'exploiter efficacement en OpenMP ou en OpenCL, s'adresser aux deux périphériques indépendamment, ce qui rendait le code, finalement, complètement spécifique à cette infrastructure. A l'époque, le soufflet du Xeon Phi était retombé : tous (ou presque) avaient expérimenté amèrement les performances catastrophiques sur leurs codes sans modification.

Au final, il n'y eut jamais la masse critique d'utilisateurs ou le temps ingénieur disponible pour pleinement exploiter cette approche. Le boitier, quant à lui, avait montré toute la pertinence d'une énorme intégration, mais le coût d'entrée (1 chassis et 4 accélérateurs) restait pour beaucoup rédhibitoire dans un marché où le GPGPU professionnel dépassait les 5000€, fixant l'ensemble à plus de 25000€. Parallèlement, d'autres solutions largement étaient plus polyvalentes ; les séries R720, R730 puis R740 offraient (et offrent) de 2 à 3 emplacements GPU ou GPGPU, avec comme perspective d'y placer (sans la garantie constructeur mais avec du papier sulfurisé) au moins 2 GPU de gamer 10 fois moins onéreux.

===== Le C4140, comment l'exploiter à distance ? =====

Pour la première fois, le matériel mis-à-disposition n'est pas livré : les ours polaires nous remercient de ce bilan carbine ! Pourtant, j'ai toujours attaché un soin particulier à pouvoir installer et exploiter mes propres outils sur les machines pour les évaluer. Si les cartes de supervision (même certaines très anciennes) offrent la possibilité d'avoir une console déportée complète (avec un mappage clavier assez pénible), toutes ne mettent pas à disposition les périphériques virtuels. Grâce à cet outil très utile, il est possible d'associer n'importe quelle clé USB ou image ISO au démarrage de la machine distante. Nous allons expérimenter ce "service" avec deux approches, la première par SIDUS, la seconde par une bonne vieille installation de la dernière Debian sortie en juillet 2019, la Buster.

==== SIDUS over Internet : pour ne plus jamais installer d'OS ====

Au delà du simple test de matériel, la mise à disposition d'un C4140 dans les locaux de Dell à Austin a donc été l'occasion de tester l'approche [[developpement:productions:sidus|SIDUS (Single Instance Distributing Universal System)]] distante. Dans sa dixième année d'exploitation au Centre Blaise Pascal à l'ENS-Lyon, dans sa huitième année au mésocentre lyonnais PSMN hébergé à l'ENS-Lyon sur plus de 500 noeuds, cette approche met à disposition une racine de système d'un unique NFS. Cela fonctionne comme avec un LiveCD en réseau, mais c'est reconfigurable "à chaud" et cela n'impose pas de "boot storm" au démarrage d'un cluster complet.

J'ai toujours détesté cuisiner chez les autres : en effet, dans un environnement "maîtrisé" (au minimum), les facteurs de variabilité dans les expériences sont légions. Mais exploiter un OS installé par un tiers, qui plus est, un intégrateur avec ses recettes "maison", cela ne me convenait pas spécialement. Dell m'a alors proposé la mise à disposition directe d'une machine avec son Idrac pour y installer ce que je voulais. Dans mon optique, c'était aussi l'occasion de tester SIDUS dans un environnement plutôt très contraint.

La première étape de SIDUS est de télécharger les noyau et initrd. Avec l'outil iPXE, il est possible de paramétrer simplement une image ISO, disquette ou clé USB pour pointer directement vers le bon serveur HTTP. Une fois ces composants téléchargés, le système démarre, crée le tunnel chiffré correspondant et monte le NFS à travers Internet. Si le premier démarrage a été laborieux, c'est essentiellement à cause des mécanismes de filtrage mis en place par Dell : en effet, tout montage NFS entraîne de nombreux accès réseau pour la récupération récurrente des attributs de fichiers et force est de constater que la limitation du réseau sortant en a été le principal obstacle à l'exploitation. Comme socle logiciel, j'avais choisi la Debian Stretch mais associée aux modules Nvidia et CUDA rétroportés. En effet, les circuits Volta et Turing exigent une version supérieure à la 390 embarquée dans les Debian Stretch. Les paquets rétroportés offrent une version 418 suffisante pour exploiter la machine. Pour l'environnement CUDA, le 9.2 est proposé en rétroportage, remplaçant le 8.0 standard. L'approche était fonctionnelle, mais incroyablement ralentie.

==== Retour à un système local ====

Si les premiers tests élémentaires ont été menés directement sur cette approche SIDUS, l'exploitation d'outils nécessitant de nombreux accès à des fichiers rendait son utilisation laborieuse. J'ai donc préféré déployer la dernière version de Debian, la Buster, fraichement sortie début juillet. Les caractéristiques de l'environnement Nvidia étaient comparables, notamment pour les versions des pilotes.

===== Premier examen du C4140 =====

L'examen de la machine commence alors par les traditionnels lscpu, lspci, lshw et, "last but not least" nvidia-smi. Pour la partie CPU, le noeud est équipé de 2 sockets Xeon Gold 6148 cadencés à 2400 MHz et disposant de 20 coeurs chacune.
Pour la partie accélérateur, le nvidia-smi offre la délicate vision de 4 Tesla V100 équipée chacune de 32 GB de RAM. Bref, sur les 512GB de RAM dont la machine est équipée, 1/4 est située dans les accélérateurs : simplement monstrueux.

{{ :developpement:activites:qualification:nvidia-smi_c4140.png?600 |}}

===== Le banc d'essai logiciel : pour se démarquer du LinPack =====

Evaluer la performance d'un système est une science. Et sa principale difficulté revient surtout à rendre la comparaison pertinente d'un système à l'autre. Ici, il s'agit d'évaluer la performance d'un accélérateur, la Tesla V100 et si possible la performance combinée de 4 d'entre elles dans un unique noeud. Nous pourrions nous rapprocher du Top 500 et son LinPack mais j'invite chacu d'entre vous a consulter les fils de discussion sur le sujet chez Nvidia. Nous pourrions aussi exploiter les suite Phoronix mais lesquelles choisir ? 

Nous avons choisi d'exploiter les programmes de test développés depuis 10 ans au CBP (en gros depuis que j'ai commencé à exploiter une antique Tesla C1060) et explorant les segments les plus classiques des machines de calcul :
  * le calcul matriciel (avec les fameuses fonctions xGEMM de la librairie BLAS ou un test "maison" exploitant 5 fonctions BLAS),
  * le parallélisme "gros grain" avec un Pi par Monte Carlo dont l'essentiel de la "charge" repose sur les générateurs de nombres aléatoires entiers (très pratique pour évaluer la différence de performance lorsque des opérations de comparaison et multiplication sont faites sur des entiers ou des flottants, sur 32 ou 64 bits),
  * le parallélisme "grain fin" avec un code N-Corps très largement reconfigurable (permettant d'évaluer la performance des accès mémoire dans des opérations très "denses" en calcul),
  * les accès mémoire via des fonctions atomiques (très pratiques pour éviter des mutex trop fréquents) avec un "postillonneur".

A noter que les codes Pi Monte Carlo, N-Corps et le "postillonneur" sont écrits en Python/OpenCL, ce qui assure un caractère parfaitement agnostique au modèle de programmation.

A notre batterie déjà fournie, nous avons intégré 3 codes "métier" :
  * un test basé sur TensorFlow et l'exploitation d'images CIFAR10,
  * un test de Gromacs (un outil de simulation de dynamique moléculaire)
  * un test de Hoomd.

En effet, pour clôturer nos investigations, il nous fallait un code relativement simple à intégrer qui soit multi-gpu. Hoomd en fait partie et l'annonce fièrement ! Les nombreux benchmarks avec leurs tableaux de comparaison nous permettront alors de comparer un unique C4140 avec ses 4 GPU à des architectures hybrides Cluster GPU.

==== Coup d'oeil dans le rétro : quels challengers pour la Tesla V100 ====

Avant de lancer notre banc de test, quels étaient nos "TOP1" dans la computhèque de 77 GPU et 42 CPU différents que nous avons au CBP ? La RTX 2080 Ti, arrivée en octobre 2018 au CBP, avait balayé la concurrence, reléguant la GTX 1080 Ti à presque un facteur 2. Elle était première sur presque tous les tests, mais seulement en simple précision. En double précision, longtemps, la Tesla P100 n'avait pas de concurrence. Qu'il s'agisse d'un xGEMM, d'un Pi Monte Carlo ou d'un N-Corps, elle reléguait les GTX et RTX à un facteur 10. La grosse surprise est venue au printemps 2019 avec la Radeon VII. Bien que moins dotée en coeurs que la Vega 64 (3840 au lieu de 4096) et avec une fréquence légèrement supérieure, la Radeon VII n'apparaissait pas aussi impressionnante que cela jusqu'à ce qu'elle soit exploitée sur le test N-Corps : elle pulvérisait la Tesla P100 d'un facteur 2. Test aussi intéressant : le "postillonneur" et ses opérations atomiques. Déjà, la Vega 64 se trouvait supérieure à toutes les cartes. Là, la Radeon VII règne également sans partage.

==== Comment la Tesla Volta V100 va-t-elle se comporter face à ces rivales de moins d'un an ? ====

=== Petit examen de la Tesla V100 : plus de 5000 ALU ! ====

Qu'avons-nous dans les entrailles de la "bête" ? Déjà, un "clinfo" nous indique que la Tesla V100 dispose de 80 unités de calcul, cadencées à 1530MHz. Dans la génération Volta (ou Turing), les "unités de calcul" ou "compute units" disposent de 64 cudacores, ce qui porte le nombre total de cudacores à 5120. En comparaison la RTX 2080 Ti dispose de 4352 cudacores à 1350MHz. Le rapport de l'un à l'autre nous fait espérer un gain de 33%. Par rapport à la Tesla P100 (3584 cudacores à 1126 MHz), la Tesla V100 devrait s'approcher d'un facteur 2 (1.94 pour être exact). Côté processeur, la machine est équipée de 2 processeurs Skylake Gold 6148 disposant de 20 coeurs et cadencés à 2400 MHz. Côté mémoire (anecdotique dans nos tests), 384 GB complètent la configuration "active".

La C4140 est donc bien une bi-myriALUs (Myriade, nombre de 10000) avec les plus de 20000 ALUs.

=== GEMM : petit clin d'oeil au shadering ===

Impossible de démarrer notre évaluation par autre chose que la multiplication matrice-matrice, la "source" de la puissance calculatoire des GPU ! Si vous en doutez, jetez donc un coup d'oeil sur la méthode classique de CGI (Computing Generated Image) par shadering et les opérations de transformations Model2World et World2View ! Là, nous constatons le bon considérable de la Tesla V100 face à la P100. Nous dépassons les 15 TFlops en FP32 et les 7.5 TFlops en FP64. C'est donc d'un facteur 2 que la V100 enfonce la P100 en simple et presque un facteur 3 en double précision. Si la RTX 2080 Ti résiste en simple, elle s'effondre en double, laissant les Tesla dépasser les 2 TFlops. La Radeon VII se contente d'approcher cette barrière sans la dépasser. Les processeurs traditionnels, même les plus récents et équipés des dernières unités vectorielles peinent à dépasser le TFlops en double précision. Définitivement, les Tesla règnent sans partage génération après génération sur ce segment du calcul grande précision...


{{ :developpement:activites:qualification:xgemm_c4140.png?600|}}


=== BLAS : pour élargir le spectre des fonctions algébriques ===

Le test suivant intégre 5 fonctions BLAS (xGEMV, xTRSV, xAXPY, xDNRM2, xSWAP pour les curieux) assemblées pour offrir un test consistant. Les familiers auront reconnus notamment la multiplication matrice-vecteur et la résolution de systèmed triangulaired. La Tesla V100 reste la première devant toutes les autres cartes, avec 25% de plus que la RTX 2080 Ti et plus d'un facteur 2 par rapport à la Tesla P100 (ce qui reste parfaitement cohérent). Les processeurs les plus performants restent au sol, avec des performances au moins 20 fois inférieures. Confirmation donc : les Tesla en général (et la V100 en particulier) règnent sans partage sur le calcul matriciel.

{{ :developpement:activites:qualification:xtrsv_c4140.png?600 |}}

=== Pi Monte Carlo, le classique à gros grain, offrant record et première ===

Le calcul de Pi par Monte Carlo est toujours le premier test que nous lançons dès qu'un périphérique de calcul quelconque se présente. Simple et aisément parallélisable, il "colle" plutôt très bien à la géométrie calculatoire d'un "moteur" de traitement d'information. Le résultat se présente comme un nombre équivalent d'itérations par seconde. A l'automne dernier, avec la RTX 2080 Ti, nous avions franchi un cap : celui des 500 Gitops (Giga ITerative Operations Per Second), soit 500 milliards d'itérations par seconde. 5 ans auparavant, nous en avions 10 fois moins. Et il y a 40 ans,  avec un 6809 et un Basic interprété nous offraient 50 itérations par seconde : soit un facteur de 10 milliards entre 1978 et 2018. Avec la Tesla V100, nous nous attendions à dépasser 600 Gitops. C'est chose faite. Par contre, nous ne nous attentions pas à "mettre" un facteur 3 à la Tesla P100 ! En double précision, étant donné que l'essentiel de la "charge" réside dans la génération de nombres aléatoires entiers sur 32 bits, les performances sont relativement comparables entre la simple et la double précision. Ce n'est pas le cas pour les GTX ou RTX, lesquelles "conservent" une performance divisée par 20 pour des calculs doublant la précision.

{{ :developpement:activites:qualification:pi_c4140.png?600 |}}

Ce calcul simple nous offre un record, mais pas une "première" ! Je recherche depuis longtemps un noeud (une machine à mémoire partagée) qui m'offre une puissance supérieure à 1 Titops (soit 1000 milliards d'itérations par seconde). En agrégeant la puissance de 2 RTX 2080 Ti, cela devait être possible à l'automne 2018, mais mes versions Pthreads et MPI plafonnaient à 970 Gitops sans franchir ce plafond. Ici, en cumulant les 4 Tesla V100 du C4140, j'obtiens près de 2.4 Titops : plafond pulvérisé. Je voulais aller sur la Lune, le C4140 m'envoie vers Mars !

=== NBody : le physique, simple mais extensible, à grain fin ===

Pour le code N-Corps, je m'attendais là encore à une démonstration. J'ai cependant été surpris lors de mes premières investigations. Généralement, je prenais comme référence un système de 32768 particules en intéraction gravitationnelle. Il est apparu que les cartes récentes n'atteignaient pas leur optimum de performance avec si peu de particules : j'ai donc "poussé" le nombre de particules à 1048576. Pour la petite histoire, à chaque pas, le nombre d'intéractions à cumuler dépasse les 1000 milliards, soit plus que le nombre de cellules que nous avons dans notre corps. Et une Tesla V100 effectue chaque pas en 19 secondes. Nous constatons par contre une explosion du ratio entre simple et double précision, même pour les Tesla ! Et, chose intéressante : si la Radeon VII reste un challenger crédible en double précision, Tesla V100 est toujours première.

{{ :developpement:activites:qualification:nbody_c4140.png?600|}}

=== Splutter : une exploitation "atomique" moins efficace ===

Le "postillonneur" se propose lui de comparer les accès mémoire en exploitant les fonctions atomiques d'incrémentation dans les zones mémoire. Dans notre test, nous manipulons un espace de 2GB dans lesquels nous "tapons" aléatoirement. Ici, première suprise : non seulement la Radeon VII conserve sa place mais reste deux fois plus performante que les Tesla P100 ou V100. Pire, la Tesla V100 se retrouve légèrement moins efficace que la Tesla P100. Pour la première fois dans nos tests, la Tesla V100 est derrière.

C'est donc là que s'arrête les tests "maison" que j'exploite chaque fois que je souhaite comparer les "moteurs" de calcul scientifique. La Tesla V100 tient donc toutes ses promesses : elle offre un gain de performances cohérent par rapport à son aînée, la Tesla P100 et elle reste complètement hors d'atteinte de ses consoeurs dédiées au jeu. Seule la Radeon VII la talonne en double précision sur un test et la surclasse sur un autre.

{{ :developpement:activites:qualification:splutter_c4140.png?600|}}

Passons maintenant aux programmes "métier".

=== Gromacs : des performances à (toujours) relativiser ===

Commençons par Gromacs. Depuis plusieurs années, ce logiciel de dynamique moléculaire a su tirer partie des GPU. Nvidia proposait même à chacun de refaire ses tests chez soi : https://www.nvidia.com/en-us/data-center/gpu-accelerated-applications/gromacs/ et c'est ce test là que nous allons exécuter.

Cependant, avant de nous précipiter, les performances (et leur comparaison) nécessitent un peu de recul, notamment sur le fait que Gromacs est (aussi) un programme hybride exploitant très efficacement les différents coeurs d'un noeud ou les différents noeuds d'un cluster ! L'introduction d'un GPU dans le "système", suggérait une légitime interrogation : quel est (réellement) l'apport de l'accélérateur ? Pour être le plus "honnête" possible, les tests effectués l'ont été dans 4 configurations d'exécution différentes : d'abord l'accélérateur et la totalité les coeurs exploités, puis l'accélérateur et un unique coeur exploité, ensuite la totalité des coeurs exploités sans accélérateur, enfin un unique coeur exploité.

Si nous regardons l'exploitation totale de chaque système (un accélérateur et tous les coeurs des CPU), nous avons presque un facteur 2 entre Tesla V100 et Tesla P100 : c'est parfaitement cohérent avec ce que nous avons déjà observé. Le gain de 1/3 entre la Tesla V100 et la RTX 2080 Ti est instructif. En effet, cela suggère que Gromacs, dans ce cas, s'accomode de la simple précision, sinon ce n'est pas un ratio de 1/3 par 1/20 que nous aurions ! A véritablement méditer en cas de fortes limitations budgétaires !

Néanmoins, si nous analysons la seconde exécution (accélérateur et un unique coeur utilisé), les performances restent comparables entre GTX 1080 Ti et Tesla P100. Cependant, la Tesla V100 accuse le coup : de 80% au dessus de la P100, elle se retrouve 40% au dessus. Face à la RTX 2080 Ti, elle passe de 40% au dessus à 20%. En fait, si nous avons une telle différence de puissance entre les configurations de la Tesla P100 et la Tesla V100, c'est essentiellement à cause de la différence des processeurs ! Il suffit de regarder la comparaison entre exécutions uniquement sur processeurs pour s'en convaincre ! A noter pour finir que le C4140 uniquement avec tous ses coeurs de processeur fait aussi bien qu'une unique Tesla V100 sur un coeur.

{{ :developpement:activites:qualification:gromacs_c4140.png?600|}}

Ainsi, quand un code "métier" est exploité comme comparateur entre accélérateur, veiller à ce que les configurations CPU soient comparables est une salutaire précaution !

Pour conclure sur Gromacs, alors que le programme est présenté comme multi-GPU, si des exécutions (et surtout une compilation spécifique) ont été réalisées, mais AUCUN GAIN significatif n'a été trouvé, et même pire : les calculs tournaient plus lentement en exploitant plusieurs Tesla V100 qu'une seule... Peut-être était-ce à cause d'un mauvais paramétrage :-/ ...

=== Tensorflow et CIFAR10 ===

Impossible désormais de présenter un comparatif de GPU sans une évaluation de Deep Learning. Pour ma part, je me suis focalisé sur un test proposé par Tensorflow dans ses tutoriels et exploitant les bases d'images CIFAR10. Les paramètres ont été modifiés pour s'exécuter sur des volumes "locaux" aux machines (et exclure ainsi les biais liés aux accès à des volumes distants). J'ai également réduit le nombre d'itérations de 100000 à 10000 pour rester sur des temps d'exécution raisonnable. Les performances ont enfin été normalisées par rapport à une exécution sur le CPU le plus lent (2 sockets E5-2637v4).

Nos premières analyses confirment ce que nous avions observé sur Gromacs : Tensorflow est aussi un programme hybride et donc la part de performance à associer aux coeurs CPU n'est pas à négliger. Mais l'addition d'un accélérateur offre un gain très substantiel : 12x pour une GTX 1080Ti, 14x pour une RTX 2080Ti, 16x pour une Tesla P100 mais 25x pour une Tesla V100. Nous aurions pu nous attendre à mieux dans son match avec la P100, surtout étant donné la différence des processeurs de leurs systèmes respectifs, mais les mesures sont là !

{{ :developpement:activites:qualification:tensorflow_c4140.png?600|}}

Bien qu'il existe dans le dossier du test une version multiGPU de l'apprentissage, elle ne s'exécute pas correctement. Ainsi se termine notre test en Deep Learning. La Tesla V100 reste la meilleure carte (et de loin) pour des activités de Depp Learning, surtout si une grosse quantité de mémoire est requise pour "charger" les bases d'apprentissage.

=== Hoomd : le petit dernier mais si illustratif ! ===

Hoomd est arrivé dans ma batterie de tests quasiment par hasard. Il m'a été demandé de le déployer pour un laboratoire de biologie. J'ai alors découvert après son intégration qu'il disposait de benchmarks plutôt aboutis et facilement exécutables. J'ai donc entrepris de les intégrer aux tests. Ce programme de dynamique moléculaire par méthode de Monte Carlo est très intéressant ; il se rapproche ainsi de tests élémentaires que nous avons détaillés au début de nos investigations. Appels en Python, multiGPU, etc... Les benchmarks de Hoomd exploitent 7 cas d'usage différents. A noter que la version Double Précision est INDISPENSABLE pour exécuter ces tests ; un des composants nécessaires à leur exécution l'exige ! Cette contrainte est assez dommageable parce qu'elle exclut toute comparaison avec les RTX ou GTX. 

Les 7 tests ont donc été exécutés 10 fois dans 5 configurations "système" différentes : pour les GTX 1080Ti, RTX 2080Ti, Tesla P100, Tesla V100 et les 4 Tesla V100 du C4140. Les valeurs ont été renormalisées à la Tesla P100 (la configuration "classique" présentée dans les benchmarks du site).

{{ :developpement:activites:qualification:hoomd_c4140.png?600|}}

Quelles conclusions pouvons-nous tirer de ces évaluations ? Tout d'abord, Les cartes de gamer GTX et RTX sont très rarement compétitives dans ce cas d'exploitation : la RTX ne dépasse la Tesla P100 que dans un cas et reste équivalente dans 2 autres. La Tesla V100 l'emporte à chaque fois, offrant au moins un facteur 2 dans 3 cas, au pire seulement 40% supplémentaire. La version multiGPU est rarement compétitive : 50% supplémentaire pour 4x plus de puissance brute, c'est assez faible... Dans deux cas, le multiGPU est franchement contre productif. Il reste cependant un cas dans lequel la présence de 4 cartes offre un gain de 3.57 : c'est très raisonnable ! Ce test Hoomd pourrait à lui seul résumer toute la difficulté de comparer les systèmes informatiques : il ne suffit que de donner une liste d'applications à comparer, il faut également les cas d'usage les plus significatifs ! Ainsi, en ne testant que "Hexagon", nous en déduisions que le multiGPU était impressionnant alors que c'est l'exception qui confirme la règle.

====== Conclusion : un monstre polyvalent (mais pour les nantis) ======

Il est clair que la mise à disposition de ce C4140 m'a réconcilié avec la série des C41. Exit les instabilités chroniques des C410X, terminé ces Xeon Phi inexploitables des C4130. Dans une unité de baie, il est possible de disposer de la puissance brute d'une baie entière de noeuds de calcul assez "musclés", et ce pour un nombre croissant d'applications dans de nombreux domaine.

Oui, la Nvidia Tesla V100 est un "monstre", reléguant la précédente, la Tesla P100 (qui était déjà impressionnante en son temps) à un facteur 2. Si l'efficacité en double précision est exigée, il n'y a pas d'autre option. Le C4140, cette intégration de 4 Tesla V100 dans une unité de baie est un pari : en plaçant le ticket d'entrée très haut (un ensemble à 45k€ minimum), il faut pouvoir justifier d'une utilisation efficace de tous ses composants et dans tous les cas. Malheureusement, les codes exploitant efficacement plusieurs GPU restent rares, et, quand ils le sont, leurs cas d'usage anecdotiques.

Si l'objectif n'est pas d'aller plus vite pour un unique utilisateur mais d'offrir une "bonne" puissance à plusieurs, le C4140 reste aussi une option. Se pose toutefois la pertinence de sa viabilité économique face à une armada de 8 R740 équipée de 16 cartes RTX 2080 Ti, sensiblement dans la même enveloppe financière. Evidemment, les détracteurs des cartes de gamers ne manqueront pas de fustiger le caractère inefficace de cette configuration en double précision... Dans le pire des cas, l'heureux propriétaire d'un C4140 pourra offrir 4 machines virtuelles avec chacune sa Tesla V100 dédiée, une solution pour ceux qui souhaitent "contrôler" le mieux possible la mise à disposition individuelle de ces monstres sans jamais redémarrer le serveur matériel...

Comme toujours "le problème, c'est le choix".