Nvidia a quelque chose qu’Intel et AMD convoitent. Non, ce ne sont pas des GPU. Intel et AMD fabriquent tous deux des GPU. Cependant, ils n’ont pas l’arme pas si secrète de Nvidia qui est un proche compagnon du GPU : CUDA, le langage de programmation parallèle qui permet aux développeurs d’exploiter les GPU pour accélérer les algorithmes à usage général (non graphiques). Depuis son introduction en 2006, CUDA est devenu un avantage concurrentiel considérable et jusqu’à présent inégalé pour Nvidia, car il fonctionne avec les GPU Nvidia, et uniquement avec les GPU Nvidia. Naturellement, ni Intel ni AMD ne prévoient de laisser cet avantage concurrentiel sans contestation.
Le premier GPU de Nvidia, le GeForce 256, est apparu en 1999. C’est la même année que Ian Buck a commencé à travailler sur son doctorat à l’Université de Stanford, où il a développé Brook, une série d’extensions pour le langage de programmation C qui a permis aux développeurs de logiciels d’exploiter les graphiques programmables. matériel, en particulier les GPU, pour effectuer des calculs à usage général. Les extensions de Buck’s Brook ont transformé les GPU en coprocesseurs vectoriels de streaming hautement parallèles. Nvidia a aimé ce qu’il a vu à Brook, a embauché Buck en 2004 et a introduit un ensemble plus généralisé d’extensions de langage de programmation parallèle appelé CUDA en 2006.
CUDA fonctionne désormais avec une variété de langages de programmation, notamment C, C++, Fortran, Python et MATLAB. L’écosystème CUDA s’est développé au cours des 15 dernières années pour devenir un avantage concurrentiel significatif pour Nvidia et ses GPU. CUDA est désormais utilisé pour aider les GPU à accélérer les charges de travail dans plusieurs domaines de calcul, notamment :
- Bioinformatique
- Chimie computationnelle
- Dynamique des fluides computationnelle
- science des données
- Apprentissage automatique et intelligence artificielle (ML et IA)
- Modélisation du temps et du climat
La réponse d’AMD à CUDA est ROCm, qui ressemble étroitement à CUDA dans le but de rendre les GPU AMD Radeon et AMD Instinct plus accessibles en tant que processeurs vectoriels hautement parallèles que les développeurs de logiciels peuvent utiliser pour accélérer les charges de travail informatiques à usage général. Selon le portail d’information ROCm, “AMD ROCm est la première plate-forme de développement de logiciels open source pour le calcul GPU de classe HPC/Hyperscale”. De plus, AMD-Xilinx est impliqué dans un projet connexe appelé SYCL, comme vous le verrez ci-dessous.
La réponse d’Intel à CUDA est plus complexe et plus nuancée, peut-être parce qu’Intel fabrique de nombreux types de processeurs, notamment des processeurs, des GPU, des FPGA et des accélérateurs spécialisés tels que les processeurs Gaudi et Gaudi 2 AI – qui peuvent tous être mis en service en tant que matériel. accélérateurs programmables pour de nombreuses charges de travail différentes. Peut-être en raison de la complexité collective de ces multiples processeurs, Intel a développé une taxonomie de charge de travail à quatre volets qui se superpose simplement au silicium de l’entreprise sur une base 1 pour 1 :
- Scalaire : charges de travail complexes qui s’exécutent mieux sur un processeur
- Vecteur : charges de travail qui peuvent être décomposées en vecteurs d’instructions ou en vecteurs d’éléments de données et accélérées en exécutant le code sur un processeur vectoriel comme un GPU
- Matrice : charges de travail, y compris l’IA et le ML, qui effectuent de nombreux calculs matriciels et fonctionnent mieux sur des puces AI/ML spécialisées telles que les processeurs tensoriels
- Spatial : charges de travail qui nécessitent des processeurs spécialisés uniques en leur genre, mieux construits à la volée à l’aide de FPGA pour répondre aux besoins de calcul de la charge de travail spécifique.
Bien sûr, il y a un peu de flou sur les lignes ici. Les processeurs x86 d’Intel ont eu des extensions d’instruction SIMD depuis le siècle dernier, à commencer par les registres vectoriels 64 bits et les instructions MMX (Matrix Math eXtensions) dans le processeur Pentium MX, introduit en 1997. (À ne pas confondre avec le type de matrice dans le processeur Intel taxonomie des processeurs illustrée ci-dessus.) Les dernières extensions d’instructions Intel AVX-512 donnent aux processeurs Intel des capacités vectorielles SIMD 512 bits. De même, les FPGA Intel Agilex SoC contiennent plusieurs processeurs Arm Cortex-A53 qui fournissent une capacité de vecteur SIMD via les extensions d’instruction Arm Neon.
De plus, les types de taxonomie « scalaire » (CPU), « vecteur » (GPU) et « matrice » (processeur AI/ML) décrivent tous le principal type de calculs que le processeur effectue, tandis que le type de taxonomie « spatial » décrit caractéristiques physiques du FPGA. Configurés de manière appropriée, les FPGA peuvent exécuter des charges de travail scalaires, vectorielles et matricielles, mais peut-être pas aussi rapidement ou aussi efficacement que les processeurs spécialisés. Donc, je dirais que la taxonomie des processeurs à quatre volets d’Intel est asymétrique ou non orthogonale, mais c’est peut-être juste moi.
La solution d’Intel à un modèle de programmation unifié pour tous ces types de processeurs est oneAPI. Alors que CUDA de Nvidia et ROCm d’AMD se concentrent sur l’accélération des charges de travail vectorielles à l’aide des capacités vectorielles innées d’un GPU, l’initiative oneAPI vise à définir un environnement de programmation, un ensemble d’outils et une bibliothèque unifiés pour un monde informatique qui comprend désormais les quatre types de charge de travail énumérés ci-dessus. L’objectif est de fournir une expérience de programmation unifiée et ouverte qui réduit, et finalement élimine, la complexité des bases de code, des langages de programmation, des outils et des workflows gérés séparément. À cette fin, Intel a créé oneAPI.io en tant que communauté ouverte travaillant pour apporter les outils oneAPI à autant d’architectures que possible, dans le but de faire de oneAPI le seul véritable environnement de programmation multi-architecture universel. OneAPI pour les gouverner tous. Bien entendu, Intel proposera sa propre version de oneAPI pour supporter son propre silicium.
Raja Koduri d’Intel a annoncé l’initiative oneAPI et son langage de programmation principal, Data Parallel C++ (DPC++), lors de la journée de l’architecture d’Intel en 2018. DPC++ est basé sur ISO C++ et les normes SYCL du groupe Khronos. SYCL est une couche d’abstraction multiplateforme libre de droits qui permet aux développeurs de logiciels d’écrire du code pour un ensemble de processeurs hétérogènes. Le DPC++ d’Intel étend ces normes en fournissant des constructions parallèles explicites et des interfaces de déchargement pour prendre en charge une large gamme d’architectures et de processeurs informatiques hétérogènes, y compris les processeurs, les GPU, les FPGA et d’autres accélérateurs matériels. Intel s’est concentré sur la prise en charge de son propre silicium, bien sûr, mais d’autres parties ont étendu oneAPI et DPC++ pour prendre en charge les éléments de traitement du silicium d’autres fournisseurs de semi-conducteurs, notamment AMD et Nvidia.
En plus d’Intel DPC++, il existe d’autres implémentations SYCL, notamment :
- ComputeCpp du logiciel de lecture de code
- hipSYCL de l’Université de Heidelberg
- neoSYCL de l’Université du Tohoku
- triSYCL d’AMD-Xilinx
Le directeur commercial de Codeplay Software, Charles Macfarlane, a fait une présentation d’une heure lors de l’événement Intel Vision qui s’est tenu le 10 mai à Dallas, où il a décrit le travail de son entreprise avec SYCL, oneAPI et DPC++. Macfarlane a expliqué que Nvidia CUDA et SYCL visent à accélérer l’exécution de la charge de travail en exécutant des noyaux, qui sont des parties spécifiques du code de la charge de travail, sur des moteurs d’exécution alternatifs globaux. Dans le cas de CUDA, les accélérateurs cibles sont les GPU Nvidia. Pour SYCL et DPC++, les choix sont sensiblement plus larges.
SYCL a des mécanismes intégrés pour permettre un reciblage facile du code vers une variété de moteurs d’exécution, y compris les CPU, les GPU, les moteurs d’IA et les FPGA. Étant donné que SYCL est une norme non propriétaire, vous pouvez cibler des processeurs de plusieurs fournisseurs de silicium si vous disposez du bon compilateur. Divers compilateurs SYCL prennent en charge les architectures de processeur de plusieurs fournisseurs.
Codeplay propose actuellement des compilateurs SYCL qui peuvent cibler les GPU Nvidia ou AMD. Cependant, un blog Intel publié le 1er juin a annoncé que la société avait signé un accord pour acquérir Codeplay, il est donc probable que les GPU d’Intel seront bientôt également pris en charge.
Au cours de sa conférence Intel Vision, Macfarlane a raconté deux exemples qui ont mis en évidence l’efficacité de oneAPI et DPC++ par rapport à CUDA. Dans le premier exemple, le Zuse Institute Berlin a pris du code pour easyWave, une charge de travail de simulation de tsunami, et a automatiquement converti le code écrit en CUDA pour les GPU Nvidia en code DPC++ à l’aide de l’outil de compatibilité DPC++ (DPCT) d’Intel. Le code converti pourrait ensuite être redirigé vers les processeurs, GPU et FPGA Intel à l’aide de compilateurs et de bibliothèques appropriés. Cependant, ce même code DPC++ pourrait également s’exécuter sur les GPU Nvidia en utilisant un compilateur et des bibliothèques différents.
Codeplay a compilé le code easyWave DPC++ pour les GPU Nvidia, et les résultats étaient à moins de 4 % des résultats de performances CUDA d’origine. Cette expérience a utilisé du code converti par machine sans réglage supplémentaire. Maintenant, juste entre nous, je soupçonne qu’une perte de performances de 4 % est peu susceptible d’exciter suffisamment de gens pour passer de CUDA à DPC++, même s’ils reconnaissent qu’un peu de réglage pourrait permettre d’obtenir des performances encore meilleures.
Cependant, le deuxième exemple de Macfarlane était plus convaincant. Codeplay a utilisé DPCT pour convertir le code du noyau à N corps écrit en CUDA en code SYCL. Le noyau à N corps utilise des mathématiques vectorielles multidimensionnelles pour simuler le mouvement de plusieurs particules sous l’influence de diverses forces physiques. Codeplay a compilé directement la version SYCL résultante du noyau N-body, sans optimisation ni réglage supplémentaires. La version CUDA originale du noyau de code à N corps s’exécutait en 10,2 millisecondes tandis que la version DPC++ convertie du noyau à N corps s’exécutait en 8,79 millisecondes. Les deux résultats concernent la même cible GPU Nvidia. Cela représente une amélioration des performances de 14 % pour le code traduit automatiquement. L’optimisation et le réglage pourraient encore améliorer ce résultat. Compte tenu du prix du temps passé sur les supercalculateurs qui exécutent généralement ce type de charge de travail, une amélioration des performances de 14 % est notable.
Au cours de son discours, Macfarlane a expliqué que les développeurs ont deux niveaux d’optimisation qui peuvent rendre le code DPC++ encore plus rapide :
- Réglage automatique, qui sélectionne automatiquement le “meilleur” algorithme parmi les bibliothèques disponibles
- Réglage manuel à l’aide de directives d’optimisation spécifiques à la plate-forme
Il existe un autre outil d’optimisation à la disposition des développeurs lorsqu’ils ciblent le silicium Intel : le VTune Profiler. C’est l’outil d’analyse des performances et d’optimisation de la puissance d’Intel. À l’origine, le profileur VTune ne fonctionnait qu’avec le code CPU, mais Intel a étendu l’outil pour couvrir le code ciblant les GPU et FPGA Intel et a maintenant intégré VTune dans sa boîte à outils de base oneAPI.
Actuellement, Intel oneAPI et DPC++ prennent en charge les CPU et GPU Intel. Il existe également une certaine prise en charge des FPGA Intel via le « module complémentaire Intel FPGA pour le kit d’outils de base oneAPI », mais le module complémentaire ne prend en charge que la compilation du noyau hors ligne (à l’avance) pour les FPGA. Cela signifie que vous devez générer le matériel d’accélération du noyau cible avant de compiler votre code SYCL/DPC++. La prise en charge des processeurs Intel Gaudi et Gaudi 2 AI de Habana Labs est en cours. La société prévoit de prendre en charge ces processeurs à l’avenir.
Ce n’est qu’une supposition, mais je m’attends à ce que l’acquisition de Codeplay par Intel accélère le développement de la couverture oneAPI et DPC++ pour tous les types de processeurs d’Intel. Ce qui était moins clair pour moi, c’était comment ou si Codeplay continuerait à prendre en charge le silicium non Intel après qu’Intel ait terminé cette acquisition. Cependant, juste après l’annonce de l’acquisition, le PDG de Codeplay, Andrew Richards, a publié un blog sur le site de Codeplay et a spécifiquement abordé cette question. Il a écrit:
“Intel se concentre sur les standards ouverts, et Codeplay a dirigé et contribué à plusieurs standards ouverts, y compris SYCL…
“Cela place Codeplay dans une position de force pour travailler dans l’ensemble de l’industrie afin d’apporter SYCL et d’autres normes ouvertes aux fournisseurs de processeurs et aux équipes de développeurs de logiciels soutenant la stratégie déclarée des deux parties. Codeplay est donc au cœur de la stratégie d’Intel pour démocratiser oneAPI et SYCL, garantissant que tous les processeurs prennent en charge les standards ouverts.
Le support d’Intel permettra à Codeplay de rester solide dans la communauté et l’écosystème. Codeplay fonctionnera comme une filiale d’Intel et continuera à prendre en charge le marché des accélérateurs multi-architectures et multi-fournisseurs.
Dans son article de blog du 1er juin annonçant l’acquisition, le directeur général d’Intel pour les produits logiciels et l’écosystème, Joe Curley, a semblé faire écho à Richards sur ce sujet. Il a écrit:
« Sous réserve de la clôture de la transaction, que nous prévoyons plus tard ce trimestre, Codeplay fonctionnera en tant que filiale au sein du Software and Advanced Technology Group (SATG) d’Intel. Grâce à la structure de la filiale, nous prévoyons de favoriser l’esprit d’entreprise unique de Codeplay et son approche d’écosystème ouvert pour lesquels il est connu et respecté dans l’industrie.
Le contrat de mise en œuvre d’un compilateur DPC++ pour prendre en charge les supercalculateurs basés sur GPU AMD que le laboratoire national d’Argonne en collaboration avec le laboratoire national d’Oak Ridge a attribué à Codeplay à la mi-juin est un signe encourageant que Codeplay et DPC++ continueront à prendre en charge les processeurs et les accélérateurs de plusieurs fournisseurs. Tout cela semble très prometteur et il sera intéressant de voir comment tout cela se déroulera à l’avenir.
Lié