OpenCL: desafíos reales - página 6

[Roffild]

Mathemat: Todavía no lo he comprobado en el probador.

Entonces, ¿por qué has publicado tonterías sin comprobar?

Quizás soy el único que ha probado OpenCL en el probador después de todo... lo probé...

[Sceptic Philozoff]

Roffild:

Entonces, ¿por qué has publicado tonterías sin verificar?

Probablemente soy el único que ha utilizado OpenCL en el probador después de todo... lo probé...

No es una tontería, es una petición satisfecha.

Una vez más, escribe a servicedesk y justifica lo que quieres. Si no puedes justificarlo, es tu problema.

En el momento de escribir estos artículos, todavía no se había empezado a hablar en serio de la utilización de OpenCL en el probador. La solicitud se refiere precisamente a ese momento.

Eres tú quien debe encender tu cerebro porque 0,35300 ms se refiere a clEnqueue[Read/Write]Buffer() y no al acceso global a la memoria dentro del kernel.

Este comando no está presente en la implementación de OpenCL para MQL5. ¿De qué estás hablando?

[Vladimir Gomonov]

Roffild:

Vuelve a repasar mis mensajes.

El criterio principal: la ejecución del código MQL en el "estilo OpenCL" durante 1 tick debe superar el tiempo = Número_Buffers * 0,35300 ms

Para averiguar la velocidad del algoritmo en MQL con precisión a los microsegundos (1000 microsegundos = 1 milisegundo) tendrá que ejecutar varias veces en tester y Total_Time / Number_of_Ticks (mi post superior).

Si no fuera por el retardo del búfer, mi código pasaría la prueba en ~30 segundos, es decir, ~2 veces más rápido que el MQL "estilo OpenCL" (55 segundos) y ~11 veces más rápido que el código normal (320 segundos).

¿Qué otros criterios hay?

No te pido que vuelvas a leer todos mis mensajes del foro sobre OpnCL. :) Allí se describen y discuten todos los criterios básicos.

El criterio principal es la relación t_alg/t_mem, donde t_alg- tiempo optimizado de cálculo del algoritmo del núcleo y t_mem- tiempo de acceso a la memoria borrada (*). Cuanto más largo sea este criterio, mejores serán las perspectivas de aumento de velocidad mediante OpenCL. En otras palabras, cuanto más pesados sean los cálculos y menos transferencias de matriz hacia y desde el dispositivo, mejores serán las perspectivas.

(*) memoria remota = todo tipo de memoria "no de registro" (la memoria de registro es muy rápida), por ejemplo (1) la memoria global del dispositivo es mucho más lenta que la memoria de registro pero mucho más rápida que (2) la memoria externa al dispositivo (RAM de la CPU).

[Roffild]

Mathemat:

No se trata de una tontería, sino de una aplicación satisfecha.

Una vez más, escribe a servicedesk y justifica lo que quieres. Si no puedes justificarlo, es tu problema.

Una vez más: bug #865549 de 2013.10.17 23:17 y los desarrolladores están notificados, pero es poco probable que arreglen algo. Probablemente esta limitación alguien de ellos añadió a propósito para no suspender todo el procesador durante la optimización.

¡Pero los artículos no dicen ni una palabra al respecto!

Matemáticas:

Es hora de encender el cerebro porque 0,35300 ms se refiere a clEnqueue[Read/Write]Buffer() y no al acceso a la memoria global dentro del núcleo.

Este comando no está presente en la implementación de OpenCL para MQL5. ¿De qué estás hablando?

Eh... Y también estáis soltando artículos sobre OpenCL...

Para que lo sepas, clEnqueueReadBuffer = CLBufferRead y clEnqueueWriteBuffer = CLBufferWrite se llaman de forma sincrónica.

El aprendizaje comienza aquí

MetaDriver: El criterio principal es la relación t_alg/t_mem, donde t_alg es el tiempo de cálculo optimizado del algoritmo del núcleo y t_mem es el tiempo de acceso a la memoria eliminada (*). En otras palabras, cuanto más "pesados" sean los cálculos y menores sean las transferencias de matriz hacia y desde el dispositivo, mayor será el potencial de aceleración con OpenCL.

Este es un criterio de optimización de la ejecución únicamente. Antes de mis mensajes no había cifras aproximadas sobre la velocidad de transferencia de los propios búferes.

[Roffild]

Amigos, antes de seguir discutiendo, piensen en los tres posts que comienzan aquí y específicamente en

mql5: En este ejemplo concreto, la ventaja de utilizar OpenCL se ve consumida por la sobrecarga de la copia del búfer.

Porque tú te centras en la optimización del propio kernel mientras que mis posts tratan sobre los buffers.

[Sceptic Philozoff]

Roffild: Para que lo sepas: clEnqueueReadBuffer = CLBufferRead y clEnqueueWriteBuffer = CLBufferWrite y se llaman de forma sincrónica.

