StorageReview y nuestros socios acaban de resolver Pi en 105 billones de lugares, un nuevo récord mundial que supera el récord anterior en un cinco por ciento.
No somos ajenos a traspasar los límites de la computación, pero éste toma el Pi(e). Pisándole los talones al año pasado 100 punto de referencia de un billón de dígitos, decidimos aumentarlo y llevar los dígitos conocidos de Pi a 105 billones de dígitos. Eso son 105,000,000,000,000 números después del 3. Hicimos algunas actualizaciones en la plataforma desde la ejecución del año pasado, encontramos algunas cosas sorprendentes a lo largo del viaje y aprendimos algunas cosas en el camino, ¡incluido el dígito 105 billones de Pi;6!
Al lograr un cálculo récord mundial de Pi con 105 billones de dígitos, el laboratorio StorageReview ha subrayado las increíbles capacidades del hardware moderno. Este esfuerzo, impulsado por un sistema AMD EPYC Bergamo 2P de 128 núcleos de vanguardia equipado con 1.5 TB de DRAM y casi un petabyte de SSD Solidigm QLC, representa un logro histórico en tecnología computacional y de almacenamiento.
El Desafío
En la carrera digital de 100 billones, encontramos varias limitaciones tecnológicas. La plataforma del servidor, por ejemplo, sólo admitía 16 SSD NVMe en las ranuras frontales. Si bien teníamos mucha potencia de CPU, este cálculo requirió un almacenamiento masivo durante el proceso y en el back-end cuando se generó el archivo TXT final.
Para resolver el problema de almacenamiento la última vez, recurrimos a adaptadores PCIe NVME para insertar otros tres SSD. Luego, para la salida, teníamos un servidor de almacenamiento HDD en RAID0, eso sí, con un recurso compartido iSCSI en el cuadro de cálculo. Esta vez, queríamos ser un poco más “empresariales” con este servidor, así que trajimos a algunos amigos para que nos ayudaran. Curiosamente, no es tan fácil como parece agregar un montón de SSD NVMe a un servidor.
El hardware
El corazón de esta monumental tarea fue el sistema Bergamo de doble procesador AMD EPYC 9754, que ofrece 128 núcleos cada uno. Los procesadores de AMD, conocidos por su rendimiento excepcional en tareas computacionales de alta complejidad (IA, HPC, análisis de big data), proporcionó los caballos de fuerza necesarios. Para complementar esto, había 1.5 TB de DRAM, lo que garantizaba velocidades de transferencia y procesamiento de datos rápidos. Al mismo tiempo, casi un petabyte de Almacenamiento Solidigm QLC ofrecía capacidad y confiabilidad sin precedentes.
Nuestra plataforma de chasis base siguió siendo la misma que la del año pasado (una caja QCT), pero actualizamos las CPU a chips AMD EPYC 9754 Bergamo. Queríamos buscar una mejora en la velocidad y los decimales y al mismo tiempo evitar el uso de almacenamiento para el cálculo, lo que significaba que teníamos que recurrir a SerialCables para proporcionar un JBOF. Esto presentó algunos desafíos por derecho propio, que detallaremos a continuación.
| Parámetro | Valor |
|---|---|
| Fecha de Inicio | Mar 19 dic 14:10:48 2023 |
| Fecha Final | Mar 27 de febrero 09:53:16 2024 |
| Tiempo total de cálculo | 5,363,970.541 segundos / 62.08 días |
| Tiempo de pared de principio a fin | 6,032,547.913 segundos / 69.82 días |
Periodo de Cómputo: 14 de diciembre de 2023 – 27 de febrero de 2024, con una duración de 75 días.
- UPC: Procesadores duales AMD Epyc 9754 Bergamo, 256 núcleos con multihilo simultáneo (SMT) deshabilitado en BIOS.
- Memoria: 1.5 TB de RAM DDR5.
- Almacenamiento: 36 unidades SSD Solidigm D30.72-P5 de 5316 TB.
- 24 SSD Solidigm D30.72-P5 de 5316 TB en un JBOF de cables serie
- 12 SSD Solidigm D30.72-P5 de 5316 TB en el servidor conectado directamente.
- Sistema operativo: Servidor Windows 2022 (21H2).
El camino hacia los 105 billones
| Parámetro | Valor |
|---|---|
| Constante | Pi |
| Algoritmo | Chudnovsky (1988) |
| Dígitos decimales | 105,000,000,000,000 |
| Dígitos hexadecimales | 87,200,612,490,794 |
| Modo de enhebrado | Cilk Plus Robo de trabajo -> 256 / 256 |
| Memoria de Trabajo | 1,492,670,259,968 (1.36 TiB) |
| La memoria total | 1,492,984,298,368 (1.36 TiB) |
| Punto de control lógico más grande | 157,783,654,587,576 (144 TiB) |
| Uso máximo lógico del disco | 534,615,969,510,896 (486 TiB) |
| Lectura de bytes de disco lógico | 44,823,456,487,834,568 (39.8 PiB) |
| Bytes de disco lógico escritos | 38,717,269,572,788,080 (34.4 PiB) |
Desafíos encontrados
Un nuevo componente de esta ejecución, que era necesario para ampliar el almacenamiento disponible para los procesadores, fue agregar un NVMe JBOF. Nuestra plataforma de prueba ofrecía 16 bahías NVMe, y las ocho restantes solo estaban conectadas para SATA. Si bien nuestra ejecución de 100 billones aprovechó tres adaptadores PCIe U.2 internos para expandir nuestro número de unidades NVMe a 19, no fue óptima. Para esta repetición, agregamos un Cables serie 24 bahías U.2 JBOF, lo que ayudó significativamente de dos maneras: más almacenamiento de intercambio informático y almacenamiento interno de archivos de salida. ¡No más servidores de almacenamiento HDD RAID0 locos!
El JBOF de 24 bahías de cables serie nos permitió casi duplicar el número de unidades con respecto a nuestra ejecución original. Asignamos 30 unidades al espacio de intercambio de Y-cruncher, dejando 6 SSD para un volumen de salida RAID5 de Storage Spaces. Una gran ventaja de ese enfoque se produjo durante la etapa de salida, donde no nos frenó la velocidad de una sola conexión de 10 Gb, como la primera iteración de 100T Pi. Si bien el JBOF abordó el problema del recuento total de unidades, introdujo una limitación: el rendimiento de las unidades individuales.
En un servidor con SSD U.2 de conexión directa, hay cuatro carriles PCIe por unidad. Si cada unidad está conectada directamente a la placa base, eso equivale a 96 carriles PCIe para 24 SSD. El ancho de banda total del JBOF está limitado por la cantidad de carriles PCIe que puede conectar al host.
En este caso, utilizamos dos tarjetas host de conmutador PCIe, dividiendo el JBOF en dos grupos de 12 SSD. Luego, cada grupo de 12 SSD compartió 16 carriles PCIe. Si bien seguimos ofreciendo ventajas considerables al conectar los SSD a nuestro host, tuvimos escenarios en los que las unidades de intercambio que se ejecutaban a través del JBOF quedaron detrás de las unidades conectadas directamente al servidor. Esto no es culpa del JBOF. Es solo una limitación técnica o más bien una limitación de con cuántos carriles PCIe puede trabajar el servidor.
Los lectores astutos podrían preguntarse por qué nos detuvimos en 36 SSD en esta versión en lugar de llegar a 40. Es una historia divertida. El espacio PCIe direccionable tiene sus límites en muchos servidores. En nuestro caso, con el recuento de 38 unidades, el último SSD tomó la dirección PCIe del chipset USB y perdimos el control del servidor. Para ir a lo seguro, lo respaldamos en 36 SSD para poder acceder al BIOS o iniciar sesión en el servidor. Superar los límites conduce a algunos descubrimientos sorprendentes.
Información diagnóstica y resolución
El primero de los dos principales desafíos que encontramos estaba relacionado con el rendimiento. Lo que descubrimos fue Ley de Amdahl en acción. Surgió un problema peculiar cuando parecía que y-cruncher se "colgaba" en nuestro sistema AMD Bergamo de 256 núcleos durante grandes operaciones en modo de intercambio. Este bloqueo, caracterizado por una falta de actividad de E/S de CPU y disco, desafió las expectativas convencionales sobre el comportamiento del software. Esto llevó a una inmersión profunda en las complejidades de la computación paralela y las interacciones de hardware.
El proceso de descubrimiento reveló que el programa no estaba realmente bloqueado, sino que operaba con una capacidad muy limitada, ejecutando un solo subproceso en una configuración expansiva de 256 núcleos. Este comportamiento inusual generó dudas sobre el impacto potencial de la Ley de Amdahl, especialmente porque las operaciones involucradas no requerían un uso intensivo de computación y no deberían haber causado retrasos significativos en un sistema equipado con 1.5 TB de RAM.
La investigación dio un giro inesperado cuando el problema se replicó en el escritorio de un consumidor, destacando las graves implicaciones de la Ley de Amdahl incluso en sistemas menos extensos. Esto llevó a un examen más profundo de las causas subyacentes, que descubrió un peligro de CPU específico de la arquitectura Zen4 que involucraba superalineación y sus efectos en los patrones de acceso a la memoria.
El problema se vio agravado en los procesadores AMD por un bucle en el código que, debido a su naturaleza simple, debería haberse ejecutado mucho más rápido de lo observado. La causa principal parecía ser el manejo ineficiente del alias de memoria por parte de la unidad de almacenamiento de carga de AMD. La resolución de este complejo problema requirió mitigar el peligro de superalineación mediante la vectorización del bucle usando AVX512 y abordar la desaceleración causada por la Ley de Amdahl con un paralelismo mejorado. Este enfoque integral no solo resolvió el problema inmediato sino que también condujo a optimizaciones significativas en los procesos computacionales de y-cruncher, sentando un precedente para abordar desafíos similares en entornos informáticos de alto rendimiento.
El siguiente problema se encontró en los pasos finales del cálculo, que se detenía inesperadamente y no proporcionaba información sobre la causa del accidente. Se concedió acceso remoto a Alexander Yee y, por primera vez en más de una década, completar un registro Pi requirió la intervención directa del desarrollador.
No nos involucramos en este proceso de diagnóstico, pero hubo un error aritmético crítico de punto flotante dentro de la ruta del código AVX512 del algoritmo de multiplicación N63. Alexander pudo diagnosticar de forma remota, proporciona un binario fijo y se reanuda desde un punto de control, lo que culmina en un cálculo exitoso después de implementar correcciones de software cruciales.
Reflexiones y Avanzar
Este esfuerzo ilustra las complejidades e imprevisibilidades de la informática de alto rendimiento. La resolución de estos desafíos estableció un nuevo récord en el cálculo de Pi y proporcionó información valiosa sobre el desarrollo de software y las metodologías de prueba. La última versión de y-cruncher, v0.8.4, incorpora correcciones para los problemas identificados, lo que promete una mayor estabilidad para futuros cálculos.
Calcular Pi con 105 billones de dígitos no fue tarea fácil. Implicó una planificación, optimización y ejecución meticulosas. Aprovechando una combinación de software propietario y de código abierto, el equipo de StorageReview optimizó el proceso algorítmico para aprovechar al máximo las capacidades del hardware, reduciendo el tiempo computacional y mejorando la eficiencia.
Con un rendimiento de lectura saturado PCIe Gen4 y capacidades líderes en la industria de hasta 61.44 TB, los SSD Solidigm QLC ofrecen resultados increíbles. "Imagínese lo que estas unidades pueden permitir en computación de alto rendimiento o aplicaciones intensivas en IA", dijo Greg Matson, vicepresidente de planificación estratégica y marketing de Solidigm. Estamos encantados de que los SSD de Solidigm puedan impulsar el segundo intento récord de Storagereview para calcular pi. Sus esfuerzos demuestran las verdaderas capacidades de las unidades de almacenamiento de Solidigm, abriendo un mundo de posibilidades para aplicaciones de IA con uso intensivo de datos”.
Conclusión
El camino hacia los 105 billones de dígitos de Pi fue mucho más complejo de lo que esperábamos. Tras reflexionar, deberíamos haber esperado encontrar nuevos problemas; después de todo, estamos completando un cálculo que nunca antes se había hecho. Pero con el cálculo de 100 billones completado con una configuración mucho más de “cinta adhesiva y alambre de gallinero”, pensamos que lo habíamos logrado. Al final, fue necesario un esfuerzo de colaboración para que este equipo llegara a la meta.
Si bien nos regocijamos con nuestros socios por esta racha sin precedentes, debemos preguntarnos: "¿Qué significa esto?" Cinco billones más de dígitos de Pi probablemente no supondrán una gran diferencia para las matemáticas. Aún así, podemos trazar algunas líneas entre las cargas de trabajo computacionales y la necesidad de hardware subyacente moderno para soportarlas. Fundamentalmente, este ejercicio refleja que el hardware adecuado marca la diferencia, ya sea un clúster de centro de datos empresarial o una gran instalación de HPC.
Para el cálculo de Pi, estábamos completamente restringidos por el almacenamiento. Las CPU más rápidas ayudarán a acelerar las matemáticas, pero el factor limitante para muchos nuevos récords mundiales es la cantidad de almacenamiento local en la caja. Para esta ejecución, nuevamente estamos aprovechando el SSD Solidigm D5-P5316 de 30.72 TB para ayudarnos a obtener un poco más de 1.1 PB de flash sin formato en el sistema. Estos SSD son la única razón por la que pudimos superar los récords anteriores y alcanzar los 105 billones de dígitos Pi.
Sin embargo, esto plantea una pregunta interesante. Muchos de nuestros seguidores saben que Solidigm tiene SSD de 61.44 TB en su D5-P5336 y hasta 30.72 TB en el D5-P5430 SSD, disponibles en múltiples factores de forma y capacidades. Hemos revisado las unidades y tenemos muchas publicaciones en las redes sociales que muestran estas unidades increíblemente densas. Con 32 de estos SSD acercándose a los 2 PB de almacenamiento, uno podría preguntarse cuánto tiempo esos 105 billones de dígitos de Pi seguirán siendo los más grandes del mundo. Nos gustaría pensar, no mucho.
Los dígitos decimales más grandes conocidos de Pi
1432360875 9463978314 2999186657 8364664840 8558373926: Dígitos hasta 105,000,000,000,000
Interactuar con StorageReview
BOLETÍN | YouTube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | RSS Feed
