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
Es stellte sich heraus, dass ich auf die Frequenz der Netzgenerierung und nicht auf die Ausgangsfrequenz geachtet hatte.
Es handelt sich um verschiedene Zahlen, die ein Vielfaches voneinander sind.
Es stellte sich heraus, dass ich die Häufigkeit der Netzgenerierung (ohne Ausgabe) und die Häufigkeit der Ausgabe (ohne Generierung) ein wenig falsch berechnet hatte
Hier ist eine korrektere Version.
Ergebnisse auf meinem Prozessor:
Nimmt man die reine Zeit, indem man ein Bild mit 200 geglätteten Kreisen ohne Ausgabe erzeugt, geschieht dies mit etwa 500 Bildern pro Sekunde.
einen Frame mit 200 ungeglätteten Kreisen ohne Ausgabe bilden - etwa 1000 fps.
Die Frequenz der Bildausgabe (Leinwand) selbst (Aktualisierungsfunktion) beträgt etwa 650 fps.
Sie haben wirklich hart gearbeitet!
Hüten Sie sich vor Massenkonvertierungen der Typen (int)double oder (double)int und der Vermischung von int+double in Mat-Operationen im Allgemeinen.
Das gibt dem Prozessor den wildesten Overhead - eben einen solchen teuren Assembler-Befehl. Wenn Sie in Double zählen, zählen Sie weiter in Double und wechseln Sie nicht zu Integer-Typen.
Befehle wie cvtsi2sd/cvttsd2si sind sehr lang. Ein kleiner Tipp im Artikel"Der langsamste x86-Befehl", Schurke Nummer 2.
Vielen Dank für diesen sehr wertvollen Artikel.
Aber um ehrlich zu sein, verstehe ich nicht, warum dann in diesem einfachen Skript:
die Summe von long mit Umwandlung von double in long ist viel schneller als die Summe von double des gleichen Arrays ohne Umwandlung
Erstens sollte man sich den Assemblercode und das Ergebnis von Optimierungen für extrem einfache Fälle ansehen (die Supermikrosynthetik ist schon lange irreführend). Es ist leicht, einen idealen Fall von Förderanlagen zu finden.
Zweitens kann kaum jemand garantieren, wie dieser oder jener Code kompiliert wird und wie lange er zur Ausführung braucht.
Man muss nur eine weitere Zeile/Befehl in den Code einfügen und die Geschwindigkeit ändert sich drastisch. Der eigentliche Code/die eigentlichen Daten könnten durchaus aus dem L1/L2-Cache kommen, und das war's.
Wie hat es bei Ihnen funktioniert? In der Theorie / Super-Synthetik scheint es, dass Integer-Befehle in der Geschwindigkeit helfen, aber in der realen Code ist es ein Drain. Denn es gibt zehn- bis hundertmal mehr Code, keine Konvektorisierung, ständige Sprünge von ganzzahligen zu reellen Berechnungen und die Optimierung ist begrenzt.
Warum ist die Initialisierung von Arrays beliebigen Typs in MQL4 mehr als 10 Mal langsamer als in MQL5?
Warum ist die Initialisierung von Arrays beliebigen Typs in MQL4 mehr als 10 Mal langsamer als in MQL5?
Denn dort sind alle Arrays dynamisch und die Sprache ist zehnmal langsamer.
Ein ultraschneller Indikator mit Hunderten von gleitenden Durchschnitten, implementiert auf Canvas.
100 MA-Zeilen (Periodenschritt 10) - Zeit der Berechnung und Anzeige auf dem Bildschirm - 4-7 Millisekunden
1000 Zeilen MA (Periodenschritt 1) - Zeit der Berechnung und Anzeige - 20-30 Millisekunden.
Ich habe den Code nicht allzu sehr getestet. Es kann Fehler geben. Nur für einen Pixel dicken Balken implementiert (er wird zu diesem Maßstab gezwungen). Auch die Bildwiederholfrequenz ist nicht optimiert. Alle Zeilen werden berechnet und bei jedem Tick vollständig ausgegeben.
Ein ultraschneller Indikator mit Hunderten von gleitenden Durchschnitten, implementiert auf Canvas.
100 MA-Zeilen (Periodenschritt 10) - Zeit der Berechnung und Anzeige auf dem Bildschirm - 4-7 Millisekunden
1000 MA-Zeilen (Periodenschritt 1) - Zeit für Berechnung und Anzeige - 20-30 Millisekunden
cool, mit Standardindikatoren wäre alles tot
cool, die Standard-Indikatoren hätten das alles aufgehängt.
und dann wäre da noch eine Meile Code...
vielleicht kann sogar das nur mit einer Vorlage gemacht werden. Ich weiß nicht, ob die Anzahl der Indikatorlinien im Körper eines Indikators begrenzt ist.
...
Die Begrenzung der Anzahl von Indikatorzeilen im Körper eines Indikators ist nicht bekannt.
Es gibt eine Grenze. Es können bis zu 512 Anzeigepuffer erstellt werden >>>https://www.mql5.com/ru/docs/indicators