Voyant AMD comme un concurrent sur le marché des GPU et Intel comme un futur acteur de poids de ce segment, NVIDIA ne veut plus dépendre de leurs CPU. Après avoir développé ses propres solutions ARM, le père des GeForce passe à l'offensive, s'alliant avec des fabricants de serveurs ARM pour une offre HPC complète.
Face à AMD et Intel, NVIDIA a un défaut majeur : il n'a pas de licence lui permettant de proposer des processeurs x86. Ce n'est pas un problème vital sur le marché grand public, bien que cela lui coupe la possibilité de puces contenant CPU et GPU, mais cela devient plus compliqué dans le domaine des serveurs où il dépend de ses concurrents directs.
Jusqu'à maintenant, les serveurs NVIDIA étant donc massivement proposés avec des processeurs Xeon d'Intel, de plus ou moins fortes puissances selon les cas. Les deux sociétés sont d'ailleurs des partenaires de longue date, bien qu'ayant toujours eu une relation complexe. Cela va empirer avec l'arrivée des GPU Xe.
Mais Jen Hsun Huang n'est pas du genre à laisser faire en attendant de voir venir. NVIDIA a donc décidé de porter sur ARM toute sa couche de développement CUDA-X il y a quelques mois. Cela lui permet de dévoiler aujourd'hui plusieurs partenariats avec des fabricants de serveurs équipés de SoC ARM, misant sur le GPU pour la puissance de calcul.
Ampere, Cray, Fujitsu, HPE et Marvell ont participé à la création ou l'intégration de la machine de référence, ce qui couvre déjà une large part du marché. On note tout de même quelques absents qui ont fait le choix de rester fidèle à x86 et donc le duo AMD/Intel pour leurs machines comme Dell ou encore Lenovo.
NVIDIA voit dans cet accord le début d'une nouvelle ère dans le monde du HPC, plus ouverte et sans doute débarrassée de sa forte dépendance à x86. Il faudra néanmoins voir si la performance est au rendez-vous, les précédentes expériences exploitant ARM dans les serveurs ou ailleurs n'ayant pas toujours été concluantes.
Mais avec un allié de poids comme NVIDIA, qui propose déjà des SoC depuis quelques années dans ses appareils Shield ou ses solutions industrielles telles qu'AGX, il y a fort à parier que le secteur subisse un coup d'accélérateur. C'est sans doute ce qui a convaincu les différentes sociétés de s'allier autour du géant américain.
Commentaires (5)
très bonne nouvelle ! surtout quand qualcom a abandonné son lancement sur le marché serveur :/
Mes premiers tests avec les processeurs ThunderX2 de Cavium étaient déjà tout à fait encourageants. Au niveau écosystème ça commence à être très au point, du coup porter un code sur ARM est devenu facile. Au niveau performance, c’était vraiment pas mal, en particulier au niveau de la bande passante mémoire.
De mon point de vue, au niveau de serveur dédié aux calculs, j’ai un sérieux doute pour ARM. En effet, la majorité des programmes sont avant tout développés et optimisé pour une architecture X86/X64 et bon nombre ne sont disponible que là dessus.
Généralement, ce genre de machine que je parle tourne sur des bi-Xeon.
Du coup, j’ai comme un sérieux doute.
Vraiment très peu de codes dépendent de l’architecture. En revanche, il est crucial d’avoir des BLAS optimisés, parce qu’on n’aura pas la MKL sur ARM, ça va de soi. Mais à partir du moment où tu as des noyaux de calcul optimisés, il n’y a besoin d’à peu près aucune modif dans le code applicatif.
A priori, pas d’AVX ou de SSE sur ARM, hors pas mal de programmes utilise ça.
Ne serait-ce, par exemple, la bibliothèque python Numpy qui est une bibliothèque massivement utilisé dans plein de programme et d’autres bibliothèques scientifiques (python n’offre de base pas de “Array”, Numpy permet de manipuler des Array C en python). Or, c’est fait pour tirer parti du processeur (après, tu as même Intel qui propose sa compilation maison pour tirer profit de MKL). Tu me diras : on a un GPU, c’est débile de d’utiliser SSE ou AVX, sauf que numpy est utilisé en Deep Learning en amont et en aval des bibliothèques comme Tensorflow.
Mais plus généralement, beaucoup de programmes scientifiques ne sont pas proposée pour ARM, c’est compilé pour Linux, mais X86-X64. Et je doute que juste demander gentiment à la boite qui développe suffise, en tout cas pas sans sortie le chéquier.