Hace tiempo que sé que la implementación de OpenCL para MQL5 no es más que una envoltura sobre la verdadera API. Por cierto, en mi segundo artículo escribí que faltaba la posibilidad de establecer el tamaño del grupo de trabajo. Hice una petición a servicedesk, y lo hicieron después de un tiempo.

También sé que CLBuffer[Lectura/Escritura] es similar a clEnqueue[Lectura/Escritura]Buffer, pero estas funciones no son idénticas en absoluto: tienen sintaxis diferentes.

Pero no entiendo por qué sigues hablando de funciones clEnqueueXXX que no están presentes en OpenCL para MQL5.

Intentaré entender lo que quieres.

Roffild:

Es hora de encender tu cerebro porque 0,35300 ms se refiere a clEnqueue[Read/Write]Buffer() y no al acceso a la memoria global dentro del kernel.

La segunda puede resolverse optimizando el propio núcleo, mientras que la primera es una limitación de hierro.

De acuerdo. ¿Contra quién tiene una queja? ¿El fabricante de la tarjeta gráfica?

[Roffild]

Mathemat: También sé que CLBuffer[Lectura/Escritura] es análogo a clEnqueue[Lectura/Escritura]Buffer pero estas funciones no son idénticas en absoluto: tienen sintaxis diferentes.

Pero no entiendo por qué sigues hablando de funciones clEnqueueXXX que no están presentes en OpenCL para MQL5.

No hay ninguna diferencia. Es probable que haya un envoltorio de este tipo:

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

Así que tampoco tienes que inventarte ninguna sintaxis. El hecho de que el tercer argumento = CL_TRUE ya ha sido confirmado.

Matemáticas:

La segunda puede resolverse optimizando el propio núcleo, mientras que la primera es una restricción de hierro y el cerebro no ayudará.

Bien. ¿Contra quién tiene una queja? ¿El fabricante de la tarjeta de vídeo?

¡La queja es para los redactores de los artículos que no hay datos prácticos sobre esta limitación tan importante! (No lo había, hasta que lo probé).

[Vladimir Gomonov]

Roffild:

La queja se dirige a los redactores del artículo, ¡que no hay datos prácticos sobre esta limitación tan importante! (No lo había, hasta que lo probé).

Y no leas más artículos, no te quejarás. ;)

--

¿Por qué te metes conmigo? ¿Cómo puedes citar datos desconocidos en un artículo? El retraso en la transferencia de datos a/desde un dispositivo es enorme y hay que tenerlo en cuenta... Las cifras concretas dependen del hardware específico. Bueno, lo has probado en ti mismo y bien por ti. A veces, la gente (yo incluido) establece un código de prueba para estimar las capacidades y limitaciones de los distintos equipos. Piden a otras personas que compartan los resultados, la gente suele hacerlo (hay que felicitarles por ello), al mismo tiempo todo el mundo puede ver las estadísticas y lo que funciona en qué combinaciones. Entonces, alguien vuelve a comprar el hardware o cambia los enfoques para escribir el código teniendo en cuenta los resultados. ¿Qué quieres? Bueno, escribe una queja a Sportlotto, tal vez eso haga que tu código funcione más rápido...

:)

[Roffild]

En realidad, ya he terminado todo en https://www.mql5.com/ru/forum/13715/page5#comment_646513, pero los propios autores de los artículos querían demostrar algo más.

No hay información específica y muy importante en sus artículos, por lo que no están terminados y describen tareas poco realistas.

Puede que no añada información a los artículos, pero es una tontería pretender que estas cifras concretas no signifiquen nada.

[Sceptic Philozoff]

No entiendo el significado oculto del guión/asesor que has publicado, Roffild. El código es, por decirlo suavemente, incomprensible.

- ¿Dónde está el pragma cl_khr_fp64? Se necesita cuando se calcula con doble en el núcleo.

- ¿Por qué hay este trozo de código en la función OnTick(), que se puede poner en la inicialización calculando una vez?

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
local_work_size[0] = global_work_size[0] / units;

- ¿Por qué el tamaño de la tarea global es igual a 240 bytes? Tendría que ser mucho más grande para obtener algún beneficio de OpenCL. Bueno, debería ser al menos un millón de veces más grande si se puede juzgar a ojo.

- ¿Por qué una tarea global debe dividirse por el número de unidades para obtener el tamaño de una local? Tanto la CPU como la GPU permiten dividir una tarea global en un número mucho mayor de subtareas. Y las unidades en su caso es sólo un número de motores SIMD.

Digamos que, por ejemplo, el número de unidades de mi tarjeta de vídeo es 28 (Radeon HD7950). Pero este número no divide exactamente 240. Significa que una parte importante de los cálculos puede ser no paralela.

El número de sombreadores que tengo es 1792. El tuyo es 1440. Este es el número aproximado en el que debería dividirse la tarea global, para cargar correctamente el mapa. Pero tendrá que calcular el tamaño correcto de la tarea global. (Y es mejor no dividir, sino multiplicar).

Y lo que cuenta su mapa todo este tiempo no está nada claro.

En resumen: ¿qué debe hacer su código?