- Este chip de investigación, presentado en Hot Chips 2023, está orientado al procesamiento de datos ultra dispersos de DARPA HIVE y ofrece un total de 528 hilos de hardware en 8 núcleos
- El análisis de cargas de trabajo mostró que, aunque hay mucho paralelismo, el aprovechamiento de líneas de caché y la eficiencia de los pipelines largos out-of-order son bajos, por lo que se necesitó un diseño distinto al de un CPU de servidor convencional
- El procesador no está basado en x86, sino en una ISA RISC, y maneja concurrencia masiva con 66 hilos por núcleo y un pipeline multihilo
- La comunicación entre chips se conecta mediante una malla óptica directa mesh-to-mesh basada en fotónica de silicio, lo que permite comunicarse directamente incluso con núcleos fuera del chasis sin switches ni NIC
- La implementación es un CPU de 8 núcleos a 75 W en TSMC 7nm y, dado que más de la mitad de la energía se usa en los enlaces ópticos, sigue siendo un diseño experimental en etapa de laboratorio
CPU de 528 hilos orientado a DARPA HIVE
- En Hot Chips 2023, Intel mostró la tecnología de direct mesh-to-mesh optical fabric por separado de sus chips de servidor convencionales
- El objetivo central del diseño es procesar los datos ultra dispersos requeridos por el programa DARPA HIVE
- El perfilado de cargas de trabajo de Intel mostró características que no encajan con el diseño de un CPU común
- Existe paralelismo a gran escala
- El aprovechamiento de líneas de caché es bajo
- La estructura de pipeline largo out-of-order no se aprovecha lo suficiente
- En respuesta, el procesador fue diseñado como una configuración de socket de 8 núcleos
- 66 hilos de hardware por núcleo
- 528 hilos en total
- ISA RISC en lugar de x86
- Cada núcleo usa un pipeline multihilo
Conexión directa entre chips con fotónica de silicio
- Este chip usa una configuración que coloca 16 sockets en una sola bandeja de cómputo OCP y los une con redes ópticas
- Un chip de I/O de alta velocidad enlaza las señales eléctricas con las funciones ópticas
- En la red on-die se colocan routers, y la mitad de los 16 routers tiene la función de dar más ancho de banda al I/O de alta velocidad
- En la capa de interconexión física dentro del paquete se usa EMIB
- En la conexión off-die, cada chip impulsa la red óptica mediante fotónica de silicio
- La conexión entre núcleos puede hacerse directamente entre chips
- Es posible conectarse sin switches ni NIC incluso si no están en el mismo chasis
- El chip completo está compuesto como un paquete multichip basado en EMIB
- Al integrar el motor de fotónica de silicio surgieron retos adicionales en la parte que conecta el paquete con las hebras de fibra óptica
- En términos de energía, se trata de una implementación de CPU de 8 núcleos a 75 W, y más de la mitad de la energía se usa en la fotónica de silicio
- La foto real del die confirmó el uso del proceso TSMC 7nm, y el trabajo sigue en curso en laboratorio
- La parte de enlaces ópticos contó con ayuda de Ayar Labs
- El conector enchufable que Intel mostró en Innovation 2022 no se utilizó en esta implementación
1 comentarios
Opiniones de Hacker News
Con 66 hilos por núcleo, parece más un procesador barrel que cualquier otra cosa.
Es difícil esperar que cada hilo sea rápido, pero si el procesador tiene suficiente trabajo, puede verse como que, en lugar de esperar a la memoria, puede hacer trabajo útil la mayor parte del tiempo.
La principal debilidad de los procesadores barrel está del lado de las personas. Muy poca gente sabe diseñar código que realmente aproveche su potencial. Como el código común también corre más o menos bien, a nivel de código parece familiar, pero no rinde bien a menos que se escriba de una forma que resulta muy extraña para alguien que solo ha escrito código para CPU.
Es una arquitectura peculiar para diseñar estructuras de datos y algoritmos, y tampoco hay mucha literatura sobre diseño de algoritmos para procesadores barrel.
He diseñado código para varias arquitecturas de procesadores barrel desde los antiguos sistemas Tera, y llegué a hacerlo bastante bien; creo que, si los usa alguien que realmente sabe, pueden ser más eficientes computacionalmente que casi cualquier arquitectura para cómputo general con un presupuesto de silicio similar.
Sin embargo, para escribir código eficiente hay que mantener en la cabeza un modelo mucho más complejo que el del código equivalente para CPU. La economía favorece a arquitecturas como las CPU, donde incluso un ingeniero promedio puede lograr una eficiencia razonable.
A pesar de sus ventajas en eficiencia de cómputo pura, ya dejé de esperar que veamos procesadores barrel en el mainstream.
Esa parte del núcleo se parece mucho a una GPU existente.
Lo distinto en esta CPU experimental de Intel es que, además de la parte tipo GPU, cada núcleo también incluye 2 hilos muy rápidos. Estos ejecutan fuera de orden, funcionan a una frecuencia mucho más alta que los hilos lentos y cada uno tiene unidades de ejecución no compartidas.
Los 2 hilos rápidos y los 64 hilos lentos, vistos por separado, se parecen a CPUs o GPUs antiguas, pero lo novedoso es combinarlos dentro de un único núcleo con memoria scratchpad y caché compartidas.
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
Apostaría a que el proyecto de DARPA que apoyó esta investigación viene de la misma línea de interés por siglas de 3 letras que le dio a Tera suficiente dinero para comprar Cray.
Si cambias "esperar a la memoria" por "esperar a la entrada/salida", el panorama es casi el mismo.
Mientras ocurre una carga lenta, el sistema puede ejecutar más instrucciones de otros hilos en paralelo.
Marvell hizo una CPU ARM SMT8 que presumía 768 Threads Per Node.
https://www.servethehome.com/marvell-thunderx3-arm-server-cp...
Según recuerdo, apuntaba a cargas de trabajo de bases de datos, y la lógica central era la misma: si normalmente los núcleos están ociosos esperando a la RAM, entonces conviene procesar otros hilos mientras tanto.
IBM y Zen4C cubren en cierta medida esta demanda, pero me gustaría ver más instancias cloud SMT16 orientadas explícitamente a estas cargas de trabajo de bajo throughput de instrucciones.
En estos diseños tipo procesador barrel, CMT8/SMT8 parece un punto adecuado.
Parece una propuesta en la que, si se puede amortizar el costo de área en el die y la pérdida de velocidad de convertir señales eléctricas en señales ópticas, los interconectores ópticos pueden ofrecer velocidades prácticamente independientes de la distancia con buena eficiencia.
Claro que no será totalmente así, pero si se limita a distancias de portadores de chips dentro de un solo chasis, hay poca interferencia y el cableado también es libre dentro del radio de curvatura de las guías ópticas.
Puede que lo haya leído mal. Los componentes ópticos podrían tener otro objetivo, como el apilado de dies, o quizá la idea sea hacer una retícula de chips sobre un superportador y conectarlos con interconectores ópticos.
Que haya fotos reales del die y confirmación de que se fabricó en TSMC 7 nm debe ser una escena bastante dolorosa para Intel.
Si tienen que usar la fab de un competidor para algo así, como fabricante de chips debe de ser un momento bastante bajo.
Pero el nodo de 10 nm fue un desastre para Intel y dejó a la empresa unos 5 a 10 años atrás en el negocio de fabricación de chips.
Es fácil imaginar que, para un proyecto de investigación, prefieran TSMC.
Eso explica por qué cosas raras como esta terminan en TSMC. Por ejemplo, Silicon Photonics en sí se desarrolla en Albuquerque, un sitio que estaba prácticamente muriéndose.
Si buscas en Google acotando el período a 2001–2010, puedes encontrar noticias al respecto.
Debe haber alguna razón por la que los usuarios de HN no saben mucho de semiconductores. Probablemente porque el público es sobre todo de software. En este sitio, parece ser el campo con la mayor proporción entre confianza y calidad de explicación.
AMD hizo lo mismo cuando abandonó GlobalFoundries, y también podría decirse que esa fue una razón principal por la que logró adelantarse a Intel.
Al fin y al cabo, todos usan equipos de litografía de ASML, así que quién mete el wafer en la máquina es algo un poco secundario.
Esto parece más una CPU de prueba de concepto que un producto vendible.
Es muy especializada, y todavía están en la etapa de encontrar qué problemas y cargas de trabajo va a resolver.
Espero que en el futuro los fotones también lleguen a la computación de propósito general. Como mínimo, para lidiar con el problema creciente del calor residual. Lo que llama especialmente la atención es el cambio de proceso de 10 nm a 7 nm.
Sun también hizo algo parecido hace mucho, pero luego lo abandonó en los CPU UltraSPARC.
¿Será que los hilos se quedaban sin trabajo? ¿Habrán decidido que era mejor reducir la cantidad de núcleos y hacerlos más rápidos? Es difícil encontrar detalles.
Sería bueno que bcantrill de HN contara qué pasó por dentro.
Muchas veces había que ajustar muchísimos más parámetros o recompilar para sacarles rendimiento.
Para mí también coincidió con una época en la que creció mucho la necesidad de usar SSL; SSL estaba bien optimizado para x86, pero no tanto para Sparc. Así que además había que lidiar con complejidades como tarjetas de offloading SSL o proxies inversos.
Al final, fuera de algunos nichos, era demasiado difícil hacer que funcionaran bien.
Tal vez no haya sido un factor enorme, pero también era una molestia para los administradores de sistemas. Mucho de lo que teníamos que hacer era serial y centrado en un solo núcleo. Es decir, mostraba su peor cara justo al grupo que normalmente aprueba las compras a proveedores.
Esto parece perfecto para reducción de grafos y programación de flujo de datos.
Si llega a producción real, creo que se podrían construir cosas bastante geniales con algo así.
¿528 hilos en 8 núcleos? ¿Cómo sale esa cuenta? Pensé que eran 512 y tuve que volver a leer.
Por la carga de trabajo, parece que la caché no se aprovecha bien, y esto no es x86 sino un conjunto de instrucciones RISC.
Aquí, 2 es la cantidad de hilos lentos como los de los CPU actuales, y 64 se parece más a hilos de GPU.
Esta arquitectura podría ser el siguiente paso de la integración de GPU. Ojalá logren escribir implementaciones eficientes de las bibliotecas matemáticas estándar. Podría ser más rápida que tener CPU+GPU separados dentro de un mismo paquete.
No se explica por qué son 66.
Ya es hora de terminar de reescribir todo el código para que sea orientado a eventos, con io_uring, etc.
La Tera MTA que mencionaron otros tenía, o tiene, sincronización por hardware en el sistema de memoria para eso.
No había interrupciones, solo hilos esperando a que alguien los despertara.
¿Leí bien el artículo? ¿Significa que hay 32 GB de DRAM en el chip, o simplemente usa DIMM estándar?
Lo interesante es que usan DIMM personalizados y un controlador de memoria para acceder en unidades de 8 bytes. Además, como se ve en la foto del die, cada núcleo tiene su propio controlador de memoria.
Si cada controlador de memoria administra 4 GB de DRAM, eso explicaría los 32 GB por chip.
También hay materiales que lo explican con más detalle, Nvidia parece hacer esto con Grace Hopper y Apple hace algo similar con los chips de la serie M.
Actualización: en este caso parece ser simplemente DDR5, más precisamente “custom DDR5-4400 DRAM”.