"New Neural" es un proyecto de motor de red neuronal de código abierto para la plataforma MetaTrader 5. - página 58
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
???
No importa.
Quiero desarrollar, escuchar diferentes opiniones y sacar conclusiones.
Quiero desarrollarme, quiero escuchar diferentes opiniones y conclusiones.
La GPU Cuda es una cosa poderosa. Tenía un código que se ejecutaba durante 2-3 horas en 16 Intel Tracks (CPU de 4 núcleos). Y con más de 300 núcleos CUDA recorrió la misma distancia en 10 minutos, lo cual es impresionante. Pero el desarrollo del código de Kuda era muy complicado: había que dividir manualmente todos los cálculos del código en hilos paralelos, optimizar la memoria (por desgracia, los núcleos de Kuda tienen poca memoria). Estaba fuera de mi alcance: un programador inteligente me ayudó. Sigo teniendo miedo de su código y sigo haciendo todos los cambios en mi código original (no paralelizado). He desarrollado una opinión: si el algoritmo es estable, puede ser optimizado y transferido a la GPU con ayuda de un programador competente - los programadores autodidactas como yo no pueden hacerlo. Si se empieza inmediatamente con el código de la GPU para un algoritmo bien entrenado, se tardará mucho tiempo en superarlo. Yo mismo siempre empiezo con un código sencillo pero no óptimo, que puedo entender yo mismo, y sólo después de obtener los resultados esperados, empiezo a optimizarlo. Soy un desastre, no un programador :)
La GPU Cuda es una cosa poderosa. Tenía un código que se ejecutaba durante 2-3 horas en 16 Intel Tracks (CPU de 4 núcleos). Y con más de 300 núcleos CUDA recorrió la misma distancia en 10 minutos, lo cual es impresionante. Pero el desarrollo del código de Kuda era muy complicado: había que dividir manualmente todos los cálculos del código en hilos paralelos, optimizar la memoria (por desgracia, los núcleos de Kuda tienen poca memoria). Estaba fuera de mi alcance: un programador inteligente me ayudó. Sigo teniendo miedo de su código y sigo haciendo todos los cambios en mi código original (no paralelizado). He desarrollado una opinión: si el algoritmo es estable, puede ser optimizado y transferido a la GPU con ayuda de un programador competente - los programadores autodidactas como yo no pueden hacerlo. Si se empieza inmediatamente con el código de la GPU para un algoritmo bien entrenado, se tardará mucho tiempo en superarlo. Siempre empiezo con un código sencillo, aunque no óptimo, que puedo entender yo mismo, y sólo después de obtener los resultados esperados empiezo a optimizarlo. Soy un desastre, no un programador :)
Por ello, nos gustaría contar con el asesoramiento de un especialista en el campo del GPU computing. yu-sha y JavaDev, ¡ay!
Me interesan las siguientes preguntas:
1. ¿Qué aspectos deberían examinarse en primer lugar a la hora de hacer que un proyecto (o sus módulos independientes) se computen en la GPU, lo que evitaría el molesto rediseño en el futuro?
2. ¿Cuáles son los límites de memoria para los núcleos de la GPU? ¿Es posible poner todo el código de ejecución en memoria (decenas y cientos de miles de barras)?
Hasta aquí tales, preguntas generales. Más adelante vendrán otros más detallados, supongo.
Por ello, nos gustaría contar con el asesoramiento de un experto en GPU computing. yu-sha y JavaDev, ¡ay!
Está interesado en las siguientes preguntas:
1. ¿A qué aspectos hay que prestar atención en primer lugar al crear un proyecto (o sus módulos individuales) en la GPU para evitar el molesto rediseño en el futuro?
2. ¿Cuáles son los límites de memoria para los núcleos de la GPU? ¿Es posible poner todo el código de ejecución en memoria (decenas y cientos de miles de barras)?
Hasta aquí tales, preguntas generales. Más adelante vendrán otros más detallados, supongo.
¿Por qué molestarse con un cuda en un proyecto destinado al uso general? Algunos usuarios tienen un cuda, otros tienen otro, y otros no tienen ningún cuda. Por ejemplo yo no tengo cuda en mi portátil del trabajo. El mismo código de red será muy diferente dependiendo del número de núcleos del cuda y de la memoria. Mejor al principio escribir este motor de red para el procesador Intel normal para que todo el mundo sea capaz de utilizar, y luego optimizarlo para kuda si tiene sentido. Por cierto, es mejor crear el motor de manera que funcione en la nube. No estoy familiarizado con la computación en nube. ¿Hay algún lugar ahí dentro?
¿Por qué molestarse con un cuda en un proyecto destinado al uso general? Algunos usuarios tienen un cuda, otros tienen otro, y otros no tienen ningún cuda. Por ejemplo yo no tengo cuda en mi portátil del trabajo. El mismo código de red será muy diferente dependiendo del número de núcleos del cuda y de la memoria. Mejor al principio escribir este motor de red para el procesador Intel normal para que todo el mundo sea capaz de utilizar, y luego optimizarlo para kuda si tiene sentido. Por cierto, es mejor crear el motor de manera que funcione en la nube. No estoy familiarizado con la computación en nube. ¿Hay algún lugar en absoluto?
MQ ha prometido soporte para OpenCL en MQL5, no para CUDA (sólo tarjetas gráficas de nVidia). OpenCL puede ejecutarse en cualquier hardware que tenga procesadores multinúcleo, esto incluye tanto CPUs como GPUs (AMD y nVidia e intel). Por lo tanto, un proyecto que soporte los cálculos tanto en la CPU como en la GPU funcionará para todos.
Dado que MQL5 soportará OpenCL, significa que los agentes de la nube soportarán la computación en la GPU.
Urain:
No se puede tener siempre la razón, para eso está el proyecto Open Source, para discutir, para probar.
Por ello, nos gustaría contar con el asesoramiento de un experto en GPU computing. yu-sha y JavaDev, ¡ay!
Está interesado en las siguientes preguntas:
1. ¿A qué aspectos hay que prestar atención en primer lugar al crear un proyecto (o sus módulos individuales) en la GPU para evitar el molesto rediseño en el futuro?
2. ¿Cuáles son los límites de memoria para los núcleos de la GPU? ¿Es posible, en principio, colocar todo el código ejecutable en un historial separado que se ejecuta en la memoria (decenas y cientos de miles de barras)?
Hasta aquí las preguntas generales. Supongo que más adelante se añadirán otros más detallados.
Los puntos principales son:
1) Las GPU sólo son necesarias para la formación
2) Se consigue un aumento significativo del rendimiento mediante el cálculo paralelo de los valores de las neuronas en una capa y, lo que es más importante, ejecutando cientos de redes simultáneamente
Desglose máximo del proyecto en componentes autónomos: esto es lo que hay que tener en cuenta
La memoria DDR de la GPU es más que suficiente para almacenar el historial de cientos de miles de barras
La memoria del núcleo está muy limitada (30-50Kbytes). La programación directa también resuelve este problema, ya que la memoria del chip funciona a la frecuencia del núcleo y acceder a ella cuesta 0 ciclos de reloj. También hay conflictos en el banco de memoria del kernel, también lo sortean.
Hay una característica desagradable de Windows: los controladores se reinician si una ejecución dura >~ 5 segundos
Por lo tanto, lo máximo que podemos conseguir es el entrenamiento de 100-200 redes de ~100 neuronas para 100k barras de historia
Con esta configuración (máxima) obtenemos una velocidad de optimización de ~ 20-30 ejecuciones por segundo en la GPU GTX 460