StorageReview et nos partenaires viennent de résoudre Pi à 105 XNUMX milliards d'endroits, un nouveau record mondial qui bat le record précédent de cinq pour cent.
Nous ne sommes pas étrangers à l'idée de repousser les limites du calcul, mais celui-ci prend le Pi(e). Dans la foulée de celui de l'année dernière 100 référence à plusieurs milliards de chiffres, nous avons décidé de l'augmenter et de pousser les chiffres connus de Pi à 105 milliards de chiffres. Cela fait 105,000,000,000,000 3 105 6 XNUMX de nombres après le XNUMX. Nous avons apporté quelques mises à jour à la plateforme depuis l'année dernière, découvert quelques éléments surprenants tout au long du parcours et appris certaines choses en cours de route, notamment le XNUMX XNUMX milliards de chiffres de Pi ;XNUMX !
En réalisant un calcul record mondial de Pi à 105 2 milliards de chiffres, le laboratoire StorageReview a souligné les incroyables capacités du matériel moderne. Cet effort, alimenté par un système AMD EPYC Bergamo 128P de pointe à 1.5 cœurs équipé de XNUMX To de DRAM et de près d'un pétaoctet de SSD Solidigm QLC, représente une réalisation historique en matière de technologie de calcul et de stockage.
Le projet
Au cours de la course aux 100 16 milliards de données numériques, nous avons rencontré plusieurs limitations technologiques. La plate-forme serveur, par exemple, ne prenait en charge que XNUMX SSD NVMe dans les emplacements avant. Même si nous disposions de beaucoup de puissance CPU, ce calcul nécessitait un stockage massif pendant le processus et en back-end lors de la sortie du fichier TXT final.
Pour résoudre le problème de stockage la dernière fois, nous avons eu recours à des traîneaux adaptateurs PCIe NVME pour insérer trois autres SSD. Ensuite, pour la sortie, nous avions un serveur de stockage HDD en RAID0, remarquez, avec un partage iSCSI vers la boîte de calcul. Cette fois, nous voulions être un peu plus « entreprise » avec ce serveur, nous avons donc fait appel à quelques amis pour nous aider. Fait intéressant, il n’est pas aussi simple qu’il y paraît d’ajouter un tas de SSD NVMe à un serveur.
Le matériel
Le cœur de cette tâche monumentale était le système à double processeur AMD EPYC 9754 Bergamo, offrant 128 cœurs chacun. Les processeurs AMD, connus pour leurs performances exceptionnelles dans les tâches informatiques de haute complexité (IA, HPC, Big Data Analytics), a fourni la puissance nécessaire. À cela s'ajoutaient 1.5 To de DRAM, garantissant des vitesses de traitement et de transfert de données rapides. Parallèlement, près d'un pétaoctet de Stockage Solidigm QLC offrait une capacité et une fiabilité sans précédent.
Notre plate-forme de châssis de base est restée la même que celle de l'année dernière (un boîtier QCT), mais nous avons mis à niveau les processeurs vers des puces AMD EPYC 9754 Bergamo. Nous souhaitions rechercher une amélioration de la vitesse et du nombre décimal tout en évitant d'utiliser du stockage pour le calcul, ce qui nous a obligé à faire appel à SerialCables pour fournir un JBOF. Cela a présenté certains défis en soi, que nous détaillerons ci-dessous.
| Paramètre | Valeur |
|---|---|
| Date d'entrée en vigeur | mar. 19 déc. 14:10:48 2023 |
| Date de fin | mar. 27 février 09 53:16:2024 |
| Temps de calcul total | 5,363,970.541 62.08 XNUMX secondes / XNUMX jours |
| Temps de mur du début à la fin | 6,032,547.913 69.82 XNUMX secondes / XNUMX jours |
Période de calcul : Du 14 décembre 2023 au 27 février 2024, sur 75 jours.
- CPU: Deux processeurs AMD Epyc 9754 Bergamo, 256 cœurs avec multithreading simultané (SMT) désactivé dans le BIOS.
- Mémoire: 1.5 To de RAM DDR5.
- Stockage: 36 disques SSD Solidigm D30.72-P5 de 5316 To.
- 24 disques SSD Solidigm D30.72-P5 de 5316 To dans un JBOF SerialCables
- 12 disques SSD Solidigm D30.72-P5 de 5316 To dans le serveur directement connecté.
- Système opérateur: Windows Serveur 2022 (21H2).
Le chemin vers 105 XNUMX milliards
| Paramètre | Valeur |
|---|---|
| Constante | Pi |
| Algorithme | Tchoudnovski (1988) |
| Chiffres décimaux | 105,000,000,000,000 |
| Chiffres hexadécimaux | 87,200,612,490,794 |
| Mode d'enfilage | Cilk Plus Vol de Travail -> 256/256 |
| Mémoire de travail | 1,492,670,259,968 1.36 XNUMX XNUMX XNUMX (XNUMX Tio) |
| Mémoire totale | 1,492,984,298,368 1.36 XNUMX XNUMX XNUMX (XNUMX Tio) |
| Le plus grand point de contrôle logique | 157,783,654,587,576 144 XNUMX XNUMX XNUMX (XNUMX Tio) |
| Utilisation logique du disque de pointe | 534,615,969,510,896 486 XNUMX XNUMX XNUMX (XNUMX Tio) |
| Octets de disque logique lus | 44,823,456,487,834,568 39.8 XNUMX XNUMX XNUMX XNUMX (XNUMX PiB) |
| Octets de disque logique écrits | 38,717,269,572,788,080 34.4 XNUMX XNUMX XNUMX XNUMX (XNUMX PiB) |
Défis rencontrés
Un nouveau composant à cette exécution, nécessaire pour étendre le stockage disponible pour les processeurs, consistait à ajouter un NVMe JBOF. Notre plate-forme de test proposait 16 baies NVMe, les huit autres étant uniquement câblées pour SATA. Bien que notre exécution de 100 2 milliards ait exploité trois adaptateurs PCIe U.19 internes pour augmenter notre nombre de disques NVMe à XNUMX, ce n’était pas optimal. Pour cette réexécution, nous avons ajouté un Câbles série 24 baies U.2 JBOF, ce qui a été d'une grande aide de deux manières : davantage de stockage d'échange de calcul et de stockage de fichiers de sortie interne. Fini les serveurs de stockage HDD RAID0 fous !
Le JBOF à 24 baies de câbles série nous a permis de presque doubler le nombre de disques par rapport à notre exécution initiale. Nous avons alloué 30 disques à l'espace de swap y-cruncher, laissant 6 SSD pour un volume de sortie Storage Spaces RAID5. Un énorme avantage de cette approche est apparu lors de la phase de sortie, où nous n'avons pas été freinés par la vitesse d'une seule connexion 10 Go, comme lors de la première itération 100T Pi. Bien que le JBOF ait résolu le problème du nombre total de disques, il a néanmoins introduit une limitation : les performances des disques individuels.
Dans un serveur doté de disques SSD U.2 à connexion directe, il existe quatre voies PCIe par disque. Si chaque disque est directement connecté à la carte mère, cela équivaut à 96 voies PCIe pour 24 SSD. La bande passante totale du JBOF est limitée par le nombre de voies PCIe qu'il peut reconnecter à l'hôte.
Dans ce cas, nous avons utilisé deux cartes hôtes de commutateur PCIe, divisant le JBOF en deux groupes de 12 SSD. Chaque groupe de 12 SSD partageait alors 16 voies PCIe. Tout en offrant des avantages considérables dans la connexion des SSD à notre hôte, nous avons eu des scénarios dans lesquels les disques d'échange exécutés via JBOF prenaient du retard sur les disques directement connectés au serveur. Ce n'est pas une faute du JBOF. Il s'agit simplement d'une limitation technique ou plutôt d'une limitation du nombre de voies PCIe avec lesquelles le serveur peut fonctionner.
Les lecteurs avisés pourraient se demander pourquoi nous nous sommes arrêtés à 36 SSD dans cette série au lieu de monter à 40. C'est une histoire amusante. L'espace PCIe adressable a ses limites sur de nombreux serveurs. Dans notre cas, au nombre de 38 disques, le dernier SSD a pris l'adresse PCIe du chipset USB et nous avons perdu le contrôle du serveur. Pour jouer la sécurité, nous l'avons sauvegardé sur 36 SSD afin de pouvoir toujours accéder au BIOS ou nous connecter au serveur. Repousser les limites conduit à des découvertes surprenantes.
Aperçu du diagnostic et résolution
Le premier des deux principaux défis que nous avons rencontrés était lié à la performance. Ce que nous avons découvert, c'est Loi d'Amdahl en action. Un problème particulier est apparu lorsque y-cruncher semblait « se bloquer » sur notre système AMD Bergamo à 256 cœurs lors d'opérations importantes en mode swap. Ce blocage, caractérisé par un manque d'activité des E/S du processeur et des disques, a remis en question les attentes conventionnelles en matière de comportement logiciel. Cela a conduit à une plongée approfondie dans les subtilités de l’informatique parallèle et des interactions matérielles.
Le processus de découverte a révélé que le programme n'était pas vraiment suspendu mais fonctionnait dans une capacité très limitée, s'exécutant en monothread sur une configuration étendue de 256 cœurs. Ce comportement inhabituel a suscité des questions sur l'impact potentiel de la loi d'Amdahl, d'autant plus que les opérations impliquées n'étaient pas gourmandes en calcul et n'auraient pas dû provoquer de retards importants sur un système équipé de 1.5 To de RAM.
L'enquête a pris une tournure inattendue lorsque le problème a été reproduit sur un ordinateur grand public, mettant en évidence les graves implications de la loi d'Amdahl, même sur des systèmes moins étendus. Cela a conduit à un examen plus approfondi des causes sous-jacentes, qui a révélé un risque CPU spécifique à l'architecture Zen4 impliquant le super-alignement et ses effets sur les modèles d'accès à la mémoire.
Le problème a été exacerbé sur les processeurs AMD par une boucle dans le code qui, en raison de sa nature simple, aurait dû s'exécuter beaucoup plus rapidement que prévu. La cause première semble être une gestion inefficace de l'alias de mémoire par l'unité de stockage de chargement d'AMD. La résolution de ce problème complexe nécessitait à la fois d'atténuer le risque de super-alignement grâce à la vectorisation de la boucle à l'aide de AVX512 et de remédier au ralentissement provoqué par la loi d'Amdahl avec un parallélisme amélioré. Cette approche globale a non seulement résolu le problème immédiat, mais a également conduit à des optimisations significatives des processus informatiques de y-cruncher, créant ainsi un précédent pour relever des défis similaires dans des environnements informatiques hautes performances.
Le problème suivant a été rencontré lors des dernières étapes du calcul, qui s’arrêtaient de manière inattendue et ne fournissaient aucune information sur la cause de l’accident. L'accès à distance a été accordé à Alexander Yee et, pour la première fois depuis plus d'une décennie, la réalisation d'un enregistrement Pi a nécessité l'intervention directe du développeur.
Nous n'avons pas été impliqués dans ce processus de diagnostic, mais une erreur arithmétique critique en virgule flottante s'est produite dans le chemin de code AVX512 de l'algorithme de multiplication N63. Alexander a pu diagnostiquer à distance, fournissez un binaire fixe et reprenez à partir d'un point de contrôle, aboutissant à un calcul réussi après la mise en œuvre de correctifs logiciels cruciaux.
Réflexions et aller de l'avant
Cet effort illustre les complexités et les imprévisibilités du calcul haute performance. La résolution de ces défis a établi un nouveau record de calcul Pi et a fourni des informations précieuses sur les méthodologies de développement et de test de logiciels. La dernière version de y-cruncher, v0.8.4, intègre des correctifs pour les problèmes identifiés, promettant une stabilité améliorée pour les calculs futurs.
Calculer Pi à 105 XNUMX milliards de chiffres n’était pas une mince affaire. Cela impliquait une planification, une optimisation et une exécution méticuleuses. En tirant parti d'une combinaison de logiciels open source et propriétaires, l'équipe de StorageReview a optimisé le processus algorithmique pour exploiter pleinement les capacités du matériel, réduisant ainsi le temps de calcul et améliorant l'efficacité.
Avec des performances de lecture saturantes PCIe Gen4 et des capacités de pointe allant jusqu'à 61.44 To, les SSD Solidigm QLC offrent des résultats incroyables. « Imaginez ce que ces disques peuvent permettre dans le domaine du calcul haute performance ou des applications à forte intensité d'IA », a déclaré Greg Matson, vice-président de la planification stratégique et du marketing chez Solidigm. Nous sommes ravis que les SSD de Solidigm puissent alimenter la deuxième tentative record de Storagereview pour calculer pi. Leurs efforts prouvent les véritables capacités des disques de stockage de Solidigm, ouvrant un monde de possibilités pour les applications d'IA gourmandes en données.
Conclusion
La course jusqu’à 105 100 milliards de chiffres de Pi a été beaucoup plus complexe que prévu. Après réflexion, nous aurions dû nous attendre à rencontrer de nouveaux problèmes ; après tout, nous réalisons un calcul qui n'avait jamais été effectué auparavant. Mais avec les XNUMX XNUMX milliards de calculs complétés par une configuration beaucoup plus « ruban adhésif et grillage », nous pensions avoir réussi. En fin de compte, il a fallu un effort de collaboration pour amener cette plate-forme à franchir la ligne d'arrivée.
Alors que nous nous réjouissons avec nos partenaires de cette course record, nous devons nous demander : « Qu’est-ce que cela signifie ? Cinq milliards de chiffres supplémentaires de Pi ne feront probablement pas une énorme différence en mathématiques. Néanmoins, nous pouvons tracer quelques lignes entre les charges de travail informatiques et la nécessité d’un matériel sous-jacent moderne pour les prendre en charge. Fondamentalement, cet exercice montre que le matériel approprié fait toute la différence, qu'il s'agisse d'un cluster de centre de données d'entreprise ou d'une installation HPC de grande envergure.
Pour le calcul de Pi, nous étions complètement limités par le stockage. Des processeurs plus rapides contribueront à accélérer les calculs, mais le facteur limitant de nombreux nouveaux records du monde est la quantité de stockage local dans la boîte. Pour cette exécution, nous exploitons à nouveau le SSD Solidigm D5-P5316 de 30.72 To pour nous aider à obtenir un peu plus de 1.1 Po de flash brut dans le système. Ces disques SSD sont la seule raison pour laquelle nous avons pu battre les records précédents et atteindre 105 XNUMX milliards de chiffres Pi.
Cela soulève cependant une question intéressante. Beaucoup de nos abonnés savent que Solidigm a SSD de 61.44 To dans son D5-P5336 et jusqu'à 30.72 To dans le D5-P5430 SSD, disponibles dans plusieurs facteurs de forme et capacités. Nous avons examiné les disques et publié de nombreuses publications sur les réseaux sociaux présentant ces disques incroyablement denses. Avec 32 de ces SSD approchant les 2 Po de stockage, on pourrait se demander combien de temps ces 105 XNUMX milliards de chiffres de Pi resteront les plus grands au monde. Nous aimerions réfléchir, pas très longtemps.
Les plus grands chiffres décimaux connus de Pi
1432360875 9463978314 2999186657 8364664840 8558373926 : Chiffres jusqu'à 105,000,000,000,000 XNUMX XNUMX XNUMX XNUMX
S'engager avec StorageReview
Newsletter | YouTube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | Flux RSS
