MT5 und Geschwindigkeit in Aktion - Seite 71
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 schlage vor, dass dies das Ende der Theorien ist, die sich hier nie mit der Praxis überschneiden werden.
Dann schlage ich vor, dass Sie auch die sinnlosen synchronen Single-Thread-Tests einstellen.
In der Erwartung, parallele Ergebnisse zu erhalten.
Das Problem ist in keiner Weise gelöst. MQL-Programme werden sehr viel komplexer, wenn auf die internen Variablen beispielsweise von verschiedenen Threads aus zugegriffen wird.
Es ist nur so, dass MQL6 ähnlich wie Erlang sein sollte, nicht wie C++.)
Dann schlage ich vor, dass Sie auch die sinnlosen synchronen Single-Thread-Tests einstellen.
In der Erwartung, parallele Ergebnisse zu erhalten.
Ich bin besorgt über Verzögerungen großen Ausmaßes, die bei fast jedem Tick auftreten. Das hat nichts mit dem Gewinde zu tun. Die Entwickler sind dabei, das herauszufinden.
Es ist nur so, dass MQL6 ähnlich wie Erlang sein sollte, nicht wie C++.)
dann ist Scala besser.
.... aber egal wie man es betrachtet, hinter den Hüllen dieser starken funktionalen Sprachen mit dynamischer Typisierung... wird immer noch maschinelles C++ sein, Python ist ein Beweis dafür, das diskutierte Java mit Ereignisschleifen ist aus einer anderen Galaxie, wo man ein verteiltes Multiprozessorsystem braucht, um eine Art von Expansion und Skalierbarkeit des Rechensystems zu erhalten
In der Schule.
- Wowotschka, wie verwenden Sie Hühnerflaum?
- Ich weiß es nicht.
- Und worauf schlafen Sie?
- Auf dem Boden.
- Und worauf legen Sie Ihren Kopf?
- Auf einem Filzstiefel.
- Und worauf schlafen deine Eltern?
- Auf dem Boden.
- Und worauf setzen sie ihre Köpfe?
- Auf dem valenki.
- Und worauf schläft die Oma?
- Auf dem Herd.
- Und worauf legt sie ihren Kopf?
- Auf einem Kopfkissen.
- Und was ist der Flaum im Kopfkissen?
- Und in dem Kissen ist ein Valenki.
Scala ist besser als
.... aber egal wie man es betrachtet, hinter den Hüllen dieser starken funktionalen Sprachen mit dynamischer Typisierung... Python ist ein Beweis dafür, das diskutierte Java mit Ereignisschleifen ist aus einer anderen Galaxie, wo man ein verteiltes Multiprozessorsystem haben muss, um eine Art von Erweiterbarkeit und Skalierbarkeit des Rechensystems zu erhalten.
Das ist die Sache, Python ist in C geschrieben und Python hat eine asyncio-Bibliothek, die auf dem Ereignisschleifenmodell basiert.
Soviel zur Anekdote mit den Schwaden ))
dann ist Scala besser.
Die Hauptsache ist, in VHDL zu kompilieren und einen eigenen Server zu erstellen)
Die Diskussion ist etwas ins Abseits geraten - die Geschwindigkeit der Integration mit Python ist natürlich ein wichtiges Thema, aber es gibt viele grundlegende Probleme, die die Ausführungsgeschwindigkeit von EAs beeinflussen.
Ich schlage vor, sich auf das Problem zu konzentrieren, dass in der Funktion OnTradeTransaction im abschließenden Aufruf von TRADE_TRANSACTION_HISTORY_ADD die Felder der Strukturen MqlTradeTransaction und MqlTradeResult praktisch leer sind, d.h. sie werden nicht analog dazu gefüllt, wie sich der Auftrag dann in der Registerkarte History widerspiegelt und wie sie in der Hilfe/Dokumentation abgelegt sind. Die Korrektur dieses Fehlers würde bereits zu einer echten Beschleunigung der Kampfausführung führen, da es nicht mehr notwendig wäre, HistoryOrderSelect unnötig aufzurufen, um erschöpfende Werte über den ausgeführten Auftrag zu erhalten.
Und im Großen und Ganzen wird die Beseitigung dieser Lücke auf der Ebene der Mql-Community zu einer massiven Verringerung des Aufwands führen, der erforderlich ist, um verschiedene Krücken in Expert Advisors zu erstellen, um die Unzulänglichkeiten der aktuellen Implementierung von OnTradeTransactio zu umgehen.
Die Frage ist, wie man das MQ-Team beeinflussen kann. Vielleicht ein separater Beitrag mit Abstimmung und Unterschriftensammlung zur Beseitigung dieses Mangels dieser Funktion?
Die Frage ist, wie man das MQ-Entwicklungsteam beeinflussen kann.
Mein Rezept scheint zu funktionieren: Ich reproduziere das Problem mit präzisem Code.
Die Diskussion ist etwas ins Abseits geraten - die Geschwindigkeit der Integration mit Python ist natürlich ein wichtiges Thema, aber es gibt viele grundlegende Probleme, die die Ausführungsgeschwindigkeit von EAs beeinflussen.
Ich schlage vor, sich auf das Problem zu konzentrieren, dass in der Funktion OnTradeTransaction im abschließenden Aufruf von TRADE_TRANSACTION_HISTORY_ADD die Felder der Strukturen MqlTradeTransaction und MqlTradeResult praktisch leer sind, d.h. sie werden nicht analog dazu gefüllt, wie sich der Auftrag dann in der Registerkarte History widerspiegelt und wie sie in der Hilfe/Dokumentation abgelegt sind. Die Behebung dieses Fehlers würde bereits zu einer echten Beschleunigung der Kampfausführung führen, da es nicht mehr notwendig wäre, HistoryOrderSelect unnötig aufzurufen, um umfassende Werte über den ausgeführten Auftrag zu erhalten.
Und im Großen und Ganzen wird die Beseitigung dieser Lücke auf der Ebene der Mql-Community zu einer massiven Verringerung des Aufwands führen, der erforderlich ist, um verschiedene Krücken in Expert Advisors zu erstellen, um die Unzulänglichkeiten der aktuellen Implementierung von OnTradeTransactio zu umgehen.
Die Frage ist, wie man das MQ-Team beeinflussen kann. Vielleicht ein separater Beitrag mit Abstimmung und Unterschriftensammlung zur Beseitigung dieses Mangels dieser Funktion?
Python ist ein gutes Beispiel für ein ereignisgesteuertes Modell. Und Igors Anekdote trifft genau den Punkt.
Und wenn der Entwickler die Bedeutung des Beispiels verstanden hat, dann weiß er auch, wo er graben muss.
Jede Erwartung, dass früher oder später ein Ergebnis vorliegt, beruht auf einem synchronen Ausführungsmodell.
Bei mql ist es soweit. Die Möglichkeiten der Sprache sind sehr vielfältig, aber künstlich auf synchrone Ausführung beschränkt.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
Du bist derjenige, der es nicht versteht. Bring den Thread nicht durcheinander.