Mi descontento con el probador de estrategias. con los desarrolladores de MQL - página 7

[Maxim Kuznetsov]

(Continuación)

He realizado algunos programas sencillos de comprensión analítica que demuestran que el mercado tiene una fuerte influencia en los ticks de Ask y Bid.

¿el marcado ya ha encontrado su lugar en la citación del foro?

eso es un HIT ... :-)

PS/ Se necesita un probador para comprobar el rendimiento del robot. Optimizador para asegurarse de que los parámetros son estables. El probador no hace estrategias y el optimizador no adivina el mercado.

[fxsaber]

Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Mi descontento con los probadores de estrategias. con los desarrolladores de MQL

Renat Fatkhullin, 2017.12.02 15:23

Y comparas cómo comprime su zip en modo de compresión débil. Tal vez los archivos BMP sean así.

La compresión de recursos funciona.

No es serio decir esas cosas sin pruebas en el fondo de la refutación directa.

Toma este código. Mi EX5 tiene 1.717.722 bytes. ZIP en su modo de compresión más débil tiene 1.177.567 bytes.

[Renat Fatkhullin]

fxsaber:

Toma este código. Mi EX5 tiene 1.717.722 bytes. ZIP en modo débil - 1 177 567 bytes.

Así es, estos archivos en particular están débilmente comprimidos y el tamaño del archivo EX es razonable.

Por supuesto, dentro de la EX los recursos están comprimidos.

[fxsaber]

Renat Fatkhullin:

Así es, estos archivos en particular se comprimen mal y el tamaño del archivo EX es razonable.

Por supuesto, dentro de los recursos EX están comprimidos.

No, por desgracia.

void OnStart()
{
  uchar Data[];
  uchar Key[1];
  uchar Result[];
  
  FileLoad("thousands_rubies_galaxy.bmp", Data);  
  Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result));
  
  ArrayFree(Data);
  
  FileLoad("space_wind.wav", Data);  
  Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result));  
}

Resultado

826534
306648

Su ZIP se comprime mucho mejor que el EX5.

[Renat Fatkhullin]

Los recursos están comprimidos con el algoritmo lzss más rápido posible, no comprimidos.

No somos suicidas para cerrar la cremallera durante mucho tiempo y luego abrirla durante mucho tiempo.

[fxsaber]

Renat Fatkhullin:

Los recursos están comprimidos con el algoritmo lzss más rápido posible, no comprimidos.

No somos suicidas para cerrar la cremallera durante mucho tiempo y luego abrirla durante mucho tiempo.

#define  BENCH(A)                                                              \
{                                                                             \
  const ulong StartTime = GetMicrosecondCount();                              \
  A;                                                                          \
  Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \
} 

void OnStart()
{
  uchar Data[];
  uchar Key[1];
  uchar Result[];
  
  FileLoad("thousands_rubies_galaxy.bmp", Data);  
  BENCH(Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result)))
  
  ArrayFree(Data);
  
  FileLoad("space_wind.wav", Data);  
  BENCH(Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result)))
}

Resultado

826534
Time[Print(CryptEncode(CRYPT_ARCH_ZIP,Data,Key,Result))] = 53334
306648
Time[Print(CryptEncode(CRYPT_ARCH_ZIP,Data,Key,Result))] = 29029

¿80ms es un suicidio?

[Renat Fatkhullin]

fxsaber:

Resultado

¿80ms es un suicidio?

Ejecútalo en un Celeron.

Y luego escalar a una variante de tamaño de archivo mayor en el proyecto.

[fxsaber]

Renat Fatkhullin:
Pásalo por un celorón.

Se trata de un tiempo relativo, por supuesto. En mi i7, la compilación del código fuente desde KB tarda

'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5   1       1
0 error(s), 0 warning(s), compile time: 232 msec                1       1

Cuando lo comento.

//#resource "\\Files\\thousands_rubies_galaxy.bmp";
//#resource "\\Files\\space_wind.wav";

Obtengo una reducción de 30ms.

'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5   1       1
0 error(s), 0 warning(s), compile time: 202 msec                1       1

El cambio total a ZIP puro (80ms) llevaría 282ms. Así que la desaceleración sería del 21,5%. Y esto es para el código fuente más sencillo.

Si se toman fuentes que se compilan en segundos, la ralentización será de aproximadamente un 1%. Parece que en este caso no es gran cosa.

[Renat Fatkhullin]

No, creíamos y seguimos creyendo que los recursos deben comprimirse y descomprimirse lo más rápido posible en todo el zoo de procesadores. Hay muchos procesadores estrangulados por la economía, incluidos los átomos semivitales. Hay una pérdida de velocidad de una docena de veces en comparación con los potentes procesadores actuales.

Por cierto, en la última compilación de MT5 hemos aumentado drásticamente la velocidad de lanzamiento del terminal y del editor tras una profunda evaluación del impacto de la compresión de recursos y de los métodos de inicialización de la protección. Hemos ganado segundos enteros en procesadores de gama baja.

Lo que era imperceptible en los i7/xeon completos, era un desastre por segundos en los atoms/celebrons y otros de potencia similar.

[fxsaber]

Renat Fatkhullin:

No, creíamos y seguimos creyendo que los recursos deben comprimirse y descomprimirse lo más rápido posible en todo el zoo de procesadores. Hay muchos procesadores estrangulados por la economía, incluidos los átomos semivitales. Hay una pérdida de velocidad de una docena de veces en comparación con los potentes procesadores actuales.

Por cierto, en la última compilación de MT5 hemos aumentado drásticamente la velocidad de lanzamiento del terminal y del editor tras una profunda evaluación del impacto de la compresión de recursos y de los métodos de inicialización de la protección. Hemos ganado segundos enteros en procesadores de gama baja.

Lo que era imperceptible en los i7/xeon a pleno rendimiento, era un desastre por segundos en los atoms/celebrons y similares.

Me quito el sombrero ante semejante investigación. Me gustaría el mismo enfoque exhaustivo para CopyTicks y CustomSymbols. Es casi un desastre allí.