L’architecture de calcul CDNA 3 d’AMD
(chipsandcheese.com)- AMD CDNA 3 est une architecture de GPU de calcul conçue pour combler les points où CDNA 2, malgré ses bons résultats en supercalcul FP64, accusait un retard face au H100 en performances IA et en taille de GPU intégré
- Le MI300X expose comme un seul GPU un total de 304 Compute Units réparties sur 8 XCD, réduisant la contrainte qui, avec le MI250X, obligeait à répartir les tâches entre deux GPU et des pools mémoire séparés
- La hiérarchie mémoire a été réorganisée autour de 256 Mo d’Infinity Cache, de 4 Mo de L2 par XCD et de 32 Ko de L1 près des CU ; elle offre en théorie 17,2 To/s de bande passante cache, mais les liens die-to-die peuvent devenir un goulot d’étranglement dans une configuration mémoire unifiée
- Les unités d’exécution adoptent une structure proche du dual issue et augmentent le nombre de threads traçables par SIMD afin de mieux exploiter le FP32 ; le débit des opérations matricielles double également par CU par rapport à la génération CDNA précédente
- Les changements clés de CDNA 3 concernent la hiérarchie mémoire et le packaging ; le MI300X est conçu pour faire apparaître plusieurs chiplets comme un grand accélérateur unique grâce à une bande passante Infinity Fabric fortement accrue
L’écart visé par CDNA 3
- Pour rattraper Nvidia sur le marché du GPU computing, AMD a fait évoluer ses architectures en passant par Terascale 3, GCN, puis la séparation CDNA/RDNA
- Les MI250X et MI210 basés sur CDNA 2 ont remporté plusieurs contrats de supercalculateurs, dont Frontier de l’ORNL, qui a pris la première place du TOP500 en novembre 2023
- CDNA 2 offrait des performances solides et rentables en calcul FP64, mais le H100 proposait de meilleures performances IA et un GPU intégré plus grand
- CDNA 3 a été conçu pour réduire cet écart en combinant le packaging avancé d’AMD, Infinity Fabric, l’Infinity Cache issu de la famille RDNA et des Compute Units améliorées
Organisation GPU du MI300X
- Le MI300X utilise une structure en chiplets qui sépare le calcul dans des Accelerator Complex Die (XCD)
- Un XCD joue un rôle similaire au Graphics Compute Die (GCD) de CDNA 2/RDNA 3 et au Core Complex Die (CCD) des Ryzen
- Comme les produits CDNA ne disposent pas du matériel graphique dédié de la famille RDNA, AMD semble avoir changé la nomenclature
- Chaque XCD contient physiquement 40 Compute Units CDNA 3, dont 38 sont activées par XCD dans le MI300X
- Chaque XCD dispose de 4 Mo de cache L2, utilisés par toutes les CU de ce die
- Avec 8 XCD, le MI300X fournit au total 304 Compute Units
- C’est nettement plus que les 220 CU du MI250X, et le MI300X peut exposer ces CU comme un GPU unique
- Sur le MI250X, chaque GPU disposait d’un pool mémoire séparé, ce qui obligeait les programmeurs à répartir eux-mêmes les tâches entre les deux GPU
- Le Nvidia H100 expose 132 Streaming Multiprocessors (SM) comme un seul GPU intégré, mais suit l’approche traditionnelle consistant à implémenter le calcul sur un grand die monolithique
- Le H100 divise le L2 en deux instances ; un SM donné peut utiliser l’ensemble des 50 Mo de L2, mais les accès au-delà de 25 Mo subissent une pénalité de performance
- Les XCD du MI300X n’utilisent pas la capacité L2 des autres XCD pour la mise en cache, ce qui rend l’approche de Nvidia plus efficace du point de vue de l’utilisation de la capacité cache
Comparaison structurelle avec Ponte Vecchio
- Ponte Vecchio (PVC) d’Intel utilise le Compute Tile comme bloc de calcul de base, ce qui correspond grossièrement au XCD de CDNA 3
- Le Base Tile de PVC contient un grand cache de dernier niveau et les contrôleurs mémoire HBM, de manière similaire au die d’E/S de CDNA 3
- Une carte PVC peut elle aussi être exposée comme un GPU unique avec un pool mémoire unifié, comme le MI300X
- Les différences entre les deux structures apparaissent dans la taille des chiplets, le placement des caches et les liens inter-die
- Le Compute Tile de PVC se compose de 8 Xe Cores, ce qui le rend plus petit qu’un XCD CDNA 3 avec 38 CU
- Intel réduit les besoins de trafic cross-die grâce à un cache L1 plus grand, plutôt qu’à un cache couvrant tout le Compute Tile
- Lorsqu’un Ponte Vecchio à 2 stacks est utilisé comme GPU unifié, le pont EMIB ne fournit que 230 Go/s, ce qui rend difficile l’exploitation complète de la bande passante HBM lorsque les accès à tous les contrôleurs mémoire sont stripés
- Intel fournit des API permettant de traiter le GPU comme une configuration NUMA
- Sur le plan physique, CDNA 3 nécessite une forte bande passante entre dies d’E/S, tandis que PVC s’appuie sur des liens EMIB à faible bande passante, mais sa conception est complexifiée par quatre types de dies et par des procédés et fonderies différents
- Le MI300X n’utilise que deux types de dies, tous deux fabriqués par TSMC en 6 nm et 5 nm
Infinity Cache et goulots d’étranglement mémoire
- Depuis des décennies, les performances de calcul progressent plus vite que la mémoire, et les GPU, comme les CPU, y répondent avec des stratégies de cache plus sophistiquées
- CDNA 2 utilisait une hiérarchie de cache traditionnelle à deux niveaux reposant sur 8 Mo de L2 et de la HBM2e, mais le MI250X souffrait davantage d’un manque de bande passante que le Nvidia H100
- CDNA 3 ajoute l’Infinity Cache issu de RDNA 2
- L’Infinity Cache du MI300 est un cache côté mémoire que la documentation technique appelle Memory Attached Last Level (MALL)
- Il est plus éloigné des Compute Units que les caches L1 et L2, et rattaché aux contrôleurs mémoire
- Tout le trafic mémoire passe par l’Infinity Cache, et le trafic d’E/S ainsi que les communications avec les GPU pairs peuvent aussi bénéficier de sa bande passante
- Comme il voit toujours l’état le plus récent du contenu de la DRAM, il n’a pas besoin de gérer des opérations de maintien de cohérence de cache comme le snoop
- Les caches côté mémoire ont généralement une latence plus élevée ; AMD protège donc les Compute Units avec des caches L2 de plusieurs Mo, aussi bien dans CDNA 3 que dans RDNA 2
Capacité et bande passante théorique de l’Infinity Cache
- L’Infinity Cache de CDNA 3 utilise, comme celui de RDNA 2, une structure associative à 16 voies
- L’implémentation de CDNA 3 est davantage optimisée pour la bande passante que pour la capacité
- Elle se compose de 128 slices
- Chaque slice offre une capacité de 2 Mo et une bande passante en lecture de 64 octets par cycle
- L’ensemble des slices fournit 8192 octets par cycle, soit 17,2 To/s à 2,1 GHz
- L’Infinity Cache de 128 Mo de RDNA 2 fournit, pour l’ensemble des slices, 1024 octets par cycle, soit 2,5 To/s théoriques à 2,5 GHz
- D’après les photos de die, une slice d’Infinity Cache de RDNA 2 semble offrir 4 Mo de capacité et 32 octets par cycle
- Le MI300X peut fournir des performances correctes même sur des workloads à faible compute density, à condition d’obtenir suffisamment de hits dans l’Infinity Cache
- Si l’on construit un modèle roofline à partir de la bande passante théorique de l’Infinity Cache, le MI300X peut atteindre tout son débit FP64 avec 4,75 FLOPs par octet chargé
- En utilisant uniquement la DRAM, il faut 14,6 à 15 FLOPs par octet chargé
Contraintes de bande passante cross-die
- L’Infinity Fabric du MI300X s’étend sur 4 dies d’E/S, chacun relié à 2 stacks HBM et aux partitions de cache associées
- Lorsque le MI300X fonctionne comme un seul GPU logique avec un pool mémoire unifié, la bande passante des connexions die-to-die peut limiter l’atteinte de la bande passante théorique totale de l’Infinity Cache
- Le goulot d’étranglement pour une seule partition de die d’E/S apparaît dans le calcul de bande passante
- Sur les deux bords adjacents aux dies d’E/S voisins, elle dispose de 2,7 To/s de bande passante entrante
- Les 2 XCD connectés à ce die d’E/S peuvent obtenir 4,2 To/s de bande passante Infinity Cache
- Si les requêtes de miss L2 sont uniformément stripées sur l’ensemble des dies, 3/4, soit 3,15 To/s, doivent provenir de dies pairs
- Comme 3,15 To/s est supérieur à 2,7 To/s, la bande passante cross-die limite la bande passante cache
- Si tous les dies demandent la bande passante maximale de l’Infinity Cache dans une configuration unifiée, les transferts entre dies situés sur des coins opposés nécessitent 2 hops, ce qui consomme encore davantage de bande passante entrante
- En divisant le MI300X en plusieurs domaines NUMA, la bande passante Infinity Cache cumulée peut être plus élevée
- Un taux de hit L2 élevé réduit le risque de goulot d’étranglement, et lorsque le taux de hit de l’Infinity Cache est faible, les liens die-to-die du MI300X fournissent une bande passante suffisante pour gérer le trafic HBM
Cohérence entre XCD et fonctionnement du L2
- L’Infinity Cache n’a pas besoin de traitement particulier en matière de cohérence, mais le cache L2 en nécessite un
- Les accès mémoire GPU ordinaires suivent un modèle de cohérence relâchée, mais le programmeur peut imposer l’ordonnancement entre threads avec des atomics
- Les accès mémoire des GPU AMD peuvent être marqués par le bit GLC (Global Level Coherent)
- Sur les précédents GPU AMD, les atomics et les accès cohérents étaient traités dans le L2
- Un load avec le bit GLC activé contourne le L1 et récupère les données les plus récentes dans le L2
- Sur MI300X, la cacheline la plus récente peut se trouver dans le L2 d’un autre XCD, ce qui rend cette seule méthode insuffisante
- CDNA 3 place un Coherent Master (CM) au niveau de l’interconnexion entre les XCD et le die d’E/S, comme l’Infinity Fabric de Ryzen, et un Coherent Slave (CS) à côté de chaque contrôleur mémoire, avec une slice d’Infinity Cache
- La documentation de Ryzen indique que le Coherent Slave contient un probe filter et du matériel pour traiter les transactions atomiques
- MI300X semble disposer d’une implémentation de CS similaire
- Lorsqu’une écriture cohérente arrive au CS, toute lecture cohérente doit pouvoir observer cette écriture, quel que soit l’endroit du GPU où s’exécute le thread
- Dans une implémentation simple, le CS devrait sonder les L2 de tous les XCD
- Le probe filter suit quels XCD ont mis la ligne en cache afin d’éviter du trafic de probe inutile
- Le whitepaper de CDNA 3 indique que le snoop filter est assez grand pour couvrir plusieurs caches L2 de XCD
- Cela dit, à l’intérieur d’un XCD, CDNA 3 se comporte de manière similaire aux GPU existants
- Une écriture mémoire ordinaire n’invalide pas automatiquement, comme le ferait un CPU, la ligne dans le cache pair
- Le code doit explicitement writeback les lignes de cache L2 dirty et invalider les lignes L2 non locales dans les L2 pairs
- La documentation LLVM associée décrit l’utilisation de
buffer_wbl2 sc1etbuffer_inv sc0 sc1pour la cible GFX942
Améliorations des caches L2 et L1
- Chaque XCD de MI300X dispose de 4 Mo de cache L2 à proximité des Compute Units
- Le L2 est composé de 16 slices
- Chaque slice de 256 Ko fournit une bande passante de 128 octets par cycle
- À 2,1 GHz, cela représente 4,3 To/s par XCD
- MI300X présente un meilleur ratio bande passante L2 / calcul que H100 et MI250X
- Comme chaque XCD possède son propre L2, la bande passante L2 augmente naturellement à mesure que les produits CDNA 3 ajoutent des XCD
- Cela évite le problème consistant à connecter de nombreuses Compute Units à un grand cache unique tout en devant maintenir la bande passante
- Sur PVC, à mesure que le nombre de Compute Tiles augmente, le L2 partagé du Base Tile subit des exigences de bande passante plus élevées
- L’architecture de PVC est plus simple côté conception de cache, car le L2 sert à la fois de point unique de cohérence et de backstop pour les miss L1
- Elle ne fournit pas une bande passante aussi élevée que le L2 de MI300X
- Le L1 de CDNA 3 a également été amélioré en priorité sur la bande passante
- Le throughput L1 passe de 64 à 128 octets par cycle
- La capacité du L1 passe aussi de 16 Ko à 32 Ko
- Un cache plus grand peut augmenter le taux de hit, réduire la latence moyenne des accès mémoire et améliorer l’utilisation des unités d’exécution
- Comme récupérer des données depuis le L2 ou au-delà consomme de l’énergie, l’augmentation du taux de hit peut aussi améliorer l’efficacité énergétique
- Ponte Vecchio reste toutefois solide côté L1
- Chaque Xe Core fournit 512 octets par cycle
- La capacité du L1 est de 512 Ko
- Les kernels memory-bound qui tiennent dans le L1 peuvent bien fonctionner sur l’architecture Intel
- En revanche, faute de cache intermédiaire au niveau du Compute Tile, les performances peuvent chuter brutalement dès que les données dépassent le L1
Ordonnancement et unités d’exécution
- Au-delà de sa structure de chiplets et de caches qui fait apparaître MI300X comme un GPU unique, CDNA 3 améliore par itérations l’architecture des Compute Units afin de traiter le problème d’utilisation FP32 de CDNA 2
- CDNA 2 traite nativement le FP64 tout en fournissant du FP32 à débit double via packed execution
- Le compilateur devait packer deux valeurs FP32 dans des registres adjacents et exécuter la même instruction
- Si le programmeur n’utilisait pas explicitement des vecteurs, il était souvent difficile pour le compilateur d’y parvenir correctement
- CDNA 3 contourne ce problème avec un mécanisme de dual issue plus flexible
- Il semble plus proche d’une extension des capacités multi-issue de GCN que du mode VOPD/wave64 de RDNA 3
- Le scheduler du CU choisit l’un des quatre SIMD à chaque cycle et vérifie s’il existe des threads prêts à s’exécuter
- Si plusieurs threads sont prêts, GCN pouvait en envoyer jusqu’à 5 vers les unités d’exécution
- Le dual issue de CDNA 3 a probablement besoin que le programmeur expose du parallélisme au niveau des threads avec une grande dispatch size, plutôt que de dépendre du compilateur, pour être efficace
- Si un SIMD exécute davantage de threads, la probabilité de trouver simultanément deux threads ayant des instructions FP32 augmente
- Il faut au minimum 2 threads actifs par SIMD pour atteindre le débit FP32 maximal
- En pratique, une occupancy plus élevée est nécessaire en raison de la latence mémoire ou de la latence d’exécution
- AMD a fortement augmenté le nombre de threads qu’un SIMD CDNA 3 peut suivre, de 8 à 24
- Aucune hausse de la capacité du fichier de registres vectoriels n’a été mentionnée, or cette capacité limite souvent le nombre de threads qu’un SIMD peut maintenir simultanément
- Les capacités multi-issue peuvent fonctionner au mieux dans des kernels simples utilisant peu de registres par thread
- Le dual issue peut aussi transformer la bande passante du register file en problème
- Le FP32 packed de CDNA 2 exploitait les ports larges du register file, capables de transférer des valeurs 64 bits, sans nécessiter de lectures supplémentaires
- Des instructions distinctes peuvent référencer des registres différents et demander davantage de lectures
- AMD indique avoir amélioré le source caching au fil des générations, de sorte qu’une lecture de registre vectoriel puisse alimenter davantage d’opérations vectorielles ou matricielles en aval
- Il s’agit probablement d’une manière d’atténuer les conflits de ports avec un register cache plus grand et d’alimenter les unités d’exécution en données
Opérations matricielles et performances IA
- Avec la diffusion du machine learning, l’importance de la multiplication matricielle a augmenté, et Nvidia a fortement investi dans ce domaine en ajoutant des tensor cores avec Volta et Turing
- AMD CDNA prenait aussi en charge le matrix multiply, mais les architectures Nvidia contemporaines ont davantage investi dans le débit matriciel pour les types de données de faible précision comme FP16
- MI300X double le matrix throughput par CU par rapport aux générations CDNA précédentes
- La conception en chiplets de MI300X permet d’intégrer un très grand nombre de CU, ce qui augmente le débit total
- Nvidia reste un concurrent redoutable grâce à ses fortes performances matricielles par SM, tandis que CDNA 3, dans la lignée d’AMD, met fortement la pression sur Nvidia avec ses performances vectorielles FP64 tout en conservant de solides performances IA indépendamment
Évolution du cache d’instructions
- Une Compute Unit doit accéder à la mémoire de données, mais aussi récupérer les instructions elles-mêmes depuis la mémoire
- Le code GPU était traditionnellement simple et de petite taille, ce qui rendait l’acheminement des instructions relativement facile
- Les GPU CDNA 2 et RDNA continuaient d’utiliser un cache d’instructions de 32 Ko, mais CDNA 3 le porte à 64 Ko
- l’associativité passe également de 4-way à 8-way
- cela augmente le taux de réussite du cache d’instructions pour les kernels plus grands et plus complexes
- AMD semble avoir envisagé le cas d’un simple portage de code CPU vers le GPU
- un code CPU complexe peut être pénalisant sur GPU
- sur GPU, il est difficile de masquer la latence des ratés du cache d’instructions au moyen d’un prefetching d’instructions sur de longues distances et d’une prédiction de branchement précise
- un cache d’instructions plus grand aide à contenir de gros kernels, et une associativité plus élevée réduit les ratés par conflit
- L’instance de cache d’instructions de CDNA 3 est partagée par deux Compute Units, comme avec CDNA 2
- un kernel GPU s’exécute généralement avec une taille de travail assez grande pour remplir de nombreuses Compute Units ; le partage du cache d’instructions est donc une manière efficace d’utiliser la SRAM
- si davantage de Compute Units partagent une même instance de cache, il peut devenir difficile de satisfaire les besoins en bande passante d’instructions
Différences entre MI300X et MI300A
- Le plus grand changement générationnel de CDNA 3 concerne la hiérarchie mémoire, et l’amélioration clé réside en pratique dans l’ajout d’Infinity Cache
- Le principal problème du MI250X était qu’il ressemblait moins à un seul GPU qu’à deux GPU partageant le même package
- la bande passante entre les deux GCD était de 200 Go/s par direction
- AMD a estimé que cette bande passante ne suffisait pas à faire apparaître le MI250X comme un seul GPU, et a donc fortement augmenté la bande passante die-to-die
- MI300 porte la bande passante East-West totale à 2,4 To/s par direction, soit 12 fois plus que le MI250X
- la bande passante North-South totale est encore plus élevée, à 3,0 To/s par direction
- grâce à cette hausse de bande passante, MI300 peut apparaître comme un grand accélérateur intégré unique, et non comme deux accélérateurs comme le MI250X
- La bande passante ingress totale de 4,0 To/s d’un seul die d’E/S correspond presque aux 4,2 To/s que deux XCD peuvent utiliser, ce qui ne pose pas de problème majeur en pratique
- toutefois, un seul die d’E/S ne peut pas exploiter toute la bande passante mémoire totale de 5,3 To/s
- la situation est similaire à celle de Ryzen 7000, où un seul CCD ne peut pas pleinement exploiter la bande passante DDR5 en raison de la limite de l’Infinity Fabric
- sur MI300X, la demande de bande passante est maximale lorsque tous les dies fonctionnent ensemble ; dans ce cas, chaque die consomme environ 1,3 To/s, si bien qu’obtenir les 3/4 via le lien cross-die ne pose pas de problème
- MI300A est une APU « big iron » qui réutilise le même die de base tout en combinant 6 XCD CDNA3 et 24 cœurs Zen 4
- le CPU et le GPU peuvent partager le même espace d’adressage mémoire
- il n’est plus nécessaire de copier les données via un bus externe pour maintenir la cohérence entre CPU et GPU
1 commentaires
Avis sur Hacker News
Techniquement, les cartes grand public d’AMD ont d’excellentes performances de calcul. Par exemple, UE5 rend les maillages triangulaires via du calcul plutôt que par le pipeline graphique https://www.youtube.com/watch?v=TMorJX3Nj6U
En plus, comme nVidia a privilégié le ray tracing et le DLSS par rapport aux performances de calcul et à la bande passante mémoire, les cartes AMD devancent souvent les nVidia de même gamme.
Le problème, c’est qu’aucune entreprise tech ne veut ajouter de backend D3D ou Vulkan à des bibliothèques d’IA comme PyTorch. nVidia ne le fait pas parce que le statu quo lui convient, et Intel comme AMD ne le font pas parce qu’ils cherchent à remplacer CUDA par leur propre alternative propriétaire plutôt que par des API GPU ouvertes.
Cela dit, ce n’est ni une segmentation produit bancale ni un problème d’architecture de haut niveau. Les produits spécialisés font mieux leur travail dans leur domaine que les produits généralistes. La demande pour des cartes excellentes à la fois en calcul et en jeu est limitée ; ces utilisateurs existent, mais ils sont moins nombreux que ceux qui ne s’intéressent qu’à un seul de ces usages.
L’effet de la séparation de GCN en RDNA et CDNA a été immédiat. Si l’on compare la Radeon VII (GCN 5) et la RX 5700 XT (RDNA 1), elles se rendent coup pour coup en jeu, avec un léger avantage moyen pour la Radeon VII, mais la RX 5700 XT est nettement à la traîne dans les benchmarks de calcul. Les deux sont gravées en 7 nm chez TSMC, mais la RX 5700 XT a moins de shaders (2560 contre 3840), un die plus petit (251 contre 311 mm2) et consomme moins (225 contre 300 W), ce qui montre qu’elle est bien plus efficace en jeu. Avec une consommation plus faible, moins de bruit et un prix inférieur de plusieurs centaines de dollars, c’était une carte beaucoup plus attractive pour les joueurs.
Les cartes CDNA semblent dépourvues de composants nécessaires au jeu, comme les unités de sortie de rendu. Elles ne bénéficient donc pas d’un support officiel de DirectX, OpenGL ou Vulkan. Je n’ai jamais vu d’exemple de jeu tournant dessus. En revanche, leurs performances de calcul sont tellement bonnes que, malgré l’écosystème CUDA écrasant, plusieurs entreprises les achètent à la place de cartes nVidia. En 2013, un supercalculateur basé sur GCN figurait dans le top 100, et c’était le seul système GCN du top 100. Aujourd’hui, 8 des 10 supercalculateurs les plus efficaces énergétiquement utilisent des accélérateurs CDNA, et le supercalculateur le plus rapide au monde utilise lui aussi CDNA.
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
C’est fondamentalement une entreprise de matériel (comme le montre aussi le parcours de Lisa Su), et elle n’a pas compris assez vite que CUDA était le coup décisif. Je me souviens de @Bridgman sur Phoronix, menant une guerre de repli pour essayer de garder les développeurs. C’était une bataille perdue d’avance.
Je peux le comprendre dans une certaine mesure. La génération hardware des années 80/90 pense instinctivement que, dans la pile, le matériel est tout en haut, et les dirigeants d’AMD, Su comprise, viennent tous de ce milieu.
Kodura avait compris que nVidia dominait AMD parce que CUDA fonctionnait aussi sur les cartes grand public. Il a donc poussé la Radeon VII contre Lisa Su, et cette carte est restée pendant des années, jusqu’à tout récemment, la seule carte grand public prise en charge par ROCm. Il a été, de fait, licencié peu après, et la RVII, qui était une excellente carte, a été rapidement abandonnée. Ensuite, Wang est arrivé et a solidifié la séparation entre grand public et professionnel.
Aujourd’hui, AMD essaie désespérément de faire marche arrière, mais il est trop tard. Plusieurs acteurs tentent de rivaliser, mais les seuls qui méritent vraiment d’être mentionnés sont AAPL et Metal.
AMD a raté sa chance.
Même ainsi, je doute que cela ait aidé l’adoption des cartes AMD pour les workloads de calcul. Ce qui est formidable avec CUDA, c’est qu’on n’a pas besoin d’une carte accélératrice spécialisée pour développer du code CUDA.
La situation aurait peut-être été différente s’ils avaient dû acheter leurs GPU au même prix que le grand public, avec leur propre argent ou leurs crédits de recherche.
Personnellement, je trouve la façon dont NVidia s’implante dans les milieux universitaires et la recherche académique très contraire à l’éthique.
Ensuite, l’entreprise a continué à attendre, misant plusieurs fois son avenir sur l’idée que le marché pour les produits qu’elle avait créés « finirait par arriver ».
Ces dernières années, c’est effectivement arrivé, et cela s’est reflété dans le cours de l’action. Les autres acteurs ont en gros dix ans de retard, et vu l’emballement actuel ainsi que la démocratisation des workflows IA/ML, il paraît presque impossible que quelqu’un les rattrape.
À l’inverse, le code CUDA continuait de fonctionner avec les nouvelles générations de cartes Nvidia.
La plupart achètent des A6000 ou mieux à prix grand public auprès de sociétés comme Exxact ou Supermicro
Je crois n’avoir jamais vu de chercheurs recevoir des GPU gratuits depuis l’époque des V100, c’est-à-dire après les systèmes DGX-1
Contrairement aux CPU, les GPU ne cherchent pas à compenser cela directement. Ils acceptent une latence plus élevée, mais parallélisent beaucoup plus largement — voire plus agressivement — que les CPU, et un grand nombre de pseudo-threads parallèles fournit un effet de masquage de la latence
On peut voir cet effet, par exemple, dans des présentations sur l’optimisation de code GPU
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
L’animation à partir de la diapositive 11 en est un exemple
Autrement dit, beaucoup de traitements peuvent se faire uniquement dans les registres et le LDS, et les accès à la mémoire globale sont bien plus rares que sur un CPU, où presque tout se trouve en mémoire globale et où l’on dispose d’environ 16 registres architecturaux
Malgré tout, la mémoire globale reste un problème. Pas seulement à cause de la latence, mais aussi de la bande passante. C’est pourquoi RDNA2 et Ada ont ajouté de grandes quantités de cache de dernier niveau. Cela sert aussi à mieux masquer la latence, mais l’objectif principal est de faire office d’amplificateur de bande passante
Very long instruction word (VLIW) désigne une architecture de jeu d’instructions conçue pour exploiter le parallélisme au niveau des instructions (ILP). Un processeur central (CPU) classique se contente généralement de laisser le programme spécifier les instructions à exécuter dans l’ordre, tandis qu’un processeur VLIW permet au programme d’indiquer explicitement les instructions à exécuter en parallèle. Cette conception vise à obtenir de meilleures performances tout en évitant la complexité inhérente à d’autres approches
Les méthodes traditionnelles pour améliorer les performances d’un processeur incluent le pipeline, qui divise les instructions en sous-étapes pour en exécuter certaines simultanément, les architectures superscalaires, qui envoient des instructions individuelles s’exécuter indépendamment dans différentes parties du processeur, voire l’exécution dans le désordre, qui exécute les instructions dans un ordre différent de celui du programme. Ces approches rendent le matériel plus complexe, car le processeur doit prendre toutes les décisions en interne
https://en.wikipedia.org/wiki/Very_long_instruction_word
Ça n’a pas vraiment marché. D’où le surnom Itanic
L’hypothèse était que le compilateur pourrait déterminer statiquement les dépendances avec suffisamment de précision pour regrouper dans une même instruction plusieurs chemins d’exécution séquentiels et certains chemins de branchement. Mais il s’est avéré qu’en pratique les compilateurs n’y arrivaient pas, et les processeurs se sont donc mis à détecter dynamiquement, dans un flux d’instructions séquentiel, les dépendances et les instructions parallélisables
Cela demande beaucoup de travail, beaucoup de ressources sur la puce et beaucoup d’énergie. Et cela ne fonctionne bien que jusqu’à un certain point, après quoi on se heurte à des rendements décroissants. Il semble que ce soit précisément le point où nous nous trouvons aujourd’hui
Il ne s’agit pas du langage dans lequel on envoie les instructions, mais du mode de traitement lui-même
Et il faut aussi garder en tête que des termes comme VLIW4 ou VLIW5 désignent des implémentations particulières
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...