Barrapunto

En un vectorial, operaciones con matrices enormes se pueden codificar "a mano" de forma sencilla, en una Nvidia (al menos en la mía) es una puñeta..

Según lo que entiendas por enormes. Tienes cuBlas para las operaciones típicas, y hace cómodo y rápido el álgebra lineal.

como se te ocurra usar la memoria principal y pasar de las caches para simplificar el código no tira todo lo que debería tirar

Solo como nota: no son caches, son memorias scratchpad (también tienen caches, pero se usan gratis y sin esfuerzo, es cambiar la función de acceso a la memoria). Y para un procesador vectorial, tampoco es suficiente con una vectorización de "grano grueso". Tienes que ordenar las operaciones adecuadamente para que puedan ser encadenadas y no te comas las latencias gordas. Los datos tienen que estar bien ordenados y, en caso de no estarlo, a diferencia de lo que ocurre en una NVIDIA, simplemente no puedes trabajar con ello (tienes que reordenarlo y hacer la operación vectorial). Los SX-6/9 no los he programado, pero los Y-MP sí, y me resultaba muchísimo más engorroso que CUDA.

35860/40960 = ~87%, 1105000/1456000 = ~76%

Estás comparando un benchmark, Linpak, que es una aplicación muy específica, muy fácil, muy conocida y muy afinada. Habría que ver qué sale con el Linpak programado en CUDA. Y que el pico en doble precisión sea bajo no quita que en simple precisión se hayan alcanzado picos de entre el 80 y el 90% con aplicaciones de verdad (cuando lo normal suele ser, como te digo, el 50% en los mejores casos, mucho menos en casos medios, en los que en la GPU se puede alcanzar fácilmente el 33%). También habría que ver qué se está tomando como valor de pico, si el máximo posible (un bucle indefinidamente grande donde todo va perfecto para el procesador) o el pico de la arquitectura (multiplicar la frecuencia de reloj por las operaciones posibles por ciclo).

Así que el rendimiento respecto a su potencia máxima de las Nvidia no es nada sorprendente.

Como te digo, unos cojones. Ponme una aplicación real que saque ese % del pico. Una aplicación real, no un benchmark (aunque el kernel sea natural). Reconstrucción 3D, simulación de elementos finitos (fluidos, rígidos, etc), simulaciones de física de altas energías... cosas concretas, no me vale un kernel donde solo salen las operaciones adecuadas y bien puestecitas.

El teclado de mi portátil es más grande que un procesador + 64GB de un SX-9, y los rack de 16 procesadores creo que son los típicos 42U.

En serio, no puedes poner uno de esos encima de la mesa. Era una pregunta retórica. Requieren de una instalación adecuada, un entorno refrigerado y, cosa importante en este caso, que el sonido esté aislado. Esos cacharros están hechos para ser enracados en un armario que esté en una sala refrigerada y aislada, y para ser compartidos entre mucha gente (nada de "one researcher, one supercomputer).

Depende de la arquitectura, los SX6/9 funcionan con encadenamiento general, así que no "llegan tarde". No obstante, reordenar las operaciones y sacar dependencias es lo "bonito" de estas arquitecturas.

Buscando rendimientos del SX-6, he encontrado:
http://www.ultrasim.info/gordon6.pdf [ultrasim.info]
El problema es de simulación atmosférica
Le sacan un 81% del pico con 80 procesadores y un 65% con 5120 procesadores