Tengo una perspectiva algo diferente a la expresada por Noam Ben-Ami.
La ley de Moore no está muerta. Ahora estamos en procesos de 10 nm, solo implementados en RAM por una compañía hasta el momento, y aunque Intel ha anunciado que se están deshaciendo de su “tic-tac” de arquitectura-arquitectura retráctil … aún no se ha hecho. Elija un sustrato diferente, y estamos de vuelta en el negocio hasta quizás 3 nm.
El límite absoluto son los sistemas nanomecánicos, lo que significa pequeños conjuntos de átomos y computación termodinámicamente reversible, y así sucesivamente. Excepto las computadoras cuánticas, y una forma fácil de lograr la densidad de la capa de obleas 3D, y otras cosas que podrían suceder para sacar a ese conejo del sombrero.
La Ley de Moore tiene mucho camino por recorrer.
Sin embargo … ya hemos pasado el tren por este acantilado un par de veces.
Y cada vez, ha habido un cambio de enfoque.
Y si bien hemos visto algunas cosas interesantes (léase: tanto útiles como inesperadas ), en su mayoría en torno a algoritmos, en su mayor parte, somos más pobres para la prueba .
Escogeré mis tres caballos favoritos en esta carrera …
Multiplicadores de reloj
Parece una idea ingeniosa, ¿verdad?
Su CPU tiene el doble de velocidad, y todo lo demás permanece a la misma velocidad, y obtiene más ciclos de cálculo para resolver su problema. Solo el cuello de botella en las cosas tiende a ser el ancho de banda de E / S, y eso significa la velocidad del bus por el ancho como un porcentaje de la velocidad del reloj de la CPU frente al tamaño de la línea de caché de la CPU.
Entonces sí: obtuviste CPU más rápidas, y pudiste hacer mucho trabajo en una pequeña cantidad de datos (porque si necesitabas más datos, te enfrentarías al problema de alimentar la CPU lo suficientemente rápido). Pero significaba que tenías tendencia a:
- Solo opere en pequeños conjuntos de datos, que limitaron artificialmente los tipos de problemas que incluso intentó resolver con las computadoras
- Solía tener un exceso de ciclos de CPU, en comparación con los datos que deseaba procesar, por lo que tendía a escribir un código menos eficiente, porque, oye, estaba arrojando hardware al problema del ciclo de la CPU, por lo que tenía los ciclos para de repuesto
Pero todo lo que pudimos ver a partir de entonces fueron los problemas relacionados con el cómputo.
En otras palabras: ¡limitamos los tipos de problemas que incluso intentamos resolver!
Agrupamiento
Antes de que hubiera multinúcleo, había agrupación, principalmente porque … éramos terribles en la construcción de multinúcleo.
Aquí es donde obtuvimos ideas como NUMA (que en realidad no es una mala idea) y multiprocesadores asimétricos (que, hey: todavía tengo mi Commodore Amiga, y además de la CPU 68000, también tiene procesadores separados llamados Agnus, Paula , y Denise chips) de los cuales tenemos la idea de que la GPU es algo separado (tampoco es realmente una mala idea).
Pero aquí está la idea básica, terrible y horrible que subyace a la agrupación: puede agregar un montón de PC y obtener una supercomputadora .
A primera vista, parece que es una gran idea. En la práctica, agrega un nodo al clúster, y su mejora no es 2X1 nodo, está más cerca de aproximadamente 1.2X1 nodo. Porque las interconexiones se volvieron aún más lentas .
Así que tomo una máquina de bus de 32Mhz y 32Mhz, que tiene una velocidad de transferencia máxima de aproximadamente 1Gbit / S, o 100MB / S, y puse esta CPU duplicada que realmente no puedo alimentar lo suficientemente rápido como para mantenerlo ocupado todo el tiempo, y luego lo conecto a otra máquina a 1/10 de esa velocidad 10Mbit / S ethernet.
Y esa es una supercomputadora … no realmente … es una supercomputadora. Mira cuántos FLOPS ( operaciones de punto flotante por segundo ) tengo cuando los sumas. Er … Siempre y cuando una operación no dependa del resultado de otra, quiero decir.
Y ahora los únicos problemas que estamos tratando de resolver no son solo aquellos en los que puede lanzar grandes cantidades de ciclos de CPU, en conjuntos de datos relativamente pequeños, son uno en el que las operaciones no dependen de operaciones anteriores.
El término técnico para esto es embarazosamente paralelo. Y aunque hay algunos problemas interesantes en este dominio, en realidad es un subconjunto de los problemas a los que nos gustaría poder lanzar ciclos de CPU, pero no podemos.
Pero … pero … ¡Dios mío, mon! Mira los FLOPS!
En otras palabras: ¡ limitamos aún más los tipos de problemas que incluso intentamos resolver!
Multinúcleo
Pero multinúcleo al rescate, ¿verdad? ¿Correcto?
Multinúcleo resuelve en gran medida muchos de los problemas de interconexión que no pudimos resolver en clustering (incluso con InfiniBand).
Comenzamos con dos CPU en un chip.
Factoid : De hecho, participé en el proyecto SMP de FreeBSD; Tenía la segunda máquina FreeBSD que ejecutaba SMP; el primero perteneció a Jeff Vogel, quien realizó el trabajo original en Sun Microsystems. Luego lo arrojó sobre la pared, con un archivo de encabezado omitido intencionalmente, para ver quién estaba realmente interesado en trabajar en él, en lugar de simplemente jugar. Todo el mundo, menos yo, no tenía ni idea de eso durante varios meses.
2 núcleos: eso sigue siendo bastante inútil; no tiene que ser bueno para escribir un sistema operativo paralelo en ese nivel, porque puede ejecutar el núcleo (principalmente) en uno o dos núcleos, y el otro (si queda) vive en el espacio de usuario ejecutando código.
La edad de oro del multinúcleo en realidad comenzó en 4 núcleos.
¡Finalmente, la barrera de interconexión desapareció! … Volvamos a preocuparnos por el ancho de banda del bus, ¡mientras sigo escribiendo un código vergonzosamente paralelo!
Smithers! ¡Libera los tamaños de caché!
Exxxxxxxccceeeelllllent!
Ahora podríamos operar en conjuntos de datos más grandes.
Pero aunque el ancho de banda del bus de memoria aumentó un poco, pero no tan rápido como el ancho de banda de interconexión.
También tuvimos el mismo problema que tuvimos la primera vez que comenzamos con los multiplicadores de reloj: mantener 24 núcleos en un solo dado alimentado. Y no pudimos acceder a los mismos elementos de datos al mismo tiempo, o obtuvimos un IPI para una invalidación de línea de caché (con paquetes discretos) o un aviso de derribo de TLB (para paquetes de caché L2 / L3 compartidos).
Aquí está mi impresión de un sistema de 16 núcleos:
Es bastante obvio que la CPU 14 obtuvo el mutex para algunos elementos de datos compartidos a los que todos también necesitan acceder, ¿verdad? ¿Y esa velocidad de reloj, en general, no está mejorando?
Tenemos técnicas para esto. Podemos usar coloración en caché. Podemos usar NUMA virtual. y así.
Pero todo se reduce a que, a medida que las personas de hardware construyen máquinas multinúcleo cada vez más grandes, las personas de software dividimos los recursos compartidos en trozos cada vez más pequeños para que no tengamos que compartirlos, y no hay contención.
De esa manera, cada caracol … er … CPU … puede progresar continuamente, en lugar de detenerse esperando algún recurso compartido.
El resultado es: volvemos a reforzar la idea de que está bien lanzar ciclos de CPU a nuestros problemas.
¿Tenemos un cálculo {A} que debe completarse antes de que otras 4 CPU puedan proceder con un cálculo {B [0], B [1], B [2], B [3]} en paralelo? Bueno, en lugar de pagar la contención, y la latencia, los costos asociados con muchos núcleos … no resolvamos {A} en una sola CPU, resuelva el mismo cálculo en las 4 CPU al mismo tiempo para que podamos hacer el {B} es de inmediato!
Puede ver a dónde lleva esto: dejamos de intentar resolver problemas de grandes conjuntos de datos; luego pasamos a resolver problemas de grandes conjuntos de datos, pero solo si eran vergonzosamente paralelos, y ahora estamos de vuelta donde comenzamos, repitiendo el ciclo .
En general: tengo que llamar a un aumento de enfoque en los ejes opuestos, alternativamente: una pérdida neta en el espacio del problema que tratamos de abordar.
Creo que esto nos hace ciegos al problema (en Pensamiento y resolución de problemas, Toru Sato nos informa que esto se llama una fijación ), y creo que aumentar el tamaño de este punto ciego con el tiempo generalmente es algo malo .
