Pracht und Armut der PLO - Seite 7

[Dmitry Fedoseev]

Ich habe es gefunden! Mit der PLO konnte ich immerhin eine höhere Geschwindigkeit erreichen. Ja, die Vorteile sind unbestreitbar.

[Dmitry Fedoseev]

dimeon:

Dann sollten wir alles in Assembler schreiben. Es wäre ohnehin schneller.

Ich verstehe das Problem nicht. Ich habe noch nie einen Expert Advisor oder Indikator mit 1 MB Code gesehen.

Auch der Aufruf einer Funktion nimmt einige Zeit in Anspruch. Lassen Sie uns auch Funktionen aufgeben!

Die Kontrolle über große Projekte ist mit OOP viel einfacher.

Außerdem ist die Geschwindigkeit der Code-Ausführung oft nicht so entscheidend wie die Ping-Zeit an den Makler und die Antwort auf den Auftrag des Maklers.

Sehen Sie sich die HFT-Algorithmen an. Sie erfordern maximale Geschwindigkeit, aber Sie werden dort keine komplexen Berechnungen finden.

PS. Normalerweise braucht man kein Superauto oder Schneemobil, um von A nach B zu kommen. Ein Moped reicht aus! Ein Moped ist genug!

Es gibt hier eine Person, die, anstatt eine Funktion zu schreiben, Code in die Datei schreibt und ihn einfügt.

[Alexey Navoykov]

Integer:

Ich habe es gefunden! Mit der PLO konnte ich immerhin eine höhere Geschwindigkeit erreichen. Ja, die Vorteile sind unbestreitbar.

Wie lautete also der Code?

[Dmitry Fedoseev]

meat:
Wie lautete also der Code?

Aufruf von iCustom() mit einer unterschiedlichen Anzahl von Parametern, einem anderen Fall für jede Anzahl von Parametern oder einer anderen Klasse für jede Anzahl von Parametern in der OOP-Variante.

[Renat Fatkhullin]

Im neuen Build des MQL-Compilers haben wir bereits die Optimierung eingebaut, eine virtuelle Methode durch einen direkten Aufruf zu ersetzen, wenn es sich um die letzte Methode in einer Kette von virtuellen Methoden handelt und keine Verbindungen zu externen Bibliotheken bestehen.

Diese Methode vereinfacht und beschleunigt virtuelle Aufrufe in vielen Programmen, die mit Klassen arbeiten.

Die Ergebnisse des test.mq4-Beispiels aus dem ersten Beitrag im 670er Build:

switch: 172
OOP:    312

Die Schleife musste von 10.000.000 auf 50.000.000 erhöht werden, um nicht mit winzigen Zeitmessungen von 32-64 ms arbeiten zu müssen. Die Zeit wird in ms angegeben, je kleiner die Zahl, desto schneller ist der Code.

Dies ist das Ergebnis, das ich mit dem neuen Compiler für denselben Code erhalten habe:

switch: 157
OOP:     93

OOP hat mit einem Paukenschlag gewonnen. Aber warum?

Zunächst wurde die virtuelle Methode in eine reguläre Methode umgewandelt, dann wurde sie zinlined und auf Null optimiert. Tatsächlich verschwanden Funktionsaufruf und -körper vollständig, so dass eine reine Schleife übrig blieb:

  mov     int[i] <- int[0]

$label:
                                        <- тут когда-то было тело, но оно оптимизировалось в ноль
  add     int[i] <- int[i], int[1]
  jlt     int[i], int[50000000] --> $label

Die Dateien sind beigefügt, einschließlich der neuen Beta-Version des Konsolen-Compilers. Sie können alle Beispiele mit dem regulären 670er Build von MetaEditor (der Compiler ist darin integriert) und dem Konsolen-Compiler vergleichen.

Was dies beweist:

1. Es wird die Qualität des Compiler-Optimierers getestet.
2. Tests sollten mit einem umfassenden Verständnis dafür geschrieben werden, wie alles optimiert wird.
3. Wie gesagt - ich habe an einem bestehenden Beispiel gezeigt, wie man sich täuschen kann (OOP hat plötzlich gewonnen), wenn man die Besonderheiten der Codeoptimierung nicht kennt.