Lo caro no es procesar, es mover
La promesa del cómputo paralelo es fácil de entender: si tienes mil núcleos y mil operaciones idénticas, repartes y terminas mil veces más rápido.
En la práctica no. Y las dos razones por las que no son bastante instructivas.
Problema uno: la memoria no se comparte gratis
Cada procesador no tiene acceso a la memoria global. Para que trabaje, hay que copiarle la información que necesita.
Y ahí está el detalle que rompe la intuición: esa copia puede tomar más tiempo que el procesamiento mismo.
Cuando las operaciones individuales son pequeñas —y en cómputo paralelo casi siempre lo son, porque de eso se trata— el costo de mover los datos hacia el núcleo y de traer el resultado de regreso puede dominar completamente. Terminas con mil núcleos ociosos esperando datos.
La técnica para lidiar con esto es no copiar todo a todos: darle a cada unidad exactamente la información que necesita, y nada más, y que devuelva sólo su resultado a la memoria principal. Suena obvio dicho así, y en la práctica es donde se va el trabajo de verdad. Yo no lo entendí bien hasta que me tocó pelearme con ello.
Problema dos: nadie sabe si los demás ya acabaron
Los procesos son independientes. Ésa es la ventaja y también el problema: ninguno tiene forma de saber si los otros terminaron.
El proceso principal tiene que esperar a todos antes de poder juntar las piezas y producir el resultado final. Y "todos" quiere decir todos: si novecientos noventa y nueve núcleos terminaron y uno se atoró, sigues esperando.
Eso significa que el tiempo total no lo determina el promedio. Lo determina el más lento.
Y aun así conviene
Con las dos penalizaciones encima, esperar a que mil núcleos terminen suele seguir siendo mucho menos tiempo que hacerlo tú solo, en serie, uno por uno. Por eso el método sirve.
Pero deja de ser una división simple. La ganancia real depende de la proporción entre cuánto cálculo hace cada unidad y cuántos datos hay que moverle. Cuando el cálculo es mucho y los datos son pocos, la ganancia es enorme. Cuando es al revés, puedes acabar más lento que si no hubieras paralelizado nada.
Por qué esto se me quedó
Porque es exactamente lo que pasa cuando repartes un trabajo entre personas.
El costo no está en que cada quien haga su parte. Está en explicarle a cada quien qué le toca —copiar la memoria— y en que el resultado no existe hasta que el último entrega. Dividir un proyecto entre cinco personas casi nunca lo hace cinco veces más rápido, y las dos razones son las mismas de arriba.
La lección práctica es la misma en los dos casos: reparte trabajos grandes con instrucciones pequeñas. Si tienes que explicar más de lo que la otra parte va a ejecutar, no repartas.
Este texto sale del episodio 006 del Podcast Algoritmos, sobre cómputo paralelo y GPUs.