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
Ich glaube, dass diese MQ-Wand ohne die Unterstützung der Forumsmitglieder nicht durchkommen wird. Der Code ist kurz, die Profis sollten ihn schnell herausfinden können. Dort gibt es keine Mängel. Es zeigt sich deutlich, dass die Preise durch Positionen viel schneller erhalten werden als durch Market Watch. Ich verstehe nicht, wie MQ das Offensichtliche nicht sehen kann.
1. Ihr Test zählt wirklich nur einen winzigen Prozentsatz an Iterationen aufgrund der Bedingung
Im Wesentlichen werden nur Anomalien gezählt, bei denen der Prozessor mit Aufgaben überlastet ist und die Ausführung der jeweiligen Aufgabe auf die lange Bank schiebt, da über 99 % der Iterationen in weniger als einer Mikrosekunde durchgeführt werden.
Und selbst wenn Sie die Bedingung >0 setzen, gibt es immer noch keine Objektivität.
2. Die Zeitmessung solcher schnellen Operationen sollte nur als volle Zykluszeit erfolgen, nicht als einzelne Iteration.
3. aber da der Zyklus in Ihrem Beispiel auf 10 Sekunden begrenzt ist (Warum! Für Ticks sind 0,1 Sekunden meiner Meinung nach völlig ausreichend. Da es durchaus vorkommen kann, dass 3 Ticks in einer Sekunde eintreffen und alle drei Ticks jeweils 10 Sekunden lang und parallel ausgeführt werden, ist kein Timing erforderlich. Es ist einfacher zu berechnen, wie viele Iterationen in einer bestimmten Zeit ausgeführt werden. Je mehr, desto höher die Produktivität.
Ich habe Ihren Code "ein bisschen" geändert. Ich denke, meine Variante spiegelt die Realität besser wider.
Die Berechnung erfolgt nacheinander, um die beiden Varianten nicht zu vermischen. Gerade Zahlen sind fürSYMBOL_BID, ungerade - für GetBid().
Ich fügte Summen und ihre Ausgabe nur für den Fall hinzu, dass ich versuche, den Compiler gegen die Optimierung auszutricksen.
Das Ergebnis der Ausgabe ist kumulativ.
Mein Ergebnis:
Wie Sie sehen können, ist der Leistungsunterschied dreimal größer als bei der Standardversion.
Wie Sie sehen können, ist der Leistungsunterschied dreimal so groß wie bei der Originalversion.Zeigt die Originalversion von fxsaber den GetBid-Vorteil, oder handelt es sich um einen leistungsfähigeren/weniger belasteten PC?
Zeigt die Originalversion von fxsaber einen GetBid-Vorteil, oder ist der PC leistungsfähiger/weniger belastet?
Seine Variante zeigte auch bei voller CPU-Auslastung einen GetBid-Vorteil. Aber gleichzeitig zeigt meine Variante den dreifachen Vorteil der regulären Funktion bei gleicher Belastung.
Das liegt daran, dass meine Variante die durchschnittliche Zeit aller Iterationen berücksichtigt, um den Angebotspreis zu erhalten, und nur einen winzigen Teil mit anomalen Hängern.
Wer weiß, aus welchem Grund der Prozessor bei der regulären Funktion (wenn die Verzögerung mehr als 100 µ beträgt) in einer schwierigen "Minute" ins Stocken gerät. Dennoch ist die durchschnittliche Zeit für die reguläre Funktion dreimal kürzer
Dies ist z. B. der Fall, wenn (Intervall##A > 100):
wenn jedoch (Intervall##A > 0) bereits recht unterschiedlich ist, was eine Zufallsverteilung von abnormalen Verzögerungen zwischen der regulären und der alternativen Version der Erlangung des Geldkurses zeigt
zur gleichen Zeit zeigt mein Test bei der gleichen CPU-Last:
Daher denke ich, dass die von fxsaber vorgeschlagene Version des Tests alles andere als objektiv ist.
Ich habe die CPU nicht mit Agenten belastet, sondern mit diesem Skript. Es war effizienter.
nach einer leichten Änderung des fxsaber-Tests, um deutlich zu machen, welcher Prozentsatz der Iterationen in die Berechnungen einfließt:
d.h. etwa 0,01%.
Darauf können Sie wetten.
Wenn die durchschnittliche Ausführungszeit von SymbolInfoDouble(_Symbol, SYMBOL_BID) etwa 50 Nanosekunden beträgt, werden nur solche mit einer Ausführungszeit von über 100 000 Nanosekunden berücksichtigt.
nach einer leichten Änderung des fxsaber-Tests, um deutlich zu machen, welcher Prozentsatz der Iterationen in die Berechnungen einfließt:
d.h. etwa 0,01%.
Und ob.
Wenn die durchschnittliche Ausführungszeit von SymbolInfoDouble(_Symbol, SYMBOL_BID) etwa 50 Nanosekunden beträgt, werden nur die Iterationen gezählt, die länger als 100 000 Nanosekunden dauern.
Wir hätten einfach die Bedingung nicht mehr als 100 µs, sondern mehr als 3 µs machen können. Das Ergebnis war offenbar das gleiche. Der Gedanke war, dass es bei einer segmentierten Studie und bei unterschiedlichen Ausführungsbedingungen einen Unterschied in verschiedenen Segmenten und in verschiedenen Abschnitten geben könnte. Ausführungsprioritäten werden oft von irgendetwas abhängig gemacht. Bei geringer Last einige Prioritäten, bei hoher Last andere, bei kritischer Last diejenigen, die den Computer nicht hängen lassen und zum Absturz bringen, und die Leistung tritt in den Hintergrund.
Im Allgemeinen ist es nicht richtig, mit einer Auslastung von mehr als 70 % der Hardware zu handeln. Es ist eine fast kritische Leistung. Die Eisenbelastung von Kampf-EAs sollte 60 % nicht überschreiten.
und haben Sie bereits HFT-Broker?)
Versuchen Sie, SymbolInfoTick zu testen, wenn es nur ein Symbol in der Marktübersicht gibt und wenn es Dutzende von Symbolen gibt, aber fragen Sie nach einem Tool - wie in Ihrem Beispiel
es ist sehr wahrscheinlich, dass der Server komprimierten Datenverkehr sendet und dass SymbolInfoTick beim Dekomprimieren der Daten periodische Verzögerungen erfährt
d. h., wenn es viele Symbole gibt, wird es noch häufigere oder tiefere Einbrüche in der Testzeit geben
In neueren Builds hat der Empfang von Tick-Streams nicht einmal theoretisch einen Effekt. Praktisch funktioniert SymbolInfoTick bereits mit Cache, aber einige Bürger suchen immer noch nach einer schwarzen Katze.
In dem Test sind es nicht einmal 80 %. Es laufen 6 Agenten auf 4 Kernen, d.h. 100% garantiert.
Die einzige Frage ist, wie der Taskplaner seines Systems mit dieser Situation umgeht. Gleichzeitig wird behauptet, dass es an der Umsetzung der Terminals liegt, die dafür verantwortlich ist.
Das heißt, es wird künstlich eine Situation geschaffen, in der ein Computer überlastet ist, in der buchstäblich alles auf ihm langsamer wird, und dann werden Behauptungen aufgestellt in der Form "Oh, sieh mal, warum ist der Terminal manchmal lags".
Verschließen wir die Augen vor der Tatsache, dass es selbst unter solchen Bedingungen "etwa 0,01 %" sind - zum Teufel mit den Details! Es genügt zu sagen, dass "sich niemand für die durchschnittliche Temperatur im Krankenhaus interessiert", "Verzögerungen beim Handel Probleme verursachen" und "wir wollen HFT".
Außerdem wollen wir natürlich HFT in 20 Experten auf einem alten Büro-Desktop oder einer toten virtuellen Maschine.
PS PositionSelectByTicket() hat in seiner Implementierung sicherlich Zugriff auf eine gemeinsame Ressource mit Zugriffssynchronisierung. Und wenn Sie nicht bei jedem Anruf die Position auswählen, lesen Sie den alten Kurs. Es war einfacher, einen "Schnappschuss" über SymbolInfoDouble zu machen.