Dudas cuda, SP, MP y warps

Re: Dudas cuda, SP, MP y warps

de Martin Pedemonte -
Número de respuestas: 0


Hola, disculpen pero por un error cuando cree el foro no quedé suscrito. Así que recién estoy viendo las preguntas por un mail que me mandó un estudiante del curso. Contesto las cosas que creo que quedaron pendiente (algunas ya fueron respondidas por Santiago Castro).

Para empezar quiero hacer una aclaración, es importante separar el modelo de ejecución de lo que realmente pasa en el hardware al momento de la ejeución. El fabricante explica el modelo de ejecución para que el código que se hace funcione siguiendo esas pautas, después hay cosas que en la práctica pueden funcionar un poco distintas a como nos las imaginamos por el modelo de ejecución.

1) Cada core ejecuta un hilo. No puede haber dos hilos ejecutando a la misma vez en un core.

2) Con respecto a "Como se relaciona todo con los conflictos de bancos en memoria compartida? Si los conflictos de bancos ocurren a nivel de half warp (16 hilos) está relacionado con que hallan 16 cores en un bloque de  MP?":

No está dicho expresamente y no creo que esté vinculado pero estamos "deduciendo". Creo que estos hechos no se vincular porque en las primeras arquitecturas CUDA (como la G80) había 8 cores por MP y el conflicto de banco ya era a nivel de half-warp, así que para mi no tienen ninguna vinculación ambos hechos. 

3) Por qué la divergencia se da a nivel de warp y no a nivel de half warp? Es un tema de como decidieron agrupar los hilos para una misma instrucción?

Básicamente porque el modelo lo establece así. Entiendo que te desorienta que habiendo 16 cores, por qué trabajar con 32 hilos en el warp y no hacer los warps de 16 hilos. El warp no ejecuta en un ciclo de reloj sólo, en ese caso está necesitando dos ciclos de reloj para poder ejecutar. Si volvés a mirar la arquitectura G80, tenía 8 cores por MP y también planificaba en base a warps de 32 hilos (necesitaba 4 ciclos de reloj para que los 32 hilos del warp pudieran completar la ejecución). ¿Cuál es el motivo? Es difícil saber, yo intuyo que tiene que ver con los accesos a memoria global, que la planificación se haga en base a 32 y el MP parta más chico le da más juego cuando hay hilos que se trancan esperando datos, pero es solamente una intuición. La realidad es que se planifica en base a 32 y eso es lo que tenemos que considerar al momento de programar. Si parte de otra forma, al no formar parte del modelo de programación, es un riesgo explotar esa característica, porque podría no estar soportada en otra arquitectura o en otra tarjeta.

Espero que haya quedado claro.

Saludos,

Martín