OpenCL: pruebas de implementación interna en MQL5 - página 33

 
Mathemat:

Andrew, ¿es, por ejemplo, Intel + Radeon algo malo?

No está mal, pero es excesivamente caro (por el procesador). :)

Por cierto, soy un viejo fan de las tarjetas nVidia. Incluso tengo una caja en algún lugar con la legendaria GeForce 3. Y si quisiera jugar no dudaría en quedarme con el fabricante de chips gráficos "verdes".

 
Captura el puesto en un mensaje privado aquí. No quiero traerlo aquí.
 
MetaDriver:
Hablando en serio, tengo muchísima curiosidad por saber qué jugos podrá exprimir, sobre todo si tiene 2 Giga DDR5. Resulta que la memoria de la GPU integrada puede ser un recurso MUY serio para el cálculo de OpenCL.

De toda la información de la que dispongo he llegado a la conclusión de que el principal recurso es el número de núcleos de la GPU, si no hay suficientes el problema se divide en tiradas consecutivas de núcleos con nuevos hilos pero es difícil ahorrar en este recurso a la hora de comprar la tarjeta ya que a más núcleos mayor es el precio.

La segunda más importante es la velocidad a la que funciona la memoria de la GPU (ya que se accede a la memoria con bastante frecuencia). Las tareas de la GPU en la mayoría de los casos son bastante primitivas y utilizan 1-2-3 operaciones antes de acceder a la memoria para mostrar los resultados. Cualquier operación lógica compleja está contraindicada para la GPU, por lo que los programadores se esforzarían en minimizarlas, lo que lógicamente se traduciría en accesos más frecuentes a la memoria. Aquí hay variantes, si la tarea es descrita por el programador de tal manera que los accesos a la memoria sean los mínimos posibles, entonces este recurso no es tan importante.

Y el tercer recurso, lo llamaría la cantidad de memoria de la GPU. Las pruebas de choque han demostrado que, independientemente del número de contextos concurrentes, toda la memoria distribuida en los contextos se asigna en un solo campo de memoria y no se solapa. Me explico con un ejemplo: si tienes N contextos en cada uno de los cuales los buffers se asignan en 1/4 de la memoria del dispositivo, entonces puedes tener 4 de estos contextos al mismo tiempo. El quinto contexto, aunque lo cree, no se le asignará memoria porque ya está distribuida por los contextos anteriores. Pero si se libera memoria en cualquiera de los anteriores (simplemente eliminando el buffer) quedará espacio libre y el quinto contexto funcionará bien.

Renat:

Todavía es pronto: tenemos que asegurarnos de que los programas OpenCL no cuelguen toda la red debido a fallos de la GPU y de los propios programas OpenCL.

De hecho, los programas OpenCL sólo se pueden poner en la red después de realizar pruebas en agentes locales para asegurarse de que el programa es funcional y no mata el ordenador.

La tarea de una red de computación paralela distribuida. El nombre en sí mismo puede confundir a un lector inexperto. Si tenía problemas para organizar una red distribuida en máquinas multinúcleo, ahora los tendrá resueltos. Todos los núcleos podrían considerarse unidades de red independientes porque realizan tareas separadas. Pero antes su velocidad de ejecución difería a lo sumo 2-3 veces (para lo cual se han introducido límites de velocidad para los núcleos lentos), la cantidad de memoria en la mayoría de los casos no jugaba un papel, ya que las matrices tienen 10^7 elementos como máximo (para las máquinas modernas es de centavos).

Pero con la GPU el problema cambia radicalmente. En primer lugar, sólo ~12 matrices dobles con una longitud de 10^7 son ya 1Gb, lo cual es un límite para muchas tarjetas. En los cálculos de la CPU las tareas con más búferes son bastante comunes (aunque, por supuesto, el programador de la GPU puede registrar utilizando la memoria del host, pero es similar a la RAM virtual, en definitiva es un mal).

En segundo lugar, la diferencia de velocidad de ejecución es linealmente proporcional al número de núcleos de una GPU. La diferencia entre las dos tarjetas es de 10 a 1000 veces.

En general, la tarea de conexión en red se reduce a la clasificación del programa a ejecutar. Presta atención al perfilador CUDA. Sus estadísticas pueden servir de base para la clasificación de las tareas. Si la tarea está diseñada para que la mayor parte del tiempo se dedique al acceso a la memoria, requiere un clúster de máquinas con grandes tamaños de memoria, pero si la mayor parte del tiempo se dedica a la aritmética, necesitamos un clúster con un gran número de núcleos. Las agrupaciones pueden ser flexibles o incluibles (es una cuestión de ejecución).

