Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 33
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
In diesem Beispiel ist die Aktualisierungsrate normal. Deshalb wird er nicht langsamer.
Im Task-Manager sehe ich Metatrader (32 bit)
Wurde das Problem der asynchronen Datenverarbeitung behoben?Kann es sein, dass der Grund für Ihre Verzögerungen mit der Bitgröße Ihres Systems zusammenhängt?
Denn Metatrader ist nur noch für x64 ausgelegt.
Und laut den Entwicklern wird es keine 32-Bit-Versionen mehr geben.
Ich sehe Metatrader (32 bit) im Task Manager
Und ist das Problem mit der asynchronen Datenverarbeitung gelöst worden?Vielleicht ist der Grund für die Langsamkeit mit der digitalen Kapazität Ihres Systems verbunden?
Nun, Metatrader ist nur noch für x64 vorgesehen.
Und laut den Entwicklern wird es keine 32-Bit-Versionen mehr geben.
Ich kann bestätigen, dass das von mir erwähnte Beispiel von Nikolai die CPU belastet, wenn eines der Objekte im Beispiel bewegt wird, insbesondere wenn dies schnell geschieht. Die Belastung steigt um 35-40 %. Der Test wurde mit einem 64-Bit-Prozessor, 64-Bit-Windows 7 und 64-Bit-MT5 durchgeführt.
Was ist in unserer Diskussion mit asynchroner Verarbeitung gemeint?
Ich kann Metatrader (32 bit) im Task Manager sehen.
Und ist das Problem mit der asynchronen Datenverarbeitung gelöst worden?Vielleicht liegt der Grund für Ihre Verzögerungen in der Bitstellenkapazität des Systems?
Tatsächlich ist Metatrader jetzt nur noch für x64 angepasst.
Und laut den Entwicklern wird es keine 32-Bit-Versionen mehr geben.
Alle diese Beispiele sind auf MT4.
MT5 zieht viel mehr, aber bei falschem Redrawing (z.B. einer Tasse) belastet es auch den Prozessor (habe ich überprüft). Das Problem liegt in der Häufigkeit und der Fläche der Neuzeichnung, die auf jeden Fall reduziert werden sollte. Wenn eine Zelle neu gezeichnet werden muss, dann ist sie die einzige Zelle. Andernfalls ist es eine Verschwendung von Ressourcen (wenn z.B. eine Zelle 10 Mal pro Sekunde neu gezeichnet werden muss, dann wird das Neuzeichnen der gesamten Leinwand den Prozessor "töten" und es wird unrealistisch sein). Aber es ist bereits klar.
Lassen Sie mich das erklären. Eine Tabellenzelle hat drei Objekte - Basis, Text und Symbol. Wenn sich der Inhalt einer Zelle ändert, müssen wir drei Schleifen auf der Leinwand machen. Im ersten Zyklus wird die Basis neu gezeichnet, im zweiten Zyklus der Text und im dritten Zyklus das Symbol. Es ist, als ob wir die Fläche der Zelle verdreifacht hätten. Wenn Sie die gesamte Leinwand auf diese Weise immer wieder neu zeichnen, kommt es zu einer erheblichen Verlangsamung. Sie sollten daher die Anzahl der Zyklen auf der neu zu zeichnenden Leinwandfläche berücksichtigen. Bei einfachen Primitiven sieht man das vielleicht nicht, aber bei komplexen Elementen wird es deutlich. Einige Elemente bestehen aus 10 Objekten(ein Eingabefeld mit Schaltflächen oder eine Ausgabeliste oder eine Fensterplattform), und es ist möglich zu berechnen, wie viele Zyklen auf einem Kanvas-Array gemacht werden müssen, wenn sie neu gezeichnet werden. Glücklicherweise erfordert dieses Umzeichnen keine hohe Wiederholungsrate.
Das Problem der asynchronen Verarbeitung ist noch nicht gelöst. Es gab einige Ideen, aber es wurde noch keine Lösung gefunden.
Im Großen und Ganzen sollten wir, wenn wir eine grafische Benutzeroberfläche auf der Leinwand erstellen wollen, diese aus separat neu zu zeichnenden Elementen zusammensetzen. Andernfalls stößt das Programm schnell an seine Grenzen, und dann werden die Verzögerungen bei einfachen Operationen spürbar.
Was versteht man unter asynchroner Datenverarbeitung in unserer Diskussion?
Nun, so wie ich es verstehe, in einfachen Worten, asynchron (Ressource Chasing) oder Multi-Threaded (dedizierte Ressource).
Ich habe mir den Code von Nikolays Beispielen nicht angesehen, aber wegen des Fehlens von Asynchronität und Multithreading inMetatrader wird der Code zum Neuzeichnen der Pixel synchron ausgeführt.
Und auch die Verarbeitung der Ausgangsdaten von Petera erfolgt höchstwahrscheinlich synchron. Und in beiden Fällen ist es wahrscheinlich, dass all dies immer noch in Zyklen verarbeitet wird.
Dies erhöht die Belastung des Prozessors. Um eine schnelle Reaktion bei gleichzeitig geringerer Belastung zu erreichen, sollten Datenverarbeitung und Redrawing parallel laufen.
Nun, so wie ich es verstehe, in einfachen Worten, asynchron (Ressource Rennen) oder Multithreading (dedizierte Ressource).
Ich habe mir den Code von Nikolays Beispielen nicht angesehen, aber wegen des Fehlens von Asynchronität und Multithreading inMetatrader wird der Code zum Neuzeichnen der Pixel synchron ausgeführt.
Und auch die Verarbeitung der Ausgangsdaten von Petera erfolgt höchstwahrscheinlich synchron. Und in beiden Fällen wird all dies wahrscheinlich in Schleifen verarbeitet werden.
Dies erhöht die Belastung des Prozessors. Um eine schnelle Reaktion bei gleichzeitig geringerer Belastung zu erreichen, sollten Datenverarbeitung und Neuberechnung parallel erfolgen.
Nicht wirklich)) Lassen Sie mich das verdeutlichen: Ich habe die Engine über eine Ressource mit der Benutzeranwendung verbunden. Das heißt, - die Benutzeranwendung führt ihre Berechnungen in ihrem Thread durch und übergibt die Daten an die Engine (die die grafische Benutzeroberfläche trägt), die sich auf einem anderen Graphen befinden kann. Dieser verarbeitet Parameterereignisse und gibt sie auf der grafischen Benutzeroberfläche aus. Mit anderen Worten: Die Verarbeitung wird in zwei Threads aufgeteilt. In dem Konstruktor, den ich veröffentlichen werde, wird dies jedoch nicht der Fall sein. Die Anwendung wird den Motor in sich selbst einschließen, und alles wird in einem einzigen Thread ablaufen. Die Belastung des Prozessors ist jedoch die gleiche. Die Abhängigkeit der Geschwindigkeit von der Abfolge der Funktionen wird einfach immer größer.
Nicht wirklich)) Lassen Sie mich das verdeutlichen: Ich habe die Engine über eine Ressource mit der Benutzeranwendung verbunden. Das heißt, - die Benutzeranwendung führt ihre Berechnungen in ihrem Thread durch und übergibt die Daten an die Engine (die die grafische Benutzeroberfläche trägt), die sich auf einem anderen Graphen befinden kann. Dieser verarbeitet Parameterereignisse und gibt sie auf der grafischen Benutzeroberfläche aus. Mit anderen Worten: Die Verarbeitung wird in zwei Threads aufgeteilt. In dem Konstruktor, den ich veröffentlichen werde, wird dies jedoch nicht der Fall sein. Die Anwendung wird den Motor in sich selbst einschließen, und alles wird in einem einzigen Thread ablaufen. Die Belastung des Prozessors ist jedoch die gleiche. Die Abhängigkeit der Geschwindigkeit von der Reihenfolge der auszuführenden Funktionen wird einfach größer.
Es geht wieder los... Versprechungen, Ankündigungen, Geschwätz.
sogar schon vergessen - "kernel-engine" wurde als anständige Software veröffentlicht ? oder als Mist in Form von Anhängen zu den Kommentaren
Nun, wie ich verstehe, in einfachen Worten, asynchron (Ressource Rennen) oder Multithreading (dedizierte Ressource).
Ich habe mir den Code von Nikolais Beispielen nicht angesehen, aber aufgrund des Fehlens von Asynchronität und Multithreading inMetatrader wird der Code zum Neuzeichnen von Pixeln synchron ausgeführt.
Und auch die Verarbeitung der Ausgangsdaten von Petera erfolgt höchstwahrscheinlich synchron. Und in beiden Fällen wird all dies wahrscheinlich in Schleifen verarbeitet werden.
Dies erhöht die Belastung des Prozessors. Um eine schnelle Reaktion bei gleichzeitig geringerer Belastung zu erreichen, sollten Datenverarbeitung und Neuberechnung parallel erfolgen.
Alle Vorgänge in MT sind strikt synchron, und dies kann nicht wirklich geändert werden, es sei denn, die Entwickler fügen der Anwendung Threads hinzu.
Es ist ziemlich überraschend, dass Entwickler versuchen, die MT-Funktionalität im Hinblick auf die Arbeit mit Datenbanken, mit Python, mit Sharpe... aber sie bieten an, das alles im selben Thread zu tun... Es ist einfach erstaunlich.
es geht wieder los ... Versprechen, Ankündigungen, Geschwätz
Ich habe sogar vergessen - wurde die "Kernel-Engine" als anständige Software veröffentlicht? oder als Mist, als Anhänge zu Kommentaren
Gut für Sie. Ich lasse mich inspirieren, wenn ich mit Leuten wie Ihnen kämpfe, und sie verlieren immer.)) Du gibst mir Energie, ohne dass du es merkst.
es geht wieder los ... Versprechen, Ankündigungen, Geschwätz
Ich habe sogar vergessen - wurde die "kernel-engine" als anständige Software veröffentlicht? oder als Mist in Form von Anhängen zu den Kommentaren
Max, sei diskret.
Nicht wirklich)) Lassen Sie mich das verdeutlichen: Ich habe die Engine über eine Ressource mit der Benutzeranwendung verbunden. Das heißt, - die Benutzeranwendung führt ihre Berechnungen in ihrem Thread durch und übergibt die Daten an die Engine (die die grafische Benutzeroberfläche trägt), die sich auf einem anderen Graphen befinden kann. Dieser verarbeitet Parameterereignisse und gibt sie auf der grafischen Benutzeroberfläche aus. Mit anderen Worten: Die Verarbeitung wird in zwei Threads aufgeteilt. In dem Konstruktor, den ich veröffentlichen werde, wird dies jedoch nicht der Fall sein. Die Anwendung wird den Motor in sich selbst einschließen, und alles wird in einem einzigen Thread ablaufen. Die Belastung des Prozessors ist jedoch die gleiche. Es ist nur so, dass die Abhängigkeit der Geschwindigkeit von der Reihenfolge der Funktionen größer sein wird.
Ich verstehe den Punkt, Anwendung getrennt, GUI getrennt.
Die Verarbeitung der Ausgabedaten im GUI erfolgt jedoch ohnehin synchron.
Die Anwendung sendet z. B. 10000 Elemente an GUI und GUI verarbeitet alle diese Elemente nacheinander.
Das ist das Problem. Es ist notwendig, die Verarbeitung der eingehenden Elemente und deren Ausgabe in der GUI zu parallelisieren. Basis, Text, Symbol.
Darüber hinaus gibt es drei Zyklen pro Zelle.