Bibliotheken: TesterBenchmark - Seite 3

Neuer Kommentar
 
Andrey Khatimlianskii:

Vasily, sprichst du ernsthaft über die Angemessenheit der Ausführungsgeschwindigkeit von OrderSend im Test und in der Realität?

Online ist es das langsamste, weil es Informationen an den Server sendet und auf eine Antwort wartet, während im Tester (wenn man die Verzögerung nicht mit einbezieht, aber das stand nicht zur Debatte), Senden und Warten sofort passieren.

Die Aufgabe dieser Bibliothek besteht lediglich darin, die Geschwindigkeit des Testers (in Bezug auf die Handelsfunktionen) zu messen.

Ja, ich habe nicht darüber nachgedacht. Mein Fehler. Speziell OrderSend arbeitet im Tester viel schneller. Aber ich behaupte nach wie vor, dass der Löwenanteil der Testzeit von den Systemfunktionen aufgefressen wird. Und im MT5 wird sie sehr gut aufgefressen, weil es dort, anders als im MT4, eine vollständige Simulation der Handelsumgebung gibt. Selbst wenn das Pipelining um 16 % beschleunigt wird, sind das nur 16 % von 5 % der Gesamtzeit, die für dieses Pipelining benötigt wird. Das heißt, alle Ideen zur Code-Optimierung in MT5 sind sehr nobel, aber sinnlos, weil wir bestenfalls den Index um diese 5 % verbessern werden.

 
Vasiliy Sokolov:

Ja, ich habe nicht nachgedacht. Mein Fehler. OrderSend funktioniert im Testprogramm viel schneller. Aber ich behaupte immer noch, dass der Löwenanteil der Testzeit von den Systemfunktionen aufgefressen wird. Und in MT5 wird sie sehr gut aufgefressen, weil es dort, anders als in MT4, eine vollständige Simulation der Handelsumgebung gibt. Selbst wenn das Pipelining um 16 % beschleunigt wird, sind das nur 16 % von 5 % der Gesamtzeit, die für dieses Pipelining benötigt wird. Das heißt, alle Ideen zur Code-Optimierung in MT5 sind sehr edel, aber sinnlos, weil wir bestenfalls den Index um diese 5% verbessern werden.

Mit der letzten Aussage bin ich nicht einverstanden.

Dank der Forschung von fxsaber hat MT5 die Arbeit mit der Historie der Trades bereits um Größenordnungen beschleunigt.

 
Andrey Khatimlianskii:

Mit der letzten Aussage bin ich nicht einverstanden.

Dank der Forschung von fxsaber ist MT5 bereits um Größenordnungen schneller in der Arbeit mit der Geschichte der Trades.

Ich bestreite das nicht. Fxsaber leistet einen großen Beitrag zur Entwicklung der Sprache und der Gemeinschaft im Allgemeinen. Er macht die richtigen Dinge. Es gibt eine Menge Fehler im MT5 und es ist toll, dass jemand sie findet. Aber man sollte grobe Fehler in der MT5-Arbeit, durch die die Arbeitsgeschwindigkeit um Größenordnungen sinkt, nicht mit dem Fangen von Flöhen im SB-Code verwechseln. Irgendwo ist es sicher möglich und sogar notwendig, die Lib zu beschleunigen. Aber wenn es keine groben Fehler darin gibt, wird es keine Beschleunigung um Größenordnungen geben.

 
Vasiliy Sokolov:

Ich bestreite das nicht. Fxsaber leistet einen großen Beitrag zur Sprache und zur Gemeinschaft als Ganzes. Er macht die richtigen Dinge. Es gibt eine Menge Fehler im MT5 und es ist toll, dass jemand sie findet. Aber man sollte grobe Fehler in der MT5-Arbeit, durch die die Arbeitsgeschwindigkeit um Größenordnungen sinkt, nicht mit dem Fangen von Flöhen im SB-Code verwechseln. Irgendwo ist es sicher möglich und sogar notwendig, die Lib zu beschleunigen. Aber wenn keine groben Fehler drin sind, wird es da keine Beschleunigung um Größenordnungen geben.