Aunque la tarea se simplifica un poco por la unificación que aplica el propio tiempo. Una tarjeta con 12 núcleos es probable que tenga 256MB, una tarjeta con 96 tiene 512MB. Por término medio, los fabricantes no permiten grandes oscilaciones (a diferencia de lo que ocurre con la CPU, donde el usuario puede pegar su vieja roca con RAM hasta las trancas, o poner un mínimo de RAM en la nueva roca, sólo para ahorrar dinero al comprar).

Aunque, en mi opinión, un enfoque más correcto sería crear un depurador para OpenCL y sobre su base defender la optimización para el dispositivo en bytecode. De lo contrario, llegaríamos al ensamblador cuando el programador tendría que adivinar en qué tarjeta se ejecutaría el programa y las características medias del mismo para un posible entorno.

 
MetaDriver:

Dígame, si no le importa, ¿cómo se hace la prueba? ¿Dónde, qué cambiar? Copia, selección, resultado:

Win7 x64 build 607

 
WChas:

Este ejemplo no necesita ser "ejecutado" en el probador. Para ejecutar el script, arrástrelo y suéltelo desde el "Navegador" al gráfico. El resultado se mostrará en el panel " Herramientas", pestaña " Expertos".

 

w7 32 bit 4GB ( 3.5GB disponibles)

Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) vs Radeon HD 5770

 
Snaf:

w7 32 bit 4GB ( 3.5GB disponibles)

Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) vs Radeon HD 5770

Genial, ahora ya sabes dónde buscar... :)
 
MetaDriver:
Genial, ahora ya sabes dónde cavar... :)

los procesadores ya llevan 2-3 generaciones de retraso

y vídeo 5770 - 6770 -7770

:)

 
Urain:

A partir de la información disponible llegué a la conclusión de que el principal recurso es el número de núcleos de la GPU, en caso de carecer de ellos el problema se soluciona con ejecuciones consecutivas de núcleos con nuevos hilos, pero es difícil ahorrar en este recurso a la hora de comprar una tarjeta ya que cuantos más núcleos mayor es el precio.

La segunda más importante es la velocidad a la que funciona la memoria de la GPU (ya que se accede a la memoria con bastante frecuencia). Las tareas de la GPU en la mayoría de los casos son bastante primitivas y utilizan 1-2-3 operaciones antes de acceder a la memoria para mostrar los resultados. Cualquier operación lógica compleja está contraindicada para la GPU, por lo que los programadores se esforzarían en minimizarlas, lo que lógicamente se traduciría en accesos más frecuentes a la memoria. Aquí hay variantes, si la tarea es descrita por el programador de tal manera que los accesos a la memoria sean los mínimos posibles, entonces este recurso no es tan importante.

Y el tercer recurso, lo llamaría la cantidad de memoria de la GPU. Las pruebas de choque han demostrado que, independientemente del número de contextos concurrentes, toda la memoria distribuida en los contextos se asigna en un solo campo de memoria y no se solapa. Me explico con un ejemplo: si tienes N contextos en cada uno de los cuales se asignan buffers en 1/4 de la memoria del dispositivo, entonces puedes tener 4 de esos contextos al mismo tiempo. El quinto contexto, aunque lo cree, no se le asignará memoria porque ya está distribuida por los contextos anteriores. Aunque liberando memoria en algunos de los anteriores (simplemente eliminando buffer) aparecerá algo de espacio y el quinto contexto funcionará bien.

Nikolai, estoy de acuerdo contigo sobre la jerarquía individual de valores. Pero en lo que respecta a la nube... el problema está en la memoria. Si los dos primeros recursos no son suficientes en la máquina de la nube, el programa cliente simplemente se ralentizará. Si hay una falta de memoria de la GPU, puede simplemente bloquearse. Es decir, si el conductor no distribuye el búfer, eso es la mitad del problema. Es una desgracia si realmente hay suficiente memoria, pero no queda suficiente para el resto de los contextos de la GPU (incluyendo los del sistema). Entonces el conductor simplemente revienta (como ha demostrado la práctica). Tal vez, esto es sólo un defecto en el software del controlador, pero mientras exista, sería mejor no dejar que los programas OpenCL en la nube. Los agentes remotos pueden, pero la nube no debe.
 

después de actualizar a la build 607 de repente tengo opencltest trabajando en mi portátilhttps://www.mql5.com/ru/code/825, antes no funcionaba (hace unas dos semanas), creo que decía "OpenCL no encontrado"

"Me huele a truco", aún no he jugado con los fractales de Mandelbrot ))))))))))))) pero sigue siendo agradable que no un nuevo ordenador portátil puede ser útil para la prueba completa de MT5

OpenCL Test
OpenCL Test
  • votos: 10
  • 2012.02.07
  • MetaQuotes Software
  • www.mql5.com
Небольшой рабочий пример расчета фрактала Мандельброта в OpenCL, который кардинально ускоряет расчеты по сравнению с софтверной реализацией примерно в 100 раз.