Diskussion zum Artikel "Vergleich von MQL5 und QLUA - warum sind Transaktionen in MQL5 bis zu 28 Mal schneller?" - Seite 3
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Gleichzeitig ist es, wenn Sie einen Unterschied in den Messungen schweben wie 10% haben.
Aber wenn nach den Ergebnissen von Dutzenden von Tests Sie eine stabile Differenz von 4-5 mal haben, gibt es nichts zu diskutieren.
Der Unterschied (nicht stabil) auf MT5 war bis zu zwei Mal. Deshalb habe ich beschlossen, dass wir, wenn wir die Leistung messen, die maximale Frequenz (Mindestzeit zwischen benachbarten Paketen) betrachten sollten, mit der Pakete ankommen. Ich habe einen entsprechenden Expert Advisor geschrieben
Und erhielt das Ergebnis
Und wenn ~10ms zwischen benachbarten BookEvent-Ereignissen plausibel ist. Aber 0,035ms ist es nicht. Es stellt sich heraus, dass ein BookEvent-Ereignis nach dem gleichen Prinzip wie ein Tick-Ereignis erzeugt wird:
Daher ist diese Messimplementierung nicht für Tick/Calculate/BookEvent-Ereignisse geeignet. Und wie man das Eintreffen eines neuen Kursnetzpakets in MQL5 überwacht, ist noch nicht klar.
Jeder Test muss einen Schutz gegen Kaltstart beinhalten.
Das Überspringen von N Ticks ist also ein Indikator dafür, dass wir uns dieser Tatsache bewusst sind und sie berücksichtigen. Nur um die natürlich zu erwartende Behauptung zu vermeiden, "warum haben Sie die Auswirkungen des Kaltstarts nicht kompensiert".
Das Video über den Start der Sitzung von drei Terminals wurde am 25. August 2016 für eine andere Behauptung eines Händlers vorbereitet, der behauptete, dass MT5 zu Beginn der Sitzung langsamer wird. Wie sich später herausstellte, nutzte dieser Händler MT5 gar nicht, sondern verbreitete Spekulationen aus dem Forum. Es stellte sich auch heraus, dass einige Händler nicht wussten, dass die Charts für Börseninstrumente nicht nach den Bid-, sondern nach den gehandelten Last-Preisen erstellt werden. Sie hielten das Ändern der Gebote und deren Nichtanzeige in den Charts für "MT5-Bremsen".
Natürlich gibt es keine Bremsen.
Der Unterschied (nicht stabil) auf MT5 betrug bis zu zwei Mal. Also beschloss ich, dass wir, wenn wir die Leistung messen, die maximale Frequenz (Mindestzeit zwischen benachbarten Paketen) betrachten sollten, mit der Pakete ankommen. Ich schrieb einen entsprechenden Expert Advisor
Und erhielt das Ergebnis
Und wenn ~10ms zwischen benachbarten BookEvent-Ereignissen plausibel ist. Aber 0,035ms ist es nicht. Es stellt sich heraus, dass ein BookEvent nach dem gleichen Prinzip erzeugt wird wie ein Tick-Event:
Plausibel.
Die Daten kommen transaktional, und die Tatsache, dass Sie zwei aufeinanderfolgende Transaktionen mit kurzem Timing gesehen haben, ist ein großartiger Beweis für die Korrektheit unserer Verarbeitung und die Leistung sowohl des Terminals selbst als auch des MQL5-Subsystems.
Es ist sehr gut geeignet.
Sehen Sie sich unseren Code an - er misst ausdrücklich nicht einzelne kurze Daten, sondern sammelt dummerweise Ticks für 30 Sekunden. Das gleicht Schwankungen und Fehler aus.
Im obigen Video erhielt MQL5 in 30 Sekunden 1.278 Ticks, während QLUA nur 254 Ticks erhielt. Das ist ein grausamer Reinfall für QLUA Algotrading.
Plausibel.
Die Daten kommen transaktional, und die Tatsache, dass Sie zwei aufeinanderfolgende Transaktionen mit kurzem Timing gesehen haben, ist ein großartiger Beweis für die Korrektheit unserer Verarbeitung und der Leistung sowohl des Terminals als auch des MQL5-Subsystems.
Aber sie kamen in einem Paket in einem Netzwerk-Paket. Ich möchte die Geschwindigkeit des Gateways messen.
Das passt gut.
Sehen Sie sich unseren Code an - er misst speziell nicht einzelne kurze Daten, sondern sammelt dummerweise Ticks für 30 Sekunden. Das gleicht Schwankungen und Fehler aus.
Im obigen Video erhielt MQL5 in 30 Sekunden 1.278 Ticks, während QLUA nur 254 Ticks erhielt. Das ist ein grausamer Reinfall für QLUA Algotrading.
Aber sie kamen gebündelt in das Netzwerkpaket. Ich möchte die Geschwindigkeit des Gateways messen.
Das spielt keine Rolle.
Die Ticks kamen einfach einer nach dem anderen, und das MT5-Terminal hat es geschafft, sie schön und ungebremst an Sie weiterzugeben.
Sie missverstehen mich. Ich interessiere mich nicht für die QLUA-Bremse - damit ist alles klar (und es gibt keine Fragen zum Artikel). Mir geht es um die Leistungsmerkmale des MT5 selbst. Und gerade der MaxFrequency-Weg, wie ich ihn implementiert habe, passt nicht. Denn MT5 hat eine Besonderheit bei der Erzeugung von Tick/Calculate/BookEvent-Events. Lassen Sie den Expert Advisor bei sich laufen - Sie werden es sehr schnell sehen.
Das Prinzip"jeder Tick ist eine unabhängig gesendete Transaktion" bedeutet, dass ideologisch alles richtig aufgebaut ist. Und wie kann es falsch sein, wenn wir 5 Plattformen von Grund auf neu gebaut haben und alle Fallstricke mehr als einmal durchlaufen haben.
Sie haben eine sehr hohe Leistung. Die Tatsache, dass Sie angefangen haben, die Frequenz zu erfinden, ist offensichtlicher Blödsinn. Wir haben Daten, wenn wir Daten haben, wenn wir Daten haben. Von "Frequenzstabilität/Instabilität" zu sprechen, macht also keinen logischen Sinn. Sie testen nicht die Stabilität des Quarzoszillators, sondern Sie versuchen, den Zufallsprozess der im Glas erscheinenden Preise zu stabilisieren.
Es ist nur Quick, der ursprünglich alle Prozesse auf die Kontrolle der Momentaufnahmefrequenz aufbaute. Mit einem natürlichen Ergebnis.
Das spielt keine Rolle.
Die Ticks kamen einfach einer nach dem anderen, und das MT5-Terminal hat es geschafft, sie schön und ungebremst an Sie weiterzugeben.
Das Prinzip "jeder Tick ist eine Transaktion, die unabhängig gesendet wird" bedeutet, dass ideologisch alles korrekt aufgebaut ist. Und wie kann es falsch sein, wenn wir 5 Plattformen von Grund auf neu aufgebaut haben und alle Fallstricke mehr als einmal durchlaufen haben.
Sie haben eine sehr hohe Leistung. Die Tatsache, dass Sie angefangen haben, die Frequenz zu erfinden, ist offensichtlicher Blödsinn. Wir haben Daten, wenn wir Daten haben, wenn wir Daten haben. Von "Frequenzstabilität/Instabilität" zu sprechen, macht also keinen logischen Sinn. Sie testen nicht die Stabilität eines Quarzoszillators, sondern Sie versuchen, den Zufallsprozess der im Glas erscheinenden Preise zu stabilisieren.
Das Prinzip der Frequenz kann ich leicht erklären. Der Stapel wird von der Börse selbst mit einer instabilen Geschwindigkeit gebildet, weil er von den Aktionen der Marktteilnehmer abhängt.
Ich wollte die maximale Frequenz der Stack-Updates messen - wie viele Stacks MT5 pro Zeiteinheit erzeugen kann. Es stellte sich heraus, dass die Einsätze in Paketen zum MT5 kommen. Es ist möglich, dass die Einsätze von der Börse nicht einmal verloren gehen, sondern ALLE überhaupt kommen. Und das BookEvent-Ereignis wird nicht für ein Paket erstellt, sondern für alle Einsätze in dem Paket (vom frühesten bis zum spätesten). Es ist unmöglich, den Zeitpunkt der Stapelbildung in MQL5 zu ermitteln. Der Zeitpunkt der Ankunft des Pakets ist derselbe. Es stellt sich also heraus, dass meine Implementierung der Messung des entsprechenden MT5-Leistungsmerkmals nicht das zeigt, was ich sehen möchte.
Die Tatsache, dass BookEvent in Paketen gebildet wird, unterstütze ich mit allen meinen Gliedern. Das ist maximale Information und minimaler Aufwand für den Expert Advisor. Das einzige Problem bei der Performancemessung ist das, was ich beschrieben habe.
Ich kann das Prinzip der Frequenz leicht erklären. Der Stack wird von der Börse selbst mit einer variablen Rate gebildet, da er von den Aktionen der Marktteilnehmer abhängt.
Ich wollte die maximale Frequenz der Stack-Updates messen - wie viele Stacks MT5 pro Zeiteinheit erzeugen kann. Es stellte sich heraus, dass die Einsätze in Paketen zum MT5 kommen. Es ist möglich, dass die Einsätze von der Börse nicht einmal verloren gehen, sondern ALLE überhaupt kommen. Und das BookEvent-Ereignis wird nicht für ein Paket erstellt, sondern für alle Einsätze im Paket (vom frühesten bis zum spätesten). Es ist unmöglich, den Zeitpunkt der Stapelbildung in MQL5 zu ermitteln. Der Zeitpunkt der Ankunft des Pakets ist derselbe. Es stellt sich also heraus, dass meine Implementierung der Messung des entsprechenden MT5-Leistungsmerkmals nicht das zeigt, was ich sehen möchte.
Die Tatsache, dass BookEvent in Paketen gebildet wird, unterstütze ich mit allen meinen Gliedern. Das ist maximale Information und minimaler Aufwand für den Expert Advisor. Aber es gibt nur ein Problem mit der Leistungsmessung, das ich beschrieben habe.
Ich wiederhole noch einmal - es macht keinen Sinn, die Häufigkeit auf diese Weise zu messen und solche Schlüsse zu ziehen.
Versuchen Sie nicht, die Häufigkeit eines zufälligen Prozesses des Kursauftretens im Stack auf der Grundlage der Zeitdifferenz zwischen zwei Ticks zu messen. Sie werden natürlich eine wilde Streuung der Zahlen von 1 bis XXXXX erhalten.
Sie haben die falsche Frage gestellt, falsch gerechnet und falsche Schlussfolgerungen gezogen. Gleichzeitig werfen Sie mit der Aussage "MT5 zeigt nicht das, was man sehen will, man kann es nicht messen" einen Schatten auf das Geflecht.
Es gibt kein Problem der "Leistungsmessung", denn Sie haben das Falsche und auf die falsche Weise gemessen. Sie haben eine falsche Kennzahl und eine grundlegend falsche Berechnung gewählt.
ps: aber in den Tests haben wir die Häufigkeit des Eintreffens von Angeboten korrekt gemessen, indem wir Angebote für 30 Sekunden gesammelt und durch die verbrachte Zeit dividiert haben.
Ich wiederhole es noch einmal: Es macht keinen Sinn, die Häufigkeit auf diese Weise zu messen und solche Schlussfolgerungen zu ziehen.
Versuchen Sie nicht, die Häufigkeit eines zufälligen Prozesses des Kursauftretens im Glas auf der Grundlage der Zeitdifferenz zwischen zwei Ticks zu messen. Sie werden natürlich eine wilde Streuung der Zahlen von 1 bis XXXXX erhalten.
Sie haben die falsche Frage gestellt, falsch gerechnet und falsche Schlussfolgerungen gezogen. Gleichzeitig haben Sie mit der Aussage "MT5 zeigt nicht an, was man sehen will, man kann es nicht messen" einen Schatten auf den Korb geworfen.
ps: aber wir haben in den Tests die Häufigkeit des Eintreffens von Kursen korrekt gemessen, indem wir 30 Sekunden lang Kurse gesammelt und durch die Zeit geteilt haben.
Ich messe die MAXIMALE Frequenz, nicht die aktuelle! Ich habe den Grund für diese Messungen und die Ergebnisse sehr detailliert beschrieben und die Quelle angegeben. Aus irgendeinem Grund haben Sie das Gefühl, ich würde einen Schatten auf MT5 werfen.
Jeder alte Hase im Forum, der diese Diskussion liest, wird verstehen, was ich meinte. Und er wird keinen Schatten auf MT5 sehen. Meine Umsetzung hat sich als falsch erwiesen. Meine, nicht Ihre! Dass Sie sich selbst verteidigen, wo ich nicht einmal einen Grund genannt habe.
Es ist meine Implementierung, die nicht erlaubt Ihnen zu messen, was Sie wollen. MQL5 hat eine solche Möglichkeit nicht und das ist normal. Genauso wie es normal ist, dass ich Saft will, aber MQL5 bietet eine solche Möglichkeit nicht.
Ich habe nur das Ergebnis geteilt, wenn jemand die Zeit zwischen den benachbarten Aufrufen der entsprechenden Ereignisse messen und als Leistung interpretieren will. Es ist notwendig, sich klar zu machen, was tatsächlich angezeigt werden soll.
Sie liegen grundlegend falsch.
Was ist die maximale Häufigkeit, wenn Sie tatsächlich das Delta eines Zufallsprozesses messen wollen, bei dem zwei Ereignisse das Delta 0 haben?
Wenn die Tick-Lieferung korrekt implementiert ist (und wir haben sie korrekt), erhalten Sie natürlich die maximale "Frequenz" = (Zeit der Verarbeitung des MQL5-Aufrufs mit dem Programmcode) / (Zeitgeberfehler).
Theoretisch wird die Frequenz unendlich sein, wenn Sie die Genauigkeit des Zeitgebers erreichen und 0 Mikrosekunden erhalten. Nun, und der kritische Fehler der Division durch Null (Sie haben keine Kontrolle über die Division durch Null in Ihrem Code).
Sie liegen grundlegend falsch.
Was ist die maximale Frequenz, wenn Sie tatsächlich das Delta eines Zufallsprozesses messen wollen, bei dem zwei Ereignisse Delta 0 haben?
Wenn die Tick-Lieferung korrekt implementiert ist (und wir haben sie korrekt), erhalten Sie auf jeden Fall die maximale "Frequenz" = (Zeit der Verarbeitung des MQL5-Aufrufs mit dem Programmcode) / (Timer-Fehler).
Ja, so habe ich es verstanden. Es hat sich herausgestellt, dass ich einen zufälligen Prozess gemessen habe, und ich wollte den Prozess der Netzwerk-Paketlieferung messen. Aber das hat nicht funktioniert.
Theoretisch ist die Frequenz unendlich, wenn man die Genauigkeit des Timers einhält und 0 Mikrosekunden erhält. Tja, und ein kritischer Fehler bei der Division durch Null(Sie haben keine Kontrolle über die Division durch Null in Ihrem Code).