Über SB habe ich gar nicht nachgedacht.

Ich glaube, es ist mir nur zum Vergleich in die Hände gefallen.

 
Andrey Khatimlianskii:

Ich bin mit der letzten Aussage nicht einverstanden.

Dank der Forschung von fxsaber, MT5 hat bereits die Arbeit mit der Geschichte der Trades um Größenordnungen beschleunigt.

Durch die Art und Weise, durch die Art und Weise, dieGeschichte der Trades geschraubt zurück in 2013. Ich erinnere mich, dass mir damals aufgefallen ist, dass der folgende Code nicht linear funktioniert:

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

D.h. je mehr i ist, desto langsamer arbeitet HistoryDealSelect. Die Verlangsamung war exponentiell. Ich musste also ein Diagramm dieser Verlangsamung in Excel zeichnen und mit dem Service Desk kommunizieren. Also, ja, es gab und gibt Fehler.

 

Jetzt habe ich den Code ein wenig verändert, indem ich OrderSend in OrderSendAsynch geändert habe. Die Ergebnisse sind erwartungsgemäß anders:

85% der Zeit wird durch HistorySelect verbraucht. D.h. wir sind wieder bei Systemaufrufen, aber ein bisschen anders.

 
Die Bibliothek wurde zu diesem Zweck geschrieben
Wenn Sie verschiedene Code-Versionen schreiben, kann es notwendig sein, deren Einfluss auf die Gesamtleistung des Expert Advisors im Tester zu messen. Auf diese Weise lässt sich nicht nur feststellen, wie optimal der geschriebene Code im Vergleich zu einem anderen ist, sondern es werden auch die Voraussetzungen für eine künftige schnelle Optimierung des Expert Advisors geschaffen. Dieser Ansatz ermöglicht es uns, den "Flaschenhals" in der Performance des EAs zu identifizieren.

Und dieser Ansatz funktionierte nicht nur mit MT4Orders.mqh, sondern auch mit Trade.mqh - es wurde nach SD spürbar schneller . Auch die Ergebnisse der Verwendung der Bibliothek erlaubten es uns, einige andere Dinge spürbar zu beschleunigen(insbesondere).

Vernünftige Lösungen, etc.

Tatsache - die Zeit bis zur Optimierung hängt sehr stark davon ab, wie der Code geschrieben ist. Die Bibliothek wollte nicht nur meine eigene, sondern auch die Aufmerksamkeit anderer darauf lenken.

Als Beispiel (der Autor möge mir verzeihen): Es gibt viele EAs in kodobase, die in Bezug auf die Performance im Optimiser nicht glänzen, zumindest aufgrund der verwendeten Handelsbibliothek. In der Tat ist dies sogar eine gewisse Geißel von kodobase (und, da bin ich mir sicher, von Market), wenn ein intelligenter und starker OOP-Advisor alle Geschwindigkeitsmöglichkeiten des MT5-Testers zunichte macht.

Fast nichts scheint für den Tester geschrieben zu werden. Und dies ist ein wichtiger Bestandteil der Arbeit mit TS.

 
fxsaber:

... wenn ein intelligenter und starker OOP-Advisor alle Geschwindigkeitsmöglichkeiten des MT5-Testers zunichte macht.

Schauen Sie sich noch einmal das Profiling Ihres Beispiels an. Alles wird durch das höllisch langsame HistorySelect(0, TimeCurrent) behindert. In OOP können Sie den Aufruf von HistorySelect umgehen, was die Ausführungszeit des Programms im Vergleich zum Aufruf von reinen MQL5-Funktionen deutlich reduziert. Die Behauptung, dass OOP alle Geschwindigkeitsvorteile von MT5 zunichte macht, ist falsch. In einigen Fällen können Sie dank OOP im Gegenteil die Geschwindigkeit erhöhen, wie im Fall von HistorySelect.

 
Vasiliy Sokolov:

