¿Venís de leer la intro, la parte 1 y la parte 2?
El tema
Desde hace años, tantos que ni es argumento de venta, tenemos computadoras multicore, esto es, que tienen varias CPUs. Pudo haber sido una novedad en desktop, pero en servidores hace rato que no lo es.
Esto puede ser de dos modos: que un mismo chip tenga varios cores o en una misma placa varios chips y estos a su vez varios cores.
Mi primera experiencia con multicore fue un mother dual Pentium 133, comprado en el Parque Los Andes de una pila de mothers de descarte que no estoy seguro de haberlo hecho arrancar.
Por que el mundo y sus acontecimientos a veces es muy pequeño, en esa misma época por canje en un trabajo me dieron el mismo mother con sus CPUs y su gigante gabinete y sus placas EISA y ese si funcionó. Ahi pude probar un trabajo práctico de threads (Taller I) mientras también lo hacia en mi Pentium 3 de 700 y en una macintosh (PPC unicore) todo con linux. Esta última muy complicado pues sólo la pude hacer arrancar con un Gentoo y en el medio del proceso de instalación compilé y probé, ya que luego de la instalación el bootloader no funcionaba, muy complicado...
Volviendo al tema, una fuerza que ha impulsado el mundo multicore es la dificultad creciente de aumentar la velocidad del reloj, al punto que se ha tendido incluso a bajar la velocidad para disminuir el consumo pero a la vez aumentado los cores para aumentar la capacidad de procesamiento.
Sin embargo, no importa cuantos cores tengas, el tiempo de una tarea no paralelizable depedende de la velocidad del reloj y sobre esto volveré en la parte de FPGA.
Dos maneras de ejecutar simultáneamente tareas es por medio de disparar programas a la vez (forks) o a un programa pedirle que ejecute una función en un hilo (thread) distinto.
 |
| Multicore |
Estas funciones o programas pueden tener propósitos distintos como tener en un core el procesamiento y en el otro la interacción con la interfaz gráfica o, como en el caso actual, hacer lo mismo con distintos sets de datos.
Algunas diferencias son que los forks se comunican mediante llamadas interprocesos, red, memoria compartida, archivos y los threads, como son parte de un mismo programa, por variables compartidas.
En este caso, como no hay comunicación, da lo mismo y de hecho la performance es la misma.
Se puede combinar con loop unroll y AVX2 y aumentar mucho el rendimiento.
 |
| Multicore + AVX2 |
En el caso del threads por 32 se trata de dos CPU de 16 cores no pude ejectuar el ejemplo con dedicación exclusiva así que el rendimiento deber ser superior. Además, me parece recordar que no tenía AVX2, debía tener AVX y aunque se puede aprovechar no debo haber tenido ganas de hacerlo.
Código
- https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v4_threads
- https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v4_threads_32cores
- https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v4_threads_avx2
- https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v5_fork
