[C con Clase] vectorizar matrices & Threads

[gdotta]

Hola Alejandro:

Entiendo que, en una programación multithread en un PC multiprocesador o
multinúcleo, el acceso a cada elemento de la matriz (que supongo que va
a estar  en la RAM del propio PC) implica un cálculo que involucra una
de las dimensiones de la matriz, la posición inicial de la misma y las
coordenadas del elemento. Estos datos, habiéndola definido como float
matriz[10][10] son constantes que cada thread va acabar teniendo en los
registros del procesador o en la caché local de cada núcleo. Por tanto,
los accesos de los distintos threads no se van a estorbar. Sí que hay un
cuello de botella y es el propio de la memoria, pero eso no se soluciona
ni con threading ni con multinúcleo o multiprocesador y tampoco
separando la matriz en trozos independientes. Lo que sí ayuda, pero
dependiendo de cómo sean los accesos que requieren los algoritmos, es la
caché de cada procesador o núcleo. 
Si distintos threads no acceden al mismo elemento, no hace falta poner
semáforos, o mutex o similares. Sólo evitar compartir variables entre
threads.
La velocidad obtenida será algo inferior a (vel. con un hilo)/(num de
threads), siempre que el número de threads no sea mayor que el número de
núcleos o procesadores. 

Por si interesa, se puede tener un gran aumento de la velocidad (3X a
8X) empleando las instrucciones SSE y similares de los procesadores
Intel (AMD tiene también las suyas propias). Éstas tratan grupos de
datos a la vez en bloques de 128bits. Como esta programación es
farragosa, es posible usar las librerías IPP de Intel (Integrated
Performance Primitives) que simplifican el trabajo (pero no son
triviales). Se pueden usar también con multithreading por lo que la
velocidad se multiplica.

un saludo,
Yan.

NOTA PARA LOS ADMINISTRADORES: No puedo ver este hilo en la página web
de la lista de correo.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.conclase.net/pipermail/cconclase_listas.conclase.net/attachments/20090225/a50cdb50/attachment.html>