Optimización en el Probador de Estrategias - página 16

Nuevo comentario
 
Renat:

En las últimas versiones hemos eliminado por completo los gastos generales del sistema en las ejecuciones de tareas, reduciéndolos de casi 2000 ms a cero.

Aquí están los resultados de la ejecución de una tarea de cálculo, que fue sugerida por joo:

Ajustes (las fechas están puestas a propósito para que no se utilice el historial del gráfico):

Parámetros a ejecutar:

Agentes utilizados (4 agentes locales):

Resultados de la optimización:

La optimización duró sólo 25 segundos y se realizaron 18.432 pases:

Volviendo a la antigua tarea de optimización del probador de estrategias comerciales.

Las mejoras del plan general para la construcción de la 425 dieron como resultado:

  • reducción de los gastos generales del sistema en la preparación de los pases
  • añadir un modo explícito de "cálculos matemáticos" a la selección del tipo de simulación que ha simplificado la configuración

De nuevo con el mismo hardware (4 agentes locales) y cachés limpios en la compilación 425: 

Tester	optimization passed in 0 minutes 07 seconds
Tester	genetic optimization finished on pass 19456 (of 100000020000001)
Tester	result cache was used 10124 times
Tester	genetics is over

En comparación conel problema original planteado(la sobrecarga era de 2 segundos por pasada), hemos resuelto con éxito el problema. La misma tarea comenzó a contar en 7 segundos en lugar de 25 segundos.

La base de la lucha contra los gastos generales del sistema era la realización de tareas por lotes. Ahora se ha medido la velocidad de ejecución de cada agente, y se ha entregado un lote de 1 a 64 tareas para su cálculo. Como resultado, el tiempo necesario para preparar las pruebas y obtener los resultados se reduce proporcionalmente. Los agentes rápidos reciben más tareas y tamaños de lote mayores que los lentos. Esto es especialmente beneficioso para las tareas de cálculo rápido, en las que el tiempo de cálculo útil es comparable al tiempo de preparación de las pruebas y de envío de los resultados.

El trabajo para optimizar el mantenimiento de los agentes aún no ha concluido. Para el trabajo eficiente de los agentes remotos en la red de la nube MQL5, la reducción de los costes de comunicación es la cuestión principal.

 

Ayuda a la comprensión

Los siguientes bloques de código funcionan bien en el terminal en una cuenta demo, pero cuando se prueban dan un mensaje deerror 4109.

if(!ChartGetDouble(0,CHART_PRICE_MAX,0,price_max))
 {
  printf(__FUNCTION__,": Не получены данные по максимальной цене. Ошибка: %g.",GetLastError());
 }

La misma situación ocurre con

if(!ChartGetDouble(0,CHART_PRICE_MIN,0,price_min))
 {
  printf(__FUNCTION__,": Не получены данные по минимальной цене. Ошибка: %g.",GetLastError());
 }
 
slyusar:

Ayuda a la comprensión

Los siguientes bloques de código funcionan bien en el terminal en una cuenta demo, pero cuando se prueban dan un mensaje deerror 4109.

La misma situación ocurre con

Los cuadros y los objetos gráficos no se modelan durante las pruebas, ya que reducen drásticamente la velocidad de las mismas.
 
Renat:
Los cuadros y los objetos gráficos no se modelan durante las pruebas, ya que esto reduce catastróficamente la velocidad de las mismas.
Ya veo, gracias. ¿Hay alguna forma de salir de esta situación?
 
Renat:
Los cuadros y los objetos gráficos no se modelan durante las pruebas, ya que esto reduce catastróficamente la velocidad de las mismas.
Realmente espero que este tipo de simulación sin gráficos sea sólo en modo sin "visualización".
 
sergeev:
Realmente espero que este tipo de modelado sin gráficos sea sólo en un modo sin "visualización".
Totalmente solidario, los gráficos son a veces muy necesarios...
 
Renat:

Volviendo a la vieja tarea de optimizar el probador de estrategias comerciales.

Las mejoras del plan general para la construcción de la 425 dieron como resultado:

  • reducción de los gastos generales del sistema en la preparación de los pases
  • adición del modo explícito "cálculos matemáticos" en la selección del tipo de simulación, que ha simplificado la configuración

