"New Neural" es un proyecto de motor de red neuronal de código abierto para la plataforma MetaTrader 5. - página 71

 
joo:

Si consideramos el entrenamiento de las neuronas como un nivel micro (ciclos de procesamiento de matrices independientes en el AG, cálculo de neuronas individuales de una red, etc.) y un nivel macro (todo el FP), entonces no tenemos preguntas ni problemas con el primero - todo se ejecuta en paralelo y funcionará bien en la GPU.

Pero hay un problema con el nivel macro. En primer lugar, sospecho que no es posible debido a las limitaciones de la cantidad de información que maneja la GPU. Podríamos trabajar alrededor de eso, usando un probador regular y la nube (cada nivel macro será transferido a agentes separados, y allí será procesado en el nivel micro - si el anfitrión lo permite por supuesto). Pero no tenemos las herramientas para controlar el probador externamente para usar GA externos.

Así que tendremos que limitarnos a la aceleración a nivel micro. La aceleración también será muy decente, ya que las mallas y los propios AG abundan en cálculos independientes entre sí.

En cuanto a UGA en sí, aparte de mejorarlo para OpenCL, no tiene prácticamente nada que mejorar (quizás sólo algunos fragmentos de código pero no servirá de nada gracias a los que participaron en el hilo de discusión del algoritmo en el artículo). Sólo puede intentar seleccionar los ajustes de UGA específicamente para las redes de entrenamiento.


Las GPU modernas tienen 1 GB de RAM o más.

Difícilmente puedo imaginar una muestra de formación de mayor tamaño.

Estoy bien con el nivel macro - probado )

Sería razonable utilizar la siguiente arquitectura para el AG: el propio AG en la CPU, mientras que los cálculos pesados de FF en la GPU

 
su.humano:

¿Puedo tener un pequeño ejemplo para usar en MT5?


¿Un ejemplo de qué? ¿Un indicador de red neuronal, una estrategia de red neuronal, ...? ?
 
yu-sha:

Las GPU modernas tienen 1 GB de RAM o más

Difícilmente puedo imaginar una muestra de formación de mayor tamaño

Si no me equivoco, las tarjetas gráficas modernas tienen dos tipos de RAM: la compartida, que puede ser de varios GBytes y es bastante lenta, y la que tiene cada procesador individual de la GPU, rápida, pero con una cantidad pequeña de unos cientos de KB. Mi razonamiento fue que aquí es donde podría surgir el problema.

yu-sha:

No hay nada malo en el nivel macro - probado )

Pero, si tú lo dices, entonces te tomo la palabra y ahora estoy tranquilo. :)

yu-sha:

Para el AG es razonable utilizar la siguiente arquitectura: el propio AG en la CPU, y los cálculos pesados de FF en la GPU

Bueno, es una cuestión de técnica, como se dice. Podrías hacerlo así. Por lo que sé, OpenCL permite seleccionar en el código qué núcleos se van a utilizar para realizar los cálculos: en la CPU o en la GPU.

 
yu-sha:
¿Un ejemplo de qué? ¿Un indicador de red neuronal, una estrategia de red neuronal, ...? ?
¿Cómo configurar una arquitectura de red suelta (no totalmente conectada), dónde alimentar, dónde sacar, dónde están los pesos?
 
joo:

Si no me equivoco, las tarjetas gráficas modernas tienen dos tipos de memoria operativa: la memoria compartida, que puede ser de varios GBytes y que es bastante lenta, y la que tiene cada procesador individual de la GPU, rápida, pero una cantidad pequeña de unos cientos de KB. Pensé que aquí es donde podría surgir el problema.

El común "lento" es el análogo completo de DDR para la CPU (~0,75 - 1,00GHz - no muy lento)

Fast es la contrapartida de la caché de la CPU.

Las GPUs permiten gestionar esta memoria en el propio chip (caché), a diferencia de las CPUs (podría estar equivocado, pero por alguna razón no me he encontrado con esta cuestión).