Schauen Sie sich das Profiling Ihres Beispiels noch einmal an. Alles wird durch die infernalisch langsame HistorySelect(0, TimeCurrent) behindert. In OOP ist es möglich, den Aufruf von HistorySelect zu umgehen, was die Ausführungszeit des Programms im Vergleich zum Aufruf von reinen MQL5-Funktionen deutlich reduziert. Die Behauptung, dass OOP alle Geschwindigkeitsvorteile von MT5 zunichte macht, ist falsch. In einigen Fällen können Sie dank OOP im Gegenteil die Geschwindigkeit erhöhen, wie im Fall von HistorySelect.

Aus irgendeinem Grund sehen Sie nicht, dass HistorySelect nur aufgerufen wird, wenn es keine offenen Positionen gibt. Außerdem wird sofort danach eine neue Position eröffnet. Das heißt, History wird nur sehr selten aufgerufen. Es ist eine Tatsache (überprüfen Sie zumindest die Zeit in den Protokollen), dass die Zeit im Tester je nach Implementierung unterschiedlich ist.


Ich schreibe alles über OOP und habe nie auch nur angedeutet, dass es möglicherweise langsamer ist. Die überwiegende Mehrheit der Autoren, die besonders auf OOP versessen sind, erstellen manchmal SEHR bequeme und schöne Designs. Sie achten jedoch nicht auf die Leistung ihrer Lösungen. Und das ist für einen Tester sehr wichtig. Jeder möchte seinen EA um viele Stunden schneller (oder billiger in der Cloud) optimieren. Es kommt oft vor, dass ein lang geschriebenes und automatisch pluggbares OOP-Modul einen Flaschenhals enthält. Aber das merkt natürlich niemand.


Sie können Ihren eigenen Expert Advisor schreiben, der die Leistung der verwendeten Handels-API zeigt. Entfernen Sie zum Beispiel den Zugriff auf die Historie und die Lot-Berechnung aus dem Original.

 
fxsaber:

Sie können Ihren eigenen Expert Advisor schreiben, der die Leistung der verwendeten Handels-API anzeigt. Lassen Sie zum Beispiel den Zugriff auf die Historie und die Lotberechnung aus dem Original heraus.

In CStrategy werden die Handelsoperationen direkt über CTrade durchgeführt. Das heißt, CStrategy hat überhaupt keine eigene Handelslogik. Im Test-Expert Advisor habe ich keine andere Handelslogik gesehen als das Öffnen/Schließen einer Position in N Sekunden. CStrategy speichert auch keine historischen Positionen, so dass dieses Beispiel in CStrategy leider nicht realisierbar ist.

fxsaber:

Die überwiegende Mehrheit der Autoren, die sich besonders für OOP begeistern, schaffen manchmal SEHR bequeme und schöne Konstruktionen.

Die große Mehrheit der OOP-begeisterten Autoren gibt es im Prinzip nicht, leider. Es gibt vielleicht nur 5-10 OOP-Autoren für die gesamte Ressource, einschließlich der SB-Autoren von MetaQuotes. Wir sind wenige und wir sind in Dichtungen:)

fxsaber:

Ich schreibe alles in OOP und habe nie auch nur angedeutet, dass es möglicherweise langsamer ist. Die überwältigende Mehrheit der Autoren, die besonders scharf auf OOP sind, erstellen manchmal SEHR bequeme und schöne Designs. Sie achten aber nicht auf die Performance ihrer Lösungen. Und das ist für einen Tester sehr wichtig. Jeder möchte seinen EA um viele Stunden schneller (oder billiger in der Cloud) optimieren. Es kommt oft vor, dass ein lang geschriebenes und automatisch pluggbares OOP-Modul einen Flaschenhals enthält. Aber natürlich merkt das niemand.

Die Tatsache, dass OOP-Code langsamer ausgeführt wird als prozeduraler Code, sagt mir gar nichts. Kommen wir zur Sache: Welche CTrade-Methoden sind der Flaschenhals? Und warum? Was sagt Ihnen das Profiling dieser Methoden? Wie können Sie langsame Codeabschnitte im Tester identifizieren?

1234
Neuer Kommentar