Meine Unzufriedenheit mit dem Strategietester. mit den MQL-Entwicklern - Seite 7

 

(Fortsetzung)

Ich habe einige einfache Programme zum analytischen Verständnis erstellt, die zeigen, dass der Markt einen starken Einfluss auf die Ask- und Bid-Ticks hat.


Hat die Markierung bereits ihren Platz im Forumszitat gefunden?

das ist ein HIT ... :-)

PS/ Tester wird benötigt, um die Leistung des Roboters zu überprüfen. Optimierer, um sicherzustellen, dass die Parameter stabil sind. Der Tester entwickelt keine Strategien und der Optimierer errät den Markt nicht.

 

Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests

Meine Unzufriedenheit mit dem Strategietester. an MQL-Entwickler

Renat Fatkhullin, 2017.12.02 15:23

Und Sie vergleichen, wie ihr Zip im schwachen Kompressionsmodus komprimiert. Vielleicht ist das bei BMP-Dateien auch so.

Die Ressourcenkomprimierung funktioniert.

Es ist nicht seriös, solche Dinge ohne Beweise vor dem Hintergrund einer direkten Widerlegung zu behaupten.

Nehmen Sie diesen Code. Meine EX5 hat 1.717.722 Bytes. Die schwächste Komprimierungsstufe von ZIP beträgt 1.177.567 Bytes.

Demo_BitmapOffset (OBJPROP_XOFFSET и OBJPROP_YOFFSET)
Demo_BitmapOffset (OBJPROP_XOFFSET и OBJPROP_YOFFSET)
  • Stimmen: 19
  • 2011.03.25
  • MetaQuotes Software Corp.
  • www.mql5.com
С появлением двух новых свойств стало возможным загружать одно изображение с набором из нескольких картинок. Такая технология давно используется в web-дизайне и получила название Спрайт: Важно: для использования свойств OBJPROP_XOFFSET и OBJPROP_YOFFSET обязательно указывайте размер области видимости с помощью свойств OBJPROP_XSIZE и...
 
fxsaber:

Nehmen Sie diesen Code. Meine EX5 hat 1.717.722 Bytes. ZIP im schwächsten Modus - 1 177 567 Bytes.

Das stimmt, diese Dateien sind nur schwach komprimiert und die EX-Dateigröße ist angemessen.

Natürlich werden die Ressourcen innerhalb der EX komprimiert.

 
Renat Fatkhullin:

Das stimmt, diese Dateien sind schlecht komprimiert, und die Größe der EX-Datei ist angemessen.

Natürlich sind die Ressourcen innerhalb von EX komprimiert.

Nein, leider nicht.

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));  
}


Ergebnis

826534
306648


Ihr ZIP komprimiert viel besser als EX5.

 

Die Ressourcen werden mit dem schnellstmöglichen lzss-Algorithmus komprimiert, nicht gezippt.

Es ist nicht selbstmörderisch, den Reißverschluss sehr lange zu schließen und ihn dann lange wieder zu öffnen.

 
Renat Fatkhullin:

Die Ressourcen werden mit dem schnellstmöglichen lzss-Algorithmus komprimiert, nicht gezippt.

Es ist nicht selbstmörderisch, den Reißverschluss sehr lange zu schließen und ihn dann lange wieder zu öffnen.

#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)))
}

Ergebnis

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

Sind 80 ms Selbstmord?

 
fxsaber:




Ergebnis

80 ms sind Selbstmord?

Führen Sie es auf einem Celeron aus.

Und dann skalieren Sie im Projekt auf eine größere Dateivariante.

 
Renat Fatkhullin:
Führen Sie es auf einer Zelone aus.

Es geht natürlich um die relative Zeit. Auf meinem i7 dauert das Kompilieren des Quellcodes aus KB

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


Wenn ich das kommentiere.

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


Ich erhalte eine Reduzierung um 30 ms.

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


Die gesamte Umstellung auf reines ZIP (80ms) würde 282ms dauern. Die Verlangsamung würde also 21,5 % betragen. Und dies gilt für den einfachsten Quellcode.

Nimmt man Quellen, die sich in Sekunden kompilieren lassen, beträgt die Verlangsamung etwa 1 %. In diesem Fall scheint es keine große Sache zu sein.

 

Nein, wir glaubten und glauben immer noch, dass Ressourcen so schnell wie möglich über den gesamten Zoo von Prozessoren komprimiert und dekomprimiert werden sollten. Es gibt viele Prozessoren, die von der Ökonomie erdrosselt werden, darunter auch halb-vitale Atome. Das bedeutet einen Geschwindigkeitsverlust von einem Dutzend Mal im Vergleich zu den leistungsfähigen Prozessoren von heute.

Übrigens, in der neuesten Version von MT5 haben wir die Startgeschwindigkeit des Terminals und des Editors nach einer eingehenden Bewertung der Auswirkungen der Ressourcenkompression und der Initialisierungsmethoden des Schutzes drastisch erhöht. Wir haben ganze Sekunden auf Low-End-Prozessoren gewonnen.

Was auf einem vollwertigen i7/Xeon nicht wahrnehmbar war, wurde auf Atoms/Celebrons und ähnlich leistungsstarken Geräten innerhalb von Sekunden zur Katastrophe.

 
Renat Fatkhullin:

Nein, wir glaubten und glauben immer noch, dass Ressourcen so schnell wie möglich über den gesamten Zoo von Prozessoren komprimiert und dekomprimiert werden sollten. Es gibt viele Prozessoren, die von der Ökonomie erdrosselt werden, darunter auch halb-vitale Atome. Das bedeutet einen Geschwindigkeitsverlust von einem Dutzend Mal im Vergleich zu den leistungsfähigen Prozessoren von heute.

Übrigens, in der neuesten Version von MT5 haben wir die Startgeschwindigkeit des Terminals und des Editors nach einer eingehenden Bewertung der Auswirkungen der Ressourcenkompression und der Initialisierungsmethoden des Schutzes drastisch erhöht. Wir haben ganze Sekunden auf Low-End-Prozessoren gewonnen.

Was auf einem vollwertigen i7/Xeon nicht wahrnehmbar war, wurde auf Atoms/Celebrons und ähnlich leistungsstarken Geräten innerhalb von Sekunden zur Katastrophe.

Hut ab vor dieser Forschungsarbeit! Ich hätte gerne den gleichen gründlichen Ansatz für CopyTicks und CustomSymbols. Dort ist es fast eine Katastrophe.