Librerías: TesterBenchmark - página 3

Nuevo comentario
 
Andrey Khatimlianskii:

Vasily, ¿estás hablando en serio de la conmensurabilidad de la velocidad de ejecución de OrderSend en tester y en real?

Online es la más lenta, porque envía información al servidor y espera una respuesta, mientras que en el tester (si no incluyes el retardo, pero no venía a cuento), el envío y la espera suceden instantáneamente.

La tarea de esta biblioteca es sólo para medir la velocidad del probador (en términos de funciones de comercio).

Sí, no pensé en ello. Mi error. Específicamente OrderSend funciona mucho más rápido en el probador. Pero sigo diciendo que la mayor parte del tiempo de prueba se lo comen las funciones del sistema. Y en MT5 se lo comen muy bien, porque allí, a diferencia de MT4, hay una simulación completa del entorno de trading. Por eso, aunque el pipelining se acelere un 16%, será un 16% de un 5% del tiempo total que se lleva ese mismo pipelining. Es decir, cualquier idea de optimización de código en MT5 es muy noble, pero inútil, porque como mucho mejoraremos el índice en ese 5%.

 
Vasiliy Sokolov:

Sí, no estaba pensando. Error mío. OrderSend funciona mucho más rápido en el probador. Pero sigo diciendo que la mayor parte del tiempo de pruebas se lo comen las funciones del sistema. Y en MT5 se lo comen muy bien, porque allí, a diferencia de MT4, hay una simulación completa del entorno de trading. Por eso, aunque el pipelining se acelere un 16%, será un 16% de un 5% del tiempo total que se lleva ese mismo pipelining. Es decir, cualquier idea de optimización de código en MT5 es muy noble pero inútil, porque como mucho mejoraremos el índice en ese 5%.

No estoy de acuerdo con la última afirmación.

Gracias a las investigaciones de fxsaber, MT5 ya ha acelerado el trabajo con el histórico de operaciones en órdenes de magnitud.

 
Andrey Khatimlianskii:

No estoy de acuerdo con la última afirmación.

Gracias a la investigación de fxsaber, MT5 ya es órdenes de magnitud más rápido en el trabajo con el historial de operaciones.

No lo discuto. Fxsaber contribuye mucho al desarrollo del lenguaje y de la comunidad en general. Hace las cosas bien. Hay muchos errores en MT5 y es genial que alguien los encuentre. Pero no hay que confundir errores groseros en el trabajo de MT5, como resultado de los cuales la velocidad de trabajo disminuye en órdenes de magnitud, y cazar pulgas en el código SB. En algún lugar es ciertamente posible e incluso necesario para acelerar la lib. Pero si no hay errores groseros en ella, no habrá aceleración por órdenes de magnitud.

 
Vasiliy Sokolov:

No lo discuto. Fxsaber contribuye mucho a la lengua y a la comunidad en su conjunto. Hace las cosas bien. Hay muchos errores en MT5 y es genial que alguien los encuentre. Pero no hay que confundir errores groseros en el trabajo de MT5, como resultado de los cuales la velocidad de trabajo disminuye en órdenes de magnitud, y cazar pulgas en el código SB. En algún lugar es ciertamente posible e incluso necesario para acelerar la lib. Pero si no hay errores graves en ella, no habrá aceleración por órdenes de magnitud allí.

Ni siquiera he pensado en SB.

Creo que sólo vino a la mano para la comparación.

 
Andrey Khatimlianskii:

No estoy de acuerdo con la última afirmación.

Gracias a la investigación de fxsaber, MT5 ya ha acelerado el trabajo con el historial de operaciones en órdenes de magnitud.

Por cierto, por cierto, elhistorial de operaciones lo fastidié allá por 2013. Recuerdo que entonces me di cuenta de que el siguiente código no funciona linealmente:

int total = HistoryDealsTotal();
for(int i = 0; i < total; i++)
{
   ulong ticket = HistoryDealTicket(i);
   HistoryDealSelect(ticket);
}

Es decir, cuanto más i es, más lento funciona HistoryDealSelect. La ralentización era exponencial. Así que tuve que dibujar un gráfico de esta ralentización en Excel y comunicarlo a Service Desk. Así que sí, hubo y habrá bugs.

 

Ahora he retocado un poco el código cambiando OrderSend por OrderSendAsynch. Los resultados son previsiblemente diferentes:

85% del tiempo es tomado por HistorySelect. Es decir, volvemos a las llamadas al sistema, pero un poco diferentes.

 
La biblioteca fue escrita con este propósito
Al escribir diferentes versiones de código, puede ser necesario medir su influencia en el rendimiento general del Asesor Experto en el probador. Esto le permite no sólo entender qué tan óptimo es el código escrito en comparación con otro, sino que también proporciona los requisitos previos para la futura optimización rápida del Asesor Experto. Este enfoque nos permite identificar el "cuello de botella" en el rendimiento del EA.

