Beaucoup plus performant que tous les autres super-ordinateurs dans le monde, il est basé sur les processeurs ARM et porte le nom de Fugaku.
1 « J'aime »
Ça donne quoi pour les jeux vidéo ? OK je sors…
3 « J'aime »
Vous pourriez aussi préciser qu’à lui tout seul, ce super calculateur japonais représente environ 60% de la totalité de la puissance de TOUS LES super calculateur américains figurants dans le top 500 !! (Ils sont plus de 120 ou 140 au total, je n’ai pas le chiffre exact sous la main)
C’est tout simplement énorme et ça montre à quel point l’augmentation à chaque nouveau top1 est gigantesque par rapport aux anciens…
2 « J'aime »
Ça fait tourner crysis en 1080p à 120 fps XD
5 « J'aime »
Wouaah… J’en veux un…
1 « J'aime »
Personne n’a pensé à le lancer une petite heure à la recherche d’ un modèle gouvernemental et fiscal efficace ?
5 « J'aime »
x86 est vieux et gourmand. Même si Intel s’essaie au chiplet, pas sûr qu’il y réussissent comme ARM.
il sera vite dépassé par un certain CRAY d’ici là !?
Ç’eut pu être sympa de connaître la finalité et l’usage de ce super ordinateur !
Ça paraît évident. Résoudre des sudoku.
8 « J'aime »
Est-ce qu’un connaisseur du sujet pourrait expliquer en quoi l’architecture ARM serait plus performante que la X86 ? Un petit topo là-dessus manque dans l’article.
Enfin le monopole d’Intel c’est vite dit… Le précédent TOP1 c’était Summit d’IBM en architecture POWER donc RISC !
Et parler du prix ça permet aussi de remettre en perspective le fait que, bien qu’il soit plus efficient et efficace, il coute 900 millions de dollars (avec la R&D si je comprends bien) alors qu’un Summit coute 3 ou 4 fois moins.
1 « J'aime »
Quid de la consommation ? (28 335 kW)
Sinon avec un casque de VR, on peut faire la matrice!
1 « J'aime »
x86 est vieux et gourmand.
Est-ce qu’un connaisseur du sujet pourrait expliquer en quoi l’architecture ARM serait plus performante que la X86 ?
Elle ne l’est pas.
Fugaku: 158 976 nodes ARMv8.2 * 52-cores = 8 266 752 coeurs CPU.
Summit: 9 216 nodes Power9 * 22 cores = 202 752 coeurs CPU + 27648 GPU Nvidia Tesla
Tianhe-2: 32 000 Xeon E5 * 12 cores + 48 000 Xeon Phi = 432 000 coeurs CPU
Fugaku: 415.5PF = 0.05 TF/coeur sur ARM
Summit: 148.6PF (difficile de savoir la part des GPUs) = entre 0.06 (si 1 pipe shader GPU = 1 coeur CPU) et 0.73 (en ignorant les GPU) TF/coeur sur Power
TH2: 61.5PF = 0.14TF/coeur sur x86-64
Bref, les AMD restent bien plus lents. Il a fallut en aligner:
- 40x plus que les Power9 de Sumit (mais j’ignore la part des GPUs dans les perfs PF de ce superordi) pour faire 2.5x fois mieux;
- 20x plus de coeurs CPU que TH2 (x86-64 Ivy Bridge) pour faire seulement 6,5x mieux.
+1. Pour le moment, le Top500 est mené par : Fugaku (Amd), Summit et Sierra (Power9), Sunway TaihuLight (SW26010), puis enfin TH2, HPC5, Selene, Frontera (en x86-64).
Ah, et une remarque sur le Top500 : il ne contient évidemment que les superordinateurs aux specs et benchmark connus publiquement. Il est possible que d’autres super-ordinateurs non connus du public existent (dans des secteurs secret comme le militaire, ou des entreprises ne publiant rien sur ce sujet).
6 « J'aime »
Je ne suis pas un grand spécialiste, mais j’ai fait des projets sur différentes plateformes et j’ai noté quelques différences. Les ARM sont un peu moins énergivore, ce qui est très intéressant dans ce genre d’engin qui consomme comme une ville. Par contre la puissance brute par coeur des processeurs X86, et dans certains cas encore plus des PowerPC est largement supérieure. Après, si tu ne fais que des opération basiques, l’ARM est vraiment un champion par watt.
En gros:
- calculs complexes (simulations scientifiques) => GPU
- calculs généralistes (on ne sait pas à quoi in destine la machine) => x86 ou PowerPC
- calculs relativement simples (serveurs web, multimédia embarqué) => ARM
Cependant, les différences ne sont pas très marquées, les consos, les jeux d’instructions et les perfs se rapprochent de plus en plus (à part certains calculs particuliers bien plus performants sur GPU), donc rien n’empêche de prendre un type de proc ou un autre.
Pour complexifier le tout, les TFlops annoncées ne veulent pas dire grand chose, avec 2 bécanes de même « puissance » mais architecturées différemment, l’une pourrait fournir des résultats 10x plus vite sur des algos spécifiques.
Edit: belle démo de @Sly
2 « J'aime »
+1. Les ARMs sont les champions de la perf/watt. Mais sont bien derrière en performances pures.
Gros avantages des x86 : bien meilleure gestion du cache mémoire, exécution out-of-order des instructions (quand des instructions sont indépendantes, les suivantes sont exécutées en parallèle d’une instruction plus lente), prédiction des test/branchements/boucles bien meilleures.
Le Power : également très performant en exécution comme le x86, mais sans la gestion du cache et l’exécution out-of-order. Le compilo et le programmeurs doivent faire plus attention.
Et le problème majeur et de plus en plus important dans beaucoup de domaines est la bande passante mémoire, loin derrière les performances des CPUs. En gros, un CPU peut exécuter 100 instructions dans le même temps que prend un seul accès mémoire. Si chaque instruction doit accéder à la mémoire, le programme va tourner théoriquement 100x plus lentement qu’un programme n’ayant pas besoin ed charger sans arrêt la mémoire.
Donc on a ajouté aux CPU des caches mémoires pour garder en local et à des vitesse bien plus élevées les données récemment accéeder (RAM = pénalité équivalente à 100 instructions, cache L2 = 20 instructions, cache L1 = 1 seule instruction de pénalité).
Mais ces caches sont en quantité limitée, et peuvent facilement être gaspillé si les programmes n’en tirent pas partie correctement : ils sont gérés par bloc de 128 (en général) octets consécutifs. Idéalement, on veut avoir un max de données « utiles » dedans, et pas de données non utilisées. Ne pas stocker des objets complet en mémoire (exemple un point 3D = {posXYZ, normale XYZ, coordoonées UV de texture etc.), mais les éclater en tableaux de chaque champs (un tableau de positions, un de normales, un de coordonnées de textures etc.). Parce que si je fais des calculs avec les positions de mes points, je ne veux pas gaspiller de la bande passante et du cache mémoire avec les normales, coordonnées de textures etc.
Et c’est pareil (voire même pire) sur GPU depuis une grosse dizaine d’années : il vaut mieux créer les tableaux de positions/normales/etc. séparément, il y a eu des caches rajoutés sur les unités de textures puis sur les unités de shaders. Et les groupe de threads exécutant un même shaders partagent une mémoire locale super rapide mais très petite (48kb à 64kb par groupe de 32 à 64 threads en générale), l’équivalent du cache mémoire d’un CPU… Sauf qu’il faut le gérer et l’utiliser à la manos dans les compute shaders. Et les accès mémoires des threads d’un même groupes doivent être « cohérents » : se suivre en mémoire (la thread 0 lit les octets 0 à 31, la thread 1 lit 31 à 63, la thread 2 lit 64 à 95 etc.); sinon ils n’auront pas lieu en même temps, et le programme tournera entre 2x et 64x plus lentement.
Trop de programmeurs ont encore une vieille mentalité des années 80s où il n’y avait pas de cache mémoire et l’on peut allouer des objets complexes en se foutant de la représentation en mémoire; mais c’est pourtant souvent l’élément essentiel à gérer pour les performances d’un programme; pas les GHz ou nombre de calculs en flottant/seconde. Et je ne parle pas des langages comme Java qui ne permettent que très très difficilement de gérer « correctement » la mémoire.
Bref : les nombres de TFlops ou opérations/s ou autre ne veulent pas dire grand chose.
C’est comme pour les voitures : annoncer une puissance max, c’est pratique pour comparer en un chiffre, mais ça n’indique pas si cette puissance est due à un couple fort ou à un régime moteur élevé, comment la boite est étagée etc. C’est plus simple et facile - mais trop simple - avec un seul chiffre.
5 « J'aime »
Si t’as 1+ Milliard de dollar … 
« Les ARMs sont les champions de la perf/watt. Mais sont bien derrière en performances pures. »
Certainement plus pour très longtemps…
System
Xiaomi Redmi K30
Qualcomm Qualcomm 1804 MHz (8 cores, ARM)
Uploaded
Jun 06, 2020
Platform
Android
Single-Core Score
5441
Multi-Core Score
16245
Ils acceptent les billets de Monopoly ?
2 « J'aime »
Ils courent vite mais ils sont toujours à la traine! Et surtout si on regarde autre chose que les benchs synthétiques qui se limitent plus ou moins quelques opérations simples en boucle.
Il y a déjà des ARM qui ont des résultats Geekbench équivalents à un i7 entrée de gamme. Effectivement en bureautique ta machine sera aussi performante, en jeu avec l’Intel HD intégré aussi (mais l’intel HD a un handicap), et sur du calcul complexe (calculs matriciels ou trigo, beaucoup de mémoire utilisée), le i7 explose complètement l’équivalent ARM (genre x20 à x100 plus rapide).