Diseño de sistemas HPC: OPS y FLOPS

Hola y mil gracias por leerme. Te escribe Simón Sánchez y en esta ocasión hablaremos sobre Diseño de sistemas HPC: OPS y FLOPS

Este es el primero de varios artículos que discuten las diversas tecnologías y criterios de diseño utilizados para los sistemas HPC. La construcción de sistemas informáticos de cualquier tipo, pero especialmente sistemas muy grandes, es algo similar al proceso al que se enfrenta un desarrollador inmobiliario de apartamentos. El desarrollador debe tener una idea de cómo se verá el producto final, sus características atractivas y su estrategia de comercialización.

¿Construyen cada unidad de la misma manera o proporcionan algún nivel de heterogeneidad, diferentes planos de planta? ¿Construyen un edificio monolítico o un pueblo con pasarelas? ¿Qué nivel de personalización, si corresponde, debería permitirse?

En el diseño HPC contemporáneo nos enfrentamos a un proceso de toma de decisiones similar. ¿Construimos sistemas estrechamente acoplados, enfatizando el ancho de banda de entrenudo y punto flotante, o construimos nodos con múltiples subprocesos extensivos que pueden hacer referencia al azar a conjuntos de datos? En ambos casos, siempre debemos escalar tanto como sea posible.

Y finalmente tenemos la imagen de marketing del sistema bajo un hermoso cielo azul con las montañas o el lago de fondo. Como pretendemos comercializar a compradores internacionales, debemos comprender qué idiomas admitir en nuestro sitio web de marketing. Casi lo olvido: ¿Vendemos estos sistemas directamente o basamos nuestro modelo financiero en un acuerdo de tiempo compartido en condominio?

¿La programación de un sistema HPC es lo mismo que el anterior? Por ejemplo, puede elegir entre ampliar los idiomas existentes o crear otros nuevos. Los lenguajes son específicos del dominio que son exclusivos de un espacio de aplicación en particular, como HTML, Verilog o SQL; ¿O agregamos nuevas características a los lenguajes existentes, como primitivas del espacio de direcciones global, como UPC?

Para esta pieza inicial, discutiremos estos problemas de diseño en el contexto de «big data». Parece razonable sugerir que la creación de un sistema exaOPS para sistemas de big data es diferente a la construcción de una máquina exaFLOPS para aplicaciones técnicas. ¿Pero es? Si bien las aplicaciones son claramente diferentes, eso no significa necesariamente que la arquitectura subyacente también deba serlo.

La siguiente tabla compara algunas de las características de OPS versus FLOPS a nivel de nodo.

El examen de los atributos enumerados anteriormente conduciría inicialmente a la observación de que existen diferencias sustanciales entre los dos. Sin embargo, mirar un diseño lógico de hardware revela una perspectiva ligeramente diferente. Ambos sistemas requieren la cantidad de memoria física que se puede admitir directamente, sujeto a restricciones de refrigeración y energía. A ambos sistemas también les gustaría tanto ancho de banda de memoria real como sea posible.

Para ambos sistemas, la lógica utilizada por las ALU tiende a ser mínima. Por lo tanto, la cantidad de espacio real que se utiliza para una ALU de punto flotante de diseño personalizado es relativamente pequeña. Esto es especialmente cierto si se tiene en cuenta que la multiplicación de enteros de 64 × 64 es un cálculo de direcciones primitivo que se utiliza a menudo en aplicaciones de Big Data y HPC. En muchos casos, la multiplicación de números enteros es parte del diseño de una ALU de coma flotante IEEE.

Si profundizamos un poco más, llegamos a la conclusión de que el elemento principal de la puerta es el ancho de banda y la latencia de la memoria sostenidos. Necesitamos determinar cuánto tiempo se tarda en acceder a un operando y cuántos se pueden acceder simultáneamente Dada una arquitectura de memoria específica, necesitamos descubrir el mejor modelo de estado de máquina para el cálculo. ¿Estos registros administrados por el compilador utilizan RAM que normalmente estaría asociada con una caché L3, o continúan cambiando el tamaño de un plano de planta similar al que se muestra a continuación?

El principal problema es la eficiencia. Podemos discutir esto incesantemente. A medida que los conjuntos de datos crecen, la localidad de las referencias (temporales y espaciales) disminuye y la aleatoriedad de las referencias aumenta. Cuales son las soluciones?