Otro resultado en el mismo hardware (4 agentes locales) y cachés limpias en 425 build:

En comparación conel problema original planteado(la sobrecarga era de 2 segundos por pasada), hemos resuelto con éxito el problema. La misma tarea comenzó a contar en 7 segundos en lugar de 25 segundos.

La base de la lucha contra los gastos generales del sistema era la realización de tareas por lotes. Ahora se ha medido la velocidad de ejecución de cada agente, y se ha entregado un lote de 1 a 64 tareas para su cálculo. Como resultado, el tiempo necesario para preparar las pruebas y obtener los resultados se reduce proporcionalmente. Los agentes rápidos reciben más tareas y tamaños de lote mayores que los lentos. El efecto es especialmente grande para las tareas de cálculo rápido, en las que el tiempo de los cálculos útiles es comparable al de la preparación de la prueba y el envío de los resultados.

El trabajo para optimizar el mantenimiento de los agentes aún no ha terminado. Para el trabajo eficiente de los agentes remotos en la Red de Nube MQL5, la reducción del coste de proporcionar comunicación es la cuestión principal.

Un cambio muy serio para mejor, gracias.

¿Qué pasa con el límite de 64 parámetros? Es el único factor, al menos para mí, que frena el uso completo del optimizador. Ya quiero olvidarme de cualquier aspaviento y escribir para el mundo "real", para que el probador pueda ser optimizado sin ningún cambio en el código.

 
Nos ocuparemos de los parámetros después de ejecutar el visualizador de prueba.
 
joo:

Un cambio muy serio para mejorar - gracias.

¿Qué pasa con el límite de 64 parámetros? Es el único factor, al menos para mí, que limita el uso a gran escala del optimizador. Y cómo quiero olvidarme de todo ese jaleo y escribir para el código "real" de una vez para poder optimizarlo en el probador sin que haya cambios en el código.

Te apoyo.
Renat:
Nos ocuparemos de los parámetros después del inicio del visualizador de pruebas.
¡Gracias! Esperaremos.
 
Renat:

Volviendo al viejo problema de la optimización del probador de estrategias comerciales.

Los siguientes resultados en el mismo hardware (4 agentes locales) y cachés limpias en 425 build:

En comparación conel problema original planteado(la sobrecarga era de 2 segundos por pasada), hemos resuelto con éxito el problema. El mismo problema es ahora de 7 segundos en lugar de 25 segundos.

En la próxima compilación que se publicará hemos hecho un gran trabajo para optimizar el cálculo de masas de los problemas matemáticos. Los gastos generales del sistema se han reducido a cero.

Ahora la misma tarea en el mismo hardware (Intel Q9400, 4 núcleos locales) para ~18 000 cálculos tarda 1 segundo (la última vez fueron 7 segundos, mientras que antes tardaba 25 segundos):

2011.04.04 20:12:34    Tester    optimization passed in 0 minutes 01 seconds
2011.04.04 20:12:34    Tester    genetic optimization finished on pass 18432 (of 1000000002000000001)
2011.04.04 20:12:34    Tester    result cache was used 9718 times
2011.04.04 20:12:34    Tester    genetics is over


Para comparar puedo mostrar cuánto tiempo en el mismo hardware gasta la misma tarea matemática para calcular 4 millones de pases (reduciendo el paso a 0,005 el número total de cálculos se convirtió en 4 millones, lo que permite ejecutar el cálculo completo):



2011.04.04 20:10:34    Tester    optimization passed in 0 minutes 46 seconds
2011.04.04 20:10:34    Tester    optimization finished, total passes 4004001


En 46 segundos tiene lugar el cálculo completo de 4 millones de tareas, la ventana de resultados de optimización muestra las 4 millones de filas con resultados, toda la tabla se ordena instantáneamente en cualquier campo, el gráfico de optimización está representando con rapidez los 4 millones de valores, el gráfico 3D está dibujando una superficie 3D a partir de los mismos resultados y girándola en diferentes ángulos:

1...910111213141516171819
Nuevo comentario