Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente | Dernière révision Les deux révisions suivantes | ||
|
developpement:activites:qualification:c4140 [2019/07/31 17:56] equemene [Conclusion : un monstre polyvalent (mais pour les nantis)] |
developpement:activites:qualification:c4140 [2019/08/02 16:37] equemene |
||
|---|---|---|---|
| Ligne 9: | Ligne 9: | ||
| ===== Introduction ===== | ===== 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... | + | Tester tout à 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 ===== | ===== Un peu d'histoire ===== | ||
| Ligne 19: | Ligne 19: | ||
| 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$). | 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. | + | 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 ; il était souvent nécessaire, 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 à jour 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. | + | 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 ou tel GPGPU à telle ou telle machine. En somme, 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. | 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. | ||
| Ligne 27: | Ligne 27: | ||
| ==== Le C4130, et le malheur du Xeon Phi ==== | ==== 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. | + | Conscient que les liens externes PCIe n'engendraient 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 déprimante. 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, si bien 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 finalement le code 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. | 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. | ||