Pero todo esto son cuestiones adicionales de optimización, se puede vivir sin ellas

 

su.humano:

yu-sha:
¿Un ejemplo de qué? Indicador de red neuronal, estrategia de red neuronal, ... ?
¿Cómo configurar una arquitectura de red suelta (no totalmente conectada), dónde alimentar, dónde sacar, dónde están los pesos?

Sí, sí, necesitamos un ejemplo de empuje y entonces lo resolveremos.

Un AG estándar y una nube ayudarían a paralelizar el cálculo del FF. Especialmente como Renat prometió:

De ninguna manera, el GA del probador está limitado a 64 bits de búsqueda, y para los pesos de entrenamiento se necesitan 16-64 bits para cada peso (depende de la precisión de la búsqueda), y los pesos pueden ser hasta..... algunos miles, y pueden ser decenas y cientos de miles. UGA puede manejar esto bastante bien, mientras que el probador no puede.

Así que, o bien hay que pedirle a MQ que actualice la GA (cosa que he hecho durante dos años sin éxito) o la UGA será mucho más lenta que en el cluster.

 
yu-sha:

Comúnmente "lento" - es el análogo de la CPU de DDR (~0,75 - 1,00GHz - no muy lento)

Rápida: es la contrapartida de la memoria caché de la CPU.

Las GPUs permiten gestionar esta memoria en el propio chip (caché), a diferencia de las CPUs (podría estar equivocado, pero por alguna razón no me he encontrado con esta cuestión).

Pero todo esto son cuestiones adicionales de optimización, y podemos vivir sin ellas

No es el punto, la memoria, y en la GPU será difícil de implementar los giros de la lógica de los objetos, tengo una idea bastante buena de cómo implementar el NS como una compleja interacción de los objetos dentro de los cuales hay funciones de cálculo de la GPU (esto es sobre el nivel micro), pero no puedo imaginar cómo este complejo código de objeto de los NS conjunto para deslizar la GPU como varios FF con diferentes conjuntos de pesos (nivel macro) ?

La pregunta es retórica, aunque si alguien la imagina no me importaría escucharla.

 

Tengo una idea curiosa:

¿Tal vez para pedir a la API deMQ que establezca tareas para el clúster?

para distribuir la tarea directamente desde MQL5, evitando el probador. Por supuesto, es una tarea complicada, hay que hacer muchas comprobaciones, pero es manejable.

Ya lo domino, pero tengo que trabajar un poco.

 
Urain:

Sí, sí, nos gustaría un ejemplo de empuje y luego lo resolveremos.

Ejemplo 1:

Declaración de tareas:

- necesitamos restablecer el algoritmo del indicador, cuyas fuentes no están disponibles (o es un indicador "redibujado" - por cierto, no es un mal maestro para NS), pero conocemos los valores en cada barra

- los valores del indicador están en el rango (-1;+1)

Entradas:

- sabemos (¿sospechamos?) que este indicador utiliza los últimos 10 precios de cierre


Ejemplo 2:

Planteamiento del problema:

- Necesitamos encontrar la estrategia de negociación de la red neuronal que mejor opere (maximizar el Beneficio/MaxDD) en un tramo de la historia

Datos de entrada:

- MACD normalizado (13,35), MACD (50,100), RSI(8), RSI(13)

Ejemplo 3:

Declaración de tareas:

- Para enseñar a una red neuronal una tabla de multiplicar

Datos de entrada:

- multiplicadores x,y en el rango (-1;+1)

Puedes proponer tu propio ejemplo y, si es posible, te mostraré la arquitectura de la red en XML.

 
yu-sha:

Puedes proponer tu propio ejemplo y, si es posible, puedo mostrarte la arquitectura de la red en XML

y lo más importante, el código fuente de cómo se creó esta arquitectura, cómo se genera el archivo XML.

Razón de la queja: