OpenCl y las herramientas para ello. Reseñas e impresiones. - página 6
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Sospecho que eso es lo que Mischek gritaba hace un mes.
Veo la aplicación de OpenCL en pruebas pesadas o en cálculos paralelos muy intensivos sobre la marcha.
Hasta ahora no lo necesito (todos los cálculos pesados están en mi init() del inductor), pero vale la pena mencionarlo.
Alexey, tengo el mismo problema: intento arrastrar algo a init, y luego a tiempo real :)
Mi cerebro se ha convertido en un lenguaje procedimental. La POO es deseable, pero no nativa.
Para los fanáticos de B4 que no visitan mql5.com : OpenCL: pruebas internas de implementación en MQL5
Gracias, yo personalmente no lo había visto. Sólo que no es tan sencillo.
Además, Rinat está confundiendo a la gente: OpenCL 1.0 puede funcionar bien con double float, es una "opción disponible públicamente" soportada por todos los fabricantes - PERO NO PARA TODOS LOS MAPAS ANTIGUOS.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
" Opción de doble precisión y media coma flotante
OpenCL 1.0 añade soporte para doble precisión y medio punto flotante como extensiones opcionales. El tipo de datos double debe confirmar el formato de almacenamiento de doble precisión IEEE-754.
Una aplicación que quiera utilizar double tendrá que incluir la directiva #pragma OPENCL EXTENSION cl_khr_fp64 : enable antes de declarar cualquier tipo de datos de doble precisión en el código del núcleo. Esto ampliará la lista de tipos de datos vectoriales y escalares incorporados para incluir los siguientes:.....".
Puede que funcione en el Probador de Estrategias pero no funcionará en el Asesor Experto de OpenCL 1.0 no porque, como dice Rinat, "no hay doble flotación allí" sino, como ya he mencionado, debido a la ausencia de hilos seguros en OpenCL 1.0 y el lío con los hilos en MT4-5.
OpenCL (y CUDA) es confuso en general. ¿Qué quieres? Al fin y al cabo, los ingenieros de hierro y radio se propusieron cambiar el concepto de programación. Tienen una mentalidad de hierro.
También habrá un problema con la llamada "SELECCIÓN DE PLATAFORMAS": el programa, es decir, MT o DLL o Expert Advisor, DEBE, simplemente DEBE elegir la plataforma (AMD, Nvidia, Intel), que pueden ser varias diferentes que ejecutarán el conector OpenCL, y luego seleccionar manualmente el DISPOSITIVO si su ordenador está ejecutando Multi-GPU. La autoselección de plataforma en OpenCL aún no existe. Rinat habla de "auto-selección del más poderoso" pero no sé cómo es. En el ejemplo que se muestra, no hay selección de plataforma ni de dispositivo (GPU, CPU).
Además, todavía no existe en el estándar la paralelización automática de tareas en varias GPUs o en GPU+CPU. Digámoslo así: en algunas versiones de sus controladores/SDK AMD solía introducir dicho autoaprovisionamiento pero tuvo algunos problemas y por el momento AMD ha desactivado esta función.
En resumen: desarrollar y habilitar programas OpenCL c/o MT4-5 requiere cierto esfuerzo manual y por lo tanto no funcionará automáticamente o "recompilando con opción". Lo cual, a su vez, está plagado de atascos en el funcionamiento real. Será un trabajo sutil y, lo que es importante, me permito repetirlo, desgraciadamente es la PROGRAMACIÓN ORIENTADA A LOS JUDÍOS, que está mal. La depuración de programas paralelos para CUDA u OpenCL resultó ser mucho más difícil de lo que los revolucionarios del hierro suponían. Nvidia incluso canceló su conferencia sobre CUDA de otoño de 2011, debido a los problemas con los controladores y a las numerosas quejas sobre el bloqueo de la depuración. Así pues, han añadido otras 1.000 nuevas funciones al último kit de herramientas, ¿y qué hacer con ellas si los programas más sencillos ni siquiera se ejecutan o lo hacen con interrupciones? Después de todo, ni siquiera han mencionado la mitad del mecanismo interno de OpenCL o CUDA en sus herramientas descriptivas.
La velocidad de la GPU (en GigaFLOPS) de una tarjeta de vídeo colgada debido a la compatibilidad del controlador o del software es cero.
Gracias, no lo he visto personalmente. Sólo que no es tan sencillo.
....Ese no es realmente el punto. Puedes escribir en estilo procesal en un cinco.
joo: ¡Y , me desanima este hecho, akhtung! - MQL4 llamando a la dll funciona más rápido que MQL5 llamando a la misma dll...
Esto es lo alarmante.
Podrían haber desarrollado un soporte nativo para OMP en MQL5. Sería fácil y barato para el codificador, y no hay necesidad de escribir ninguna dll.
Pero este enjambre de abejas en un lenguaje de programación de hierro incompleto... aún no me inspira exactamente. Bueno, sí, una aceleración de cien veces en algunos casos es genial, pero en términos de cultura de programación es un paso atrás.
Hay mucha confusión en OpenCL (y CUDA) en general. ¿Qué quieres? Al fin y al cabo, los ingenieros de hierro y radio se han propuesto cambiar el concepto de programación. Tienen una mentalidad de hierro.
También habrá un problema con la llamada "SELECCIÓN DE PLATAFORMAS": el programa, es decir, MT o expert DLL o EA, DEBE, simplemente DEBE elegir la plataforma (AMD, Nvidia, Intel), que pueden ser varias diferentes en su ordenador y en la que se ejecutará el conector OpenCL, y luego seleccionar manualmente DEVICE si su ordenador está ejecutando Multi-GPU. La auto-selección de plataforma en OpenCL aún no existe. Rinat habla de "auto-selección del más poderoso" pero no sé cómo es. En el ejemplo que se muestra, no hay selección de plataforma ni de dispositivo (GPU, CPU).
Además, todavía no existe una forma estándar de paralelizar automáticamente las tareas de OpenCL en varias GPUs o en GPU+CPU. Digámoslo así: en algunas versiones de sus drivers/SDK, AMD solía implementar dicha autoparalelización, pero hubo problemas y AMD la ha desactivado hasta ahora.
En resumen: desarrollar y habilitar programas OpenCL c/o MT4-5 requiere cierto esfuerzo manual y por lo tanto no funcionará automáticamente o "recompilando con opción". Lo cual, a su vez, está plagado de atascos en el funcionamiento real. Será un buen trabajo y, lo que es importante, me permito repetirlo, desgraciadamente es la PROGRAMACIÓN ORIENTADA A LOS JUDÍOS, que está mal. La depuración de programas paralelos para CUDA u OpenCL resultó ser mucho más difícil de lo que los revolucionarios del hierro suponían. Nvidia incluso canceló su conferencia sobre CUDA de otoño de 2011, debido a los problemas con los controladores y a las numerosas quejas sobre el bloqueo de la depuración. Así pues, han añadido otras 1.000 nuevas funciones al último kit de herramientas, ¿y qué hacer con ellas si los programas más sencillos ni siquiera se ejecutan o lo hacen con interrupciones? Después de todo, ni siquiera han mencionado la mitad del mecanismo interno de OpenCL o CUDA en sus herramientas descriptivas.
La velocidad de la GPU (en GigaFLOPS) de una tarjeta de vídeo colgada debido a la compatibilidad del controlador o del software es igual a cero.
Ese no es realmente el punto. También puedes escribir en estilo procedimental en el 5.
Pero esto es alarmante.
Podrían haber desarrollado un soporte nativo para OMP en MQL5. Es fácil y limpio, no hay que escribir ningún dll.
Pero este enjambre de abejas en un lenguaje de programación de hardware incompleto... ...no parece muy emocionante. Sí, multiplicar por cien la velocidad en algunos casos es genial, pero en términos de cultura de programación es un paso atrás.
También me he encontrado con hechos en los que mql4 funciona más rápido que MQL5. En la mayoría de los casos se manifiesta en operaciones matemáticas optimizadas por el programador.
Pero creo que este no es el problema principal - al usar OpenCL MQ tomaron un camino que corre paralelo al camino principal de la programación - tal vez hasta ahora esto requiera un paso atrás, pero en el futuro desarrollo de la tecnología informática veremos sistemas escalables integrados donde ya dependerá del código si se usa el procesamiento secuencial o paralelo.
Así que el camino es bastante correcto. Aunque hoy en día no hay tantos algoritmos que exijan la implementación de un enfoque paralelo, esto se debe más bien a que el pensamiento matemático no disponía de equipos para la implementación de cálculos paralelos y, por lo tanto, no había necesidad de crear tales algoritmos.
Alexey, solo piensa en un hecho, todos los descubrimientos matemáticos se hicieron hace 200-300 años, los últimos 100 años el pensamiento matemático solo estaba puliendo lo que hay. Sólo el descubrimiento del NS creó la demanda de cálculos paralelos. En los próximos 100 años veremos algoritmos sustancialmente paralelos. Y tú, entre otros, puedes inventar uno de ellos.
También he visto hechos en los que mql4 es más rápido que MQL5. Esto se ve más a menudo en las operaciones matriciales optimizadas por el programador.
Pero creo que este no es el principal problema - al entrar en OpenCL MQ ha tomado un camino que corre paralelo al camino principal de la programación; tal vez hasta ahora esto requiera un paso atrás, pero en el futuro desarrollo de la tecnología informática veremos sistemas escalables integrados donde ya dependerá del código si se utiliza el procesamiento secuencial o paralelo.
Así que el camino es bastante correcto. Aunque hoy en día no hay tantos algoritmos que exijan la implementación del enfoque paralelo, se debe más bien a que el pensamiento matemático no disponía de equipos para la implementación de cálculos paralelos y, por tanto, no había necesidad de crear dichos algoritmos.
Alexey, piensa solo en un hecho, todos los descubrimientos matemáticos se hicieron hace 200-300 años, los últimos 100 años el pensamiento matemático solo estaba puliendo lo que hay. Fue el descubrimiento de la NS lo que dio lugar a la demanda de cálculos paralelos. En los próximos 100 años veremos algoritmos sustancialmente paralelos. Y tú, entre otros, puedes inventar uno de ellos.
No, no estás del todo desesperado después de todo. :)
Hola.
MQ son buenos, no tuvieron miedo de lidiar con un dolor (para ellos) como la introducción de soporte para los cálculos de la GPU. El dolor, en primer lugar, está relacionado con el hecho de que la introducción de tecnologías fundamentalmente nuevas (cualquiera) reduce la fiabilidad y la tolerancia a los fallos de la plataforma en su conjunto al principio. Pero entienden perfectamente, que el futuro pertenece a la computación paralela y tarde o temprano tendrían que hacer algo en esta dirección (el primer paso ya se dio - la nube).
P.D. Hola Nikolai. ¿Por qué has desaparecido? - Escríbeme.
Esto no es un hecho ya que no lo es. El desarrollo cualitativo de las matemáticas nunca se ha interrumpido.
Y los cálculos paralelos no sólo son necesarios para la NS, sino que hay tareas más mundanas, como la codificación de vídeo o el renderizado.
Pero el vector general del movimiento MQ es ciertamente alentador.