OpenCl y las herramientas para ello. Reseñas e impresiones. - página 28
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
Dentro de un par de años, le recordaremos este hilo.
Personalmente para mí esta rama fue muy útil - incluso cuando el topicstarter comenzó a asustar a mi espíritu inmaduro horrores de la reducción de la precisión de los cálculos.
El modo de optimización en MT5 es muy lento cuando el algoritmo genético está activado. Hice un Asesor Experto en MT4 y lo probé y optimicé. El tiempo de optimización no supera los 5 minutos en el doble núcleo (por supuesto, MT4 sólo tiene un núcleo involucrado, pero otras tareas no interfieren, porque pueden ejecutarse en el segundo núcleo). He reescrito el mismo Asesor Experto para MT5. Lo he probado para optimizarlo. El tiempo de optimización es de más de una hora, casi 2 horas para ser exactos. ¿Cuál es la diferencia?
Ahora no hay ninguna diferencia.
Pues bien, MetaTrader 5 parece estar por delante incluso en las pruebas por precios de apertura: Comparación de la velocidad de las pruebas en MetaTrader 4 y MetaTrader 5
Como prometimos, hemos simplificado el modo de prueba de apertura de bares y lo hemos hecho más rápido.
Bueno, han pasado dos años.
La versión CUDA del EA está funcionando. En MT4. De momento, sólo está en modo de prueba. Hasta ahora no puedo conseguir la aceleración de los cálculos prometida por nVidia.
Aquí hay dos problemas:
1. La propia nVidia, que exagera la velocidad de rediseño de los programas, o NO prepara su documentación en absoluto, o cambia fundamentalmente algunos aspectos esenciales de la programación.
2. La paralelización de algoritmos en la GPU lleva mucho más tiempo del esperado. Cuando empecé a portar un programa de DLL a CUDA-DLL, basándome en mis más de 20 años de experiencia en el lenguaje Caelian, supuse que las promesas de nVidia debían dividirse por 3, y el tiempo de portación del algoritmo que citaban debía multiplicarse por, digamos, 3.
Pero resultó que la regla general es: todas las promesas de nVidia deben dividirse por DIEZ y el tiempo estimado de portar C a CUDA debe multiplicarse por 10.
Nota: si has comprendido los principios de funcionamiento de los aceleradores de la GPU, puedes trasladar el algoritmo de C a CUDA en TRES SEMANAS. Y puedes hacerlo directamente, sólo para comprobar la construcción. Es decir, su programa será ejecutado por SOLO UNO de los cientos o MILES de pequeños procesadores de la tarjeta de vídeo. Esto funciona unas 70 (setenta) veces más lento que en la CPU. Sí, lento, pero funciona.
Entonces podrá, con bastante más esfuerzo, empezar a paralizar su programa. Esto ya funciona 4-5 veces más lento, o sólo 2-3 veces más rápido que en el procesador central.
Y modificar tu ALGORITMO de forma global, para que se ejecute en pasiones, repito en pasiones, y no de forma secuencial como te enseñan en todas las universidades del mundo, es una tarea difícil.
Dejémoslo claro: es difícil, pero no inusual, paralelizar un algoritmo secuencial habitual mediante el principio de Multithreading. Es una cosa. De la misma manera, se obtiene una velocidad 5-10 veces mayor en la GPU. Pero convertir el algoritmo secuencial en un algoritmo de racimo (no tengo una palabra mejor en mi vocabulario), para cargar cientos y miles de procesadores de GPU y obtener el aumento de velocidad de 100 veces como promete nVidia - esto puede ser un problema.
Pero también tiene solución. Es sólo cuestión de tiempo.
Pero también está Crimea, Benderites y demás .....
3. MetaTrader-4 no tiene problemas al escribir una DLL para CUDA.
El problema es que los desarrolladores de software de nVidia (2500 personas) están radicalmente en desacuerdo con el modelo de multihilo utilizado en MetaTrader-4-5. Nvidia cambió fundamentalmente este modelo cuando pasó de CUDA 3.2 a 4.0+. Es más, si te pones a preguntarles por qué era así (como Metatrader-4 y otros cientos de programas multihilo) y ahora es así, lo único que oirás como respuesta es "fundamentalmente has entendido mal nuestro kAnstment".
Lo he oído en alguna parte antes.... recientemente.....
4. Es mucho más fácil traducir un algoritmo nuevo de C a CUDA que de C a OpenCL genérico directamente, por lo que recomiendo este camino. Más aún cuando se supone que hoy mismo nVidia presentará oficialmente CUDA-6 en el que, teóricamente, en las nuevas GPU de la serie Maxwell y bajo algunos sistemas operativos será posible reducir significativamente la cantidad de programación, debido a la unificación de la memoria y a la eliminación de las operaciones de reenvío entre la CPU y la GPU.
¿Y bien?
¿Y qué?
¿Nadie está interesado en absoluto?
Ni una sola pregunta o post en un año.
Pero es interesante para Nvidia: leyó mis quejas en este y otros foros, reunió a su consejo de artes, lo frotó de todas las maneras posibles, - y decidió que los comerciantes son personas también, y que el terminal de comercio es un programa también, e introdujo en la última versión de CUDA una clave especial para el compilador - para crear un programa altamente multihilo en CUDA.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
una cadena como
nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread
Desgraciadamente, ni siquiera el Xeon Phi despegó. Y está más cerca de la programación convencional.
Quien necesite potencia en los cálculos universales puede ahora obtenerla fácilmente sin necesidad de recurrir a sistemas multiprocesadores de uso general. El número de núcleos de los procesadores de Intel está creciendo muy rápido.
Por ejemplo, nuestros servidores tienen 40 núcleos cada uno, incluso tengo un ordenador en funcionamiento con 20 núcleos y memoria DDR4. Un servidor con 40 núcleos de Xeon a 3 Ghz supera sin lugar a dudas a un Xeon Phi de baja frecuencia con 56 o más núcleos sin tener que reescribir una sola línea de código.
Quien necesite potencia en los cálculos de propósito general puede ahora obtenerla fácilmente sin necesidad de recurrir a sistemas multiprocesadores de propósito general. El número de núcleos de los procesadores Intel está creciendo con bastante rapidez.
Por ejemplo, nuestros servidores tienen 40 núcleos cada uno, incluso tengo un ordenador en funcionamiento con 20 núcleos y memoria DDR4. Un servidor basado en Xeon con 40 núcleos a 3 Ghz supera sin lugar a dudas a un Xeon Phi de baja frecuencia con 56 o más núcleos, sin necesidad de reescribir una sola línea de código.
Te equivocas un poco (2 veces. Ambas). Básicamente, yo también lo pensaba, sobre todo cuando me metí en la programación de la GPU.
(1). La "potencia en cálculos universales" en una CPU anfitriona puede obtenerse fácilmente SÓLO para los algoritmos más simples. Ese es el punto de fricción para la mayoría de los programadores de OpenMP y GPU. Hay cientos de millones de tarjetas de vídeo CUDA vendidas, pero sólo unos 300 programas para ella. En el caso de las finanzas, sólo unos 7-8 (sin contar las colecciones de bibliotecas inútiles).
Consulta la lista completa en el sitio web de nVidia:
http://www.nvidia.com/object/gpu-applications.html?cFncE
(Nuestro primer EA acelerado por CUDA disponible en el mercado para el terminal de trading MT4 *no* existe todavía).
Esta lista no ha cambiado desde hace varios años.
¿Por qué? Pues bien, porque el complejo algoritmo adaptativo, que puede armarse fácilmente a partir de piezas en una CPU-host, resulta que no basta con programarlo, sino que se necesita BREAK. Y eso no es una tarea tan fácil debido a :
a). peculiaridades y limitaciones del modelo de GPU CUDA-OpenCL (los kernels de diferentes tamaños deben ejecutarse de forma secuencial).
b). cualquier transferencia de datos a través del bus PCI entre la GPU y el procesador anfitrión acabará con toda la ganancia de velocidad. Y en los algoritmos adaptativos complejos, no se puede prescindir de ellos.
(2). "no requiere reescribir ni una sola línea de código" también es sólo para algoritmos sencillos. La situación se agrava por el hecho de que OpenMP -como alternativa real a la GPU- funciona de forma misteriosa, es decir, a veces funciona y a veces produce basura. Es una ilusión que con sólo añadir una línea pragma en un lugar, el algoritmo se paralelizará inmediatamente así. Está lejos de serlo. En un algoritmo complejo se producen tales correlaciones inesperadas entre los datos y los hilos paralelos que no podemos hacer sin construir un gráfico.
La GPU es un asunto totalmente diferente. Hay más trabajo que hacer allí al principio, pero el programa SIEMPRE funciona correctamente, en términos de tiempo. Además, un programa reescrito para CUDA (incluso sin escribir los kernels) se traduce a OpenMP ACTIVAMENTE mediante una línea de pragma y ESTO sí funciona. No tiene ningún sentido traducirlo a OpenMP justo después - sería mucho más perspectivo y fiable añadir kernels para CUDA-OpenCL. Sorprendentemente, los kernels para las GPUs CUDA resultan ser cortos, claros y fiables.
Bueno, y en términos de velocidad y fiabilidad absolutas, la CPU anfitriona no tiene ninguna posibilidad contra la GPU.
=Los mercados financieros y el forex en particular son una versión MUY comprimida de enormes procesos en todo el mundo.
= Por esta razón, un agloritmo de predicción de precios no puede ser sencillo. Por lo tanto, tiene que ser adaptativo y, en sentido figurado, estadístico en la actualidad.
= Así que sin la simulación y la retroalimentación adaptativa en un algoritmo tan bueno no hay nada que hacer.
=Por lo tanto, si la CPU anfitriona puede seguir siendo útil para realizar pedidos (es decir, su velocidad sigue siendo suficiente), es casi imposible trabajar sin GPU para fines de prueba y optimización.
Has afirmado que me he equivocado dos veces y luego, bajo el pretexto de la prueba, has aportado una prueba completamente ajena.
Tengo razón en lo siguiente (que se dijo inmediatamente):
No he mencionado OpenMP en absoluto. Desde mi punto de vista, OpenMP es una "bala de plata para peleles". Si estás luchando por el rendimiento real, deshazte de las tonterías de OpenMP y escribe a mano código multihilo inicialmente correcto/nativo, perfílalo y llévalo al máximo.
Usted mismo ha demostrado que no hay suficiente software de computación en la GPU. La mayoría de los programas de la GPU son sólo los casos más simples, incluyendo los descifradores de contraseñas y los mineros tontos (los juegos no se discuten).
Mi opinión es que las CPU y la infraestructura subyacente están evolucionando con bastante rapidez y, de hecho, están superando a las GPU en cuanto a rendimiento en aplicaciones del mundo real. Hace tres o cuatro años se podía creer en el potencial de las GPU, pero ahora ha quedado claro.
Has afirmado que me he equivocado dos veces y luego, bajo el pretexto de la prueba, has aportado una prueba completamente ajena.
Tengo razón en lo siguiente (que se ha dicho inmediatamente):
No he mencionado OpenMP en absoluto. Desde mi punto de vista, OpenMP es una "bala de plata para peleles". Si estás luchando por el rendimiento real, abandona la tontería de OpenMP y escribe a mano código multihilo inicialmente correcto/nativo, perfílalo y llévalo al máximo.
Usted mismo ha demostrado que no hay suficiente software de computación en la GPU. La mayoría de los programas de la GPU son sólo los casos más sencillos, incluidos los descifradores de contraseñas y los mineros tontos (los juegos no deben ser discutidos).
Mi opinión es que las CPUs y la infraestructura subyacente están evolucionando lo suficientemente rápido como para superar a las GPUs en cuanto a rendimiento en aplicaciones del mundo real. Hace tres o cuatro años se podía creer en el potencial de las GPU, pero ahora ha quedado claro.
1. extrapolando el ritmo de crecimiento de los núcleos de la CPU-host, es poco probable que en los próximos años su número llegue a 3000 núcleos como HOY tiene una buena tarjeta de vídeo. Y cada núcleo de la tarjeta de vídeo funciona a unos 1GHz. Por tanto, sería imposible que un procesador anfitrión compitiera con la GPU. Pero eso es suponiendo que haya un buen programa que pueda no sólo y no sólo trabajar esos 3000 núcleos, sino también asumir todas las pegas de la arquitectura de hardware de la GPU actual. Y la velocidad de vídeo de la memoria GDDR5 en la tarjeta de vídeo media actual es de unos 150 GBytes/seg. Todos los tipos de memoria DDR4 (25 GB/seg) tienen todavía un largo camino por recorrer.
¿Cómo puede un procesador anfitrión competir con 40-60 núcleos, incluso a 4 GHz y 25 Gb/s de memoria?
2. Todo tipo de exóticos como Phi no tienen el apoyo necesario y la versatilidad como una tarjeta de vídeo. Por lo tanto, se han extinguido.
3. sobre la necesidad de programar directamente en multihilo - sí, estoy de acuerdo contigo, pero es una tarea ardua . Escribir un complejo algoritmo adaptativo NUEVO a la vez en versión multihilo es muy difícil. Y hay que trabajar por evolución, por así decirlo. Y además, no hace falta que te diga lo mal que maneja Windows el multihilo cuando se llena de verdad (hay todo tipo de retrasos). Por eso, incluso el sistema operativo ha ideado las llamadas fibras, hilos simplificados.
Conclusión: No hay nada más barato, prometedor y fiable que la GPU.