Y este enfoque funcionó no sólo con MT4Orders.mqh, sino también con Trade.mqh - se hizo notablemente más rápido después de SD. También los resultados del uso de la biblioteca nos permitió acelerar notablemente algunas otras cosas(en particular).

Soluciones racionales de sonido, etc.

Hecho - el tiempo de Optimización depende mucho de cómo está escrito el código. La biblioteca quería llamar convenientemente no sólo mi propia, sino también la atención de los demás a esto.

Como ejemplo (que el Autor me perdone), hay muchos EAs en kodobase que, en términos de rendimiento, no brillan en Optimiser al menos por la librería de trading utilizada. De hecho, este es incluso un cierto azote de kodobase (y, estoy seguro, de Market), cuando un asesor OOP inteligente y fuerte anula todas las capacidades de velocidad del probador MT5.

Casi nada parece estar escrito para el probador. Y este es un componente enorme de trabajar con TS.

 
fxsaber:

... cuando un asesor OOP inteligente y fuerte anula todas las capacidades de velocidad del probador MT5.

Eche otro vistazo al perfil de su ejemplo. Todo se ve obstaculizado por el infernalmente lento HistorySelect(0, TimeCurrent). En OOP puedes omitir la llamada a HistorySelect, lo que reduce significativamente el tiempo de ejecución del programa en comparación con la llamada a funciones MQL5 puras. La afirmación de que OOP anula todas las capacidades de velocidad de MT5 es incorrecta. En algunos casos, gracias a ella, se puede acelerar al contrario, como en el caso de HistorySelect.

 
Vasiliy Sokolov:

Echa otro vistazo al perfil de tu ejemplo. Todo se ve obstaculizado por el infernalmente lento HistorySelect(0, TimeCurrent). En OOP es posible obviar la llamada a HistorySelect, lo que reduce significativamente el tiempo de ejecución del programa en comparación con la llamada a funciones MQL5 puras. La afirmación de que OOP anula todas las capacidades de velocidad de MT5 es incorrecta. En algunos casos, gracias a ella, se puede acelerar al contrario, como en el caso de HistorySelect.

Por alguna razón no ves que HistorySelect se llama sólo cuando no hay posiciones abiertas. Además, inmediatamente después se abre una nueva posición. Es decir, History se llama muy raramente. Es un hecho (compruébalo al menos por el tiempo en los logs) que el tiempo en el Tester difiere dependiendo de la implementación.


Yo escribo todo a través de OOP y nunca he insinuado su posible lentitud. La gran mayoría de autores especialmente aficionados a la POO crean diseños a veces MUY cómodos y bonitos. Sin embargo, no prestan atención al rendimiento de sus soluciones. Y esto es muy importante para un tester. Todo el mundo quiere optimizar su EA durante muchas horas más rápido (o más barato en la Nube). A menudo sucede que algún módulo de programación orientada a objetos, escrito hace mucho tiempo y automáticamente conectable, contiene un cuello de botella. Pero nadie se da cuenta, por supuesto.


Puedes escribir tu propio Asesor Experto que muestre el rendimiento de la API de trading utilizada. Por ejemplo, elimine el acceso al historial y el cálculo de lotes del original.

 
fxsaber:

Puedes escribir tu propio Asesor Experto que muestre el rendimiento de la API de trading utilizada. Por ejemplo, desde el original tirar el acceso a la historia y el cálculo del lote.

En CStrategy las operaciones comerciales se realizan a través de CTrade directamente. Es decir, CStrategy no tiene lógica de negociación propia en absoluto. En el Asesor Experto de prueba no vi ninguna otra lógica de negociación que la apertura/cierre de una posición en N segundos. CStrategy tampoco almacena posiciones históricas, por lo que este ejemplo no es realizable en CStrategy.

fxsaber:

La gran mayoría de Autores especialmente apasionados por la POO crean construcciones a veces MUY convenientes y bonitas.

La gran mayoría de autores apasionados por la POO no existen en principio, por desgracia. Puede que sólo haya 5-10 autores de POO para todo el recurso, incluidos los autores de SB de MetaQuotes. Somos pocos y estamos en focas:)

fxsaber:

Yo escribo todo mediante OOP y nunca he insinuado siquiera su posible lentitud. La inmensa mayoría de autores especialmente aficionados a la POO crean diseños a veces MUY cómodos y bonitos. Sin embargo, no prestan atención al rendimiento de sus soluciones. Y esto es muy importante para un tester. Todo el mundo quiere optimizar su EA durante muchas horas más rápido (o más barato en la Nube). A menudo sucede que algún módulo OOP escrito hace tiempo y automáticamente conectable contiene un cuello de botella. Pero, por supuesto, nadie se da cuenta.

El hecho de que el código OOP se ejecute más lentamente que el código procedimental no me dice nada. Vayamos al grano: ¿qué métodos de CTrade son el cuello de botella? ¿Por qué? ¿Qué te dice el perfilado de estos métodos? ¿Cómo se identifican las secciones de código lento en el probador?

1234
Nuevo comentario