Discusión sobre el artículo "OpenCL: De una programación simple a una más intuitiva" - página 2

 
denkir: Se podría añadir por ejemplo algún cálculo estadístico.

Ya lo voy a hacer, (lo más probable) será sólo la recopilación de estadísticas sobre una gran historia. Nada que ver con muves sin embargo. Odio los muves - tengo derecho a hacerlo :)

Sincronizar cotizaciones.

Esta es una tarea para CPU más que para GPU. No todas las tareas son adecuadas para GPU, ¿no? Es mejor elegir una que sea adecuada, porque para eso está la GPU.

Esto será un array bidimensional.

Supongo que en el futuro artículo será tridimensional. Al mismo tiempo, quedará claro cómo trabajar con el buffer de la GPU que muestra un array de cualquier dimensión.

 
Mathemat:

Ya va a hacer esto, (lo más probable) será sólo acerca de la recopilación de estadísticas sobre una gran historia....

Supongo que en un futuro artículo será tridimensional. Al mismo tiempo se pondrá de manifiesto cómo escribir una matriz de cualquier dimensionalidad en el búfer de la GPU y cómo trabajar con él.

¡genial! Esperemos...

 
denkir: Toma el histórico de cotizaciones de todos los instrumentos en el terminal. Digamos un minuto. Sincroniza las cotizaciones.

¿Es necesario sincronizarlas también?

P.D. He leído la ayuda, veo que es necesario.

 

He recalculado los resultados del artículo teniendo en cuenta la actualización del hardware.

Hace un año: CPU Intel Pentium G840 (2 núcleos a 2,8 GHz) + tarjeta de vídeo AMD HD4870.

Recientemente: CPU Intel Xeon E3-1230v2 (4 núcleos/8 hilos a 3,3 GHz; ligeramente por detrás del i7-3770) + tarjeta de vídeo AMD HD.6 870.

Los resultados de los cálculos en OpenCL se muestran en el gráfico (en horizontal, el número de optimizaciones aplicadas en el artículo):


El tiempo de cálculo se muestra verticalmente en segundos. El tiempo de ejecución del script "de un golpe en la CPU" (en un núcleo, sin OpenCL) varió en función de los cambios de algoritmo dentro de 95 más o menos 25 seg.

Como vemos, todo parece claro, pero aún no es muy evidente.

El outsider obvio es el G840 de doble núcleo. Bueno, era de esperar. Otras optimizaciones no cambiaron demasiado el tiempo de ejecución, que varió de 4 a 5,5 segundos. Nótese que incluso en este caso la aceleración de la ejecución de scripts alcanzó valores superiores a 20 veces.

En la competición entre dos tarjetas de vídeo de distintas generaciones -la antigua HD4870 y la más moderna HD6870- casi podemos considerar ganadora a la 6870. Excepto en la última fase de optimización, en la que el antiguo monstruo 4870 aún se llevó una victoria nominal (aunque se quedó rezagado casi todo el tiempo). Las razones, francamente hablando, no están claras: los shaders son más pequeños y su frecuencia también es menor, pero aun así ganó.

Supongamos que se trata de los caprichos del desarrollo de las generaciones de tarjetas de vídeo. O un error en mi algoritmo :)

Yo estaba francamente contento con Xeon, que consiguió ser mejor que la antigua 4870 en todas las optimizaciones, y luchó con la 6870 casi en igualdad de condiciones, y al final incluso consiguió ganarles a todos. No digo que siempre vaya a ser así en cualquier tarea. Pero la tarea era bastante difícil desde el punto de vista computacional; después de todo, ¡se trataba de la multiplicación de dos matrices de tamaño 2000 x 2000!

La conclusión es simple: si ya tienes una CPU decente como i7, y los cálculos OpenCL no son demasiado largos, entonces tal vez no necesites un calentador potente adicional (tarjeta de vídeo). Por otro lado, cargar la piedra al 100% durante decenas de segundos (durante cálculos largos) no es muy agradable, porque el ordenador "pierde capacidad de respuesta" durante este tiempo.

 

Hola a todos,

¿Pueden dar un ejemplo de cómo OpenCL puede acelerar el backtesting de un EA en modo EveryTick? Actualmente, me lleva 18 minutos ejecutar datos de 14 años en el modo EveryTick. Creo que muchos operadores estarán interesados si OpenCL puede reducir el tiempo de prueba en un 50%.

 

Gran artículo , yo no entendía cómo mover la transferencia de la fila desde dentro del bucle fuera de la velocidad de la memoria privada .

La misma operación de transferencia se produce de todos modos , tengo cero impacto en mi código, pero por supuesto cada caso difiere. (pero de nuevo 0 impacto después de añadir algo significa que algo se acelera pero no hay ganancia)

Esta parte en la fuente OpenCL :

      "  REALTYPE rowbuf[ COLSROWS ];                                               \r\n"
      "  for( int col = 0; col < COLSROWS; col ++ )                                 \r\n"
      "     rowbuf[ col ] = in1[ r * COLSROWS + col ];                              \r\n"

Donde se mueve fuera del bucle crunch

Gracias

 
Gracias por el artículo, ha sido un gran aprendizaje, deseando ponerlo en práctica