OpenCL: ¿Por qué el rendimiento difiere mucho entre estos dos casos?

Question

Aquí hay dos pedazos de código de un kernel de OpenCL en el que estoy trabajando; muestran tiempos de ejecución muy diferentes.

El código es bastante complicado, por lo que lo he simplificado.

Esta versión se ejecuta en menos de un segundo:

for (int ii=0; ii<someNumber;ii++) 
{ 
    for (int jj=0; ii<someNumber2;jj++) 
    { 
     value1 = value2 + value3; 
     value1 = value1 * someFunction(a,b,c); 
     double nothing = value1; 
    } 
} 

y esta versión toma alrededor de 38 segundos para ejecutar:

for (int ii=0; ii<someNumber;ii++) 
{ 
    for (int jj=0; ii<someNumber2;jj++) 
    { 
     value1 = value2 + value3; 
     value1 = value1 * someFunction(a,b,c); 
    } 
    double nothing = value1; 
} 

Como digo, el código es algo más complicado que esto (hay muchas otras cosas sucediendo en los bucles), pero la variable "nada" realmente se mueve desde inmediatamente antes hasta inmediatamente después del corsé.

Soy nuevo en OpenCL, y no puedo entender qué está pasando, y mucho menos cómo solucionarlo. Huelga decir que el caso lento es realmente lo que necesito en mi implementación. He intentado meterme con los espacios de direcciones (todas las variables aquí están en __private).

Solo puedo imaginar que, por alguna razón, la GPU está presionando la variable "value1" en la memoria más lenta cuando se cierra la abrazadera. ¿Es esta una explicación probable? ¿Que puedo hacer?

¡Gracias de antemano!

ACTUALIZACIÓN: Esto se ejecuta en menos de un segundo también: (pero sin comentario en ninguna de las líneas, vuelve a la lentitud extrema). Esto es sin realizar ningún otro cambio en los bucles, y el valor 1 todavía se declara en el mismo lugar que antes.

for (int ii=0; ii<someNumber;ii++) 
{ 
    for (int jj=0; ii<someNumber2;jj++) 
    { 
//  value1 = value2 + value3; 
//  value1 = value1 * someFunction(a,b,c); 
    } 
    double nothing = value1; 
} 

ACTUALIZACIÓN 2: El código fue realmente anidado en otro bucle de este tipo, con la declaración de value1 como se muestra:

double value1=0; 
for (int kk=0; kk<someNumber3;kk++) 
{ 
    for (int ii=0; ii<someNumber;ii++) 
    { 
     for (int jj=0; ii<someNumber2;jj++) 
     { 
      value1 = value2 + value3; 
      value1 = value1 * someFunction(a,b,c); 
     } 
     double nothing = value1; 
    } 
} 

en movimiento, donde value1 se declara también nos lleva de nuevo a la caja rápida:

for (int kk=0; kk<someNumber3;kk++) 
{ 
    double value1=0; 
    for (int ii=0; ii<someNumber;ii++) 
    { 
     for (int jj=0; ii<someNumber2;jj++) 
     { 
      value1 = value2 + value3; 
      value1 = value1 * someFunction(a,b,c); 
     } 
     double nothing = value1; 
    } 
} 

parece OpenCL es un arte muy difícil! Todavía no entiendo realmente lo que está pasando, pero al menos sé cómo solucionarlo ahora.

Answer 1

¿Qué implementación está utilizando? Yo esperaría el "doble nada = valor1"; para ser eliminado como código muerto en cualquiera de los casos por cualquier compilador razonable.

Answer 2

El primer caso es solo un bucle (con optimizaciones del compilador) Pero el segundo es un bucle con un bucle anidado. Ese es el gran problema. Muchas comprobaciones de las variables globales/locales. (¿Seguro que son privadas? ¿Has declarado todo eso dentro del kernel?)

Te recomiendo que lo guardes como variable privada (somenumber y somenumber2) antes de iniciar el ciclo. Porque de esa manera estarás revisando cada vez con datos privados. Como experiencia personal, cada var utilizada como el caso de verificación de un bucle OpenCL debe ser privada. Esto puede ahorrar hasta 80% de acceso a la memoria global. (Especialmente si el bucle es muy corto o simple)

Como ejemplo, este debe trabajar rápido:

int c_somenumber = someNumber; 
for (int ii=0; ii<c_someNumber;ii++) 
{ 
    int c_somenumber2 = someNumber2;  
    for (int jj=0; ii<c_someNumber2;jj++) 
    { 
     value1 = value2 + value3; 
     value1 = value1 * someFunction(a,b,c); 
    } 
    double nothing = value1; 
} 

EDIT: Además, valor1 debe almacenar en caché en la memoria privada.(Como lo hizo en su última edición)