En HPC clásico, los programadores (y algunos compiladores) generan código que bloquea explícitamente conjuntos de datos en la caché, generalmente la caché privada L2 o compartida L3. Esta técnica tiende a funcionar lo suficientemente bien para las aplicaciones tradicionales de HPC. Sus principales deficiencias son el trabajo de codificación adicional y la falta de portabilidad del rendimiento entre diferentes arquitecturas de caché.

Varias técnicas, especialmente aquellas soportadas por las capacidades de autoajuste de LAPACK, funcionan lo suficientemente bien para muchas aplicaciones que manipulan matrices densas. En consecuencia, los sistemas de memoria están orientados a bloques y el soporte es inherente a los controladores de memoria de todos los microprocesadores contemporáneos.

Sin embargo, para big data, los inicios de sesión son relativamente aleatorios y este enfoque de bloque tiende a no funcionar. Dependiendo de la estructura de los datos (un árbol, un gráfico, una cadena), se utilizan diferentes enfoques para hacer que las referencias a la memoria sean más eficientes.

Además, para el trabajo de big data, el rendimiento se mide en términos de rendimiento de transacciones o consultas por segundo, no en FLOPS. Coincidentemente, quizás, la estructura de memoria óptima es la memoria principal HPC clásica, lo que significa memoria principal altamente intercalada, orientada a la dispersión / recopilación de palabras. Este fue el enfoque utilizado en las máquinas Cray, Convex, Fujitsu, NEC e Hitachi.

Hay otra dinámica interesante de la memoria interna del procesador basada en caché o registro: el consumo de energía y la complejidad del diseño. Si bien no es obvio de inmediato, para una determinada cantidad de estado de la máquina visible para el usuario, un caché tiene transistores adicionales para mantener su transparencia, lo que resulta en un consumo de energía adicional.

Por ejemplo, hay memoria para etiquetas y lógica para comparar las etiquetas de dirección generadas con las etiquetas de caché almacenadas. Se requiere lógica adicional para el control de la caché. Es difícil cuantificar la potencia incremental requerida, pero es incremental.

Otro aspecto de la caché frente al estado interno, especialmente para big data, es el modelo de referencia. Las referencias aleatorias tienen características deficientes de acierto de caché. Pero si los datos se pueden bloquear, la tasa de aciertos aumenta dramáticamente. La eficiencia de manejar grandes cantidades de máquina interna es proporcional a la arquitectura del hilo.

Necesitamos determinar si tenemos muchos subprocesos con conjuntos de registros de tamaño razonable o menos subprocesos, como una máquina vectorial, con una gran cantidad de estado de máquina. El último enfoque impone una carga al diseño de la memoria física.

La conexión de cachés privados L1 y L2 por núcleo es relativamente simple y escala a medida que aumenta la cantidad de núcleos. Una caché L3 compartida aumenta la complejidad del diseño interno. Necesitamos equilibrar el ancho de banda, los inicios de sesión simultáneos, la latencia y la coherencia del caché. La pregunta que se debe hacer es si es mejor usar RAM estática interna para registros de datos administrados por el compilador por núcleo / hilo.

Obviamente, ambas estructuras de memoria tienen sus propias compensaciones de costo / rendimiento. Un sistema de memoria basado en caché tiende a ser más económico, pero con menor rendimiento. El diseño del subsistema de memoria es más simple, ya que los DIMM DRAM estándar están disponibles comercialmente.

La arquitectura HPC clásica ofrece un mayor rendimiento y es aplicable a una gama más amplia de aplicaciones. El ancho de banda de memoria disponible se usa de manera más efectiva y los operandos se cargan y almacenan solo cuando es necesario; no hay tamaños de bloque para abordar.

En resumen, este artículo analiza la arquitectura del procesador de un solo nodo para el procesamiento convencional y centrado en datos de alto rendimiento. Hay muchas similitudes y muchas diferencias. La principal divergencia se encuentra en la interfaz y el modelo de referencia de memoria principal. Los cachés de datos se crearon hace décadas, pero no está claro si esta arquitectura sigue siendo óptima. ¿Las arquitecturas Hybrid Memory Cube (HMC) y Processor in Memory (PIM) se comprometerán con diseños más nuevos que se alejen de los diseños de memoria tradicionales? El tiempo dirá.

El próximo artículo discutirá los enfoques de diseño para interconexiones globales.

Deberías compartir en una historia de tu Instagram para que tus amigos lo consulten

??? ? ? ???

Comparte