Theorie der EA-Beschleunigung bei Verwendung eines benutzerdefinierten Indikators (Funktion - iCustom)

 

Ich möchte vorausschicken, dass ich kein Programmierer bin und mich irren könnte, aber ich würde gerne die Meinung eines Fachmanns zu der unten vorgeschlagenen Idee hören, die auf Berechnungen beruht.

Die Verwendung von benutzerdefinierten Indikatoren ist ein aktuelles Thema bei der Entwicklung eines Expert Advisors in mehreren Stufen. Das ist besonders wichtig, wenn sich die Programmierer gegenseitig ersetzen. Dann ist es besser, einen Teil der Logik des Expert Advisors in den Indikator einzufügen, die Logik zu testen (um die Berechnungen und ihre Relevanz zu überprüfen) und dann an einem neuen Teil der Idee zu arbeiten. Als Ergebnis erhalten wir einen nicht sehr komplexen Expert Advisor, der tatsächlich Informationen vom Indikator anfordert und eine Entscheidung trifft, indem er die erwarteten und tatsächlichen Daten vergleicht.

Dieser Ansatz hat jedoch einen entscheidenden Nachteil: die Geschwindigkeit eines solchen Expert Advisors. Denn je häufiger die Daten von den benutzerdefinierten Indikatoren angefordert werden, desto langsamer ist die Berechnung und desto mehr Ressourcen (Speicher) werden für die Optimierung benötigt.

Bisher arbeite ich mit MT4, aber das Prinzip dieses Problems, wie ich es verstehe, ist das gleiche.

Und das Problem liegt nicht in der Berechnungsgeschwindigkeit des iCustom Indikators selbst, sondern in seiner Verbindung mit dem Expert Advisor.

Angenommen, der Indikator verwendet 5 Diagrammpuffer und der EA benötigt Informationen aus diesen Puffern, dann muss er 5 iCustom-Funktionen in seinem Code verwenden und tatsächlich 5 Indikatoren auf das Diagramm setzen, anstatt eines Indikators, was 5 Mal mehr Ressourcen erfordert. Vielleicht liege ich falsch, und der Compiler analysiert diesen Umstand - er berechnet für einen Indikator und gibt allen Funktionen die Daten für die benötigten Puffer auf einmal? In diesem Fall sind meine weiteren Spekulationen müßig.

Aber wenn das nicht so ist, warum nicht die Informationen aus dem Indikator in einem Paket zusammenfassen?

Ich schlage vor, ein Experiment zu diesem Thema durchzuführen und die Leistung des Expert Advisors zu messen.

Dazu muss ein benutzerdefinierter Indikator mit mehr als einem Puffer verwendet und ein zusätzlicher Puffer hinzugefügt werden.

Der Algorithmus ist logisch (nicht mathematisch):

1. Konvertieren Sie die Puffer im Indikator in ganze Zahlen, abhängig von den Ziffern pro Zahl, insgesamt 3 Puffer, war: 1,21101; 1,13; 5, wurde: 121101;113;5

2. Wir zählen, wie viele Ziffern wir nach der ersten Zahl setzen müssen - in unserem Fall 4, dann in der nächsten Zahl die nächste - 1, diese Werte sind der Grad des Multiplikators:

1,21101*10^4=1211010000

1.13*10^1=113

5*10^0=5 (Prüfung auf 0)

3. Addiere die Zahlen und erhalte 1211011135.

4. Schreiben Sie den Wert in den Puffer 4.

5. Wir fordern den 4-Indikator-Puffer im Expert Advisor an und zerlegen den Wert in umgekehrter Reihenfolge in Komponenten und erhalten 3 Zahlen, die für die Arbeit des Expert Advisors weiter verwendet werden können.

Kann jemand die Geschwindigkeit dieses Ansatzes vergleichen, gibt es eine Begründung dafür?

 
...Допустим, индикатор использует 5 графических буферов и для работы советника требуется информация с этих буферов, тогда в коде советника необходимо использовать 5 функций iCustom, и фактически вместо одного индикатора наносить на график 5 индикаторов, что требует в 5 раз больше ресурсов. Быть может я не прав и компилятор анализирует это обстоятельство - делая расчет по одному индикатору и дает сразу всем функциям данные по востребованным буферам!? Тогда дальше мои измышления пусты...

Der Compiler kann viele Dinge tun, aber nicht das :-)

...Allerdings hat dieser Ansatz einen entscheidenden Nachteil - die Geschwindigkeit eines solchen Expert Advisors. Denn je häufiger die Daten von den benutzerdefinierten Indikatoren angefordert werden, desto langsamer ist die Berechnung und desto mehr Ressourcen (Speicher) werden für die Optimierung benötigt ...

Und dieser Fall kann optimiert werden. Erstens sollte der Indikator selbst intelligent geschrieben werden (nicht alle Balken auf jeden Tick neu zu berechnen), zweitens sollte der Indikator super schwer sein, um den EA irgendwie zu verlangsamen... Um eine lange Geschichte kurz zu machen...

Und hier ist ein interessanter Artikel über "Verringerung des Speicherverbrauchs von Hilfsindikatoren".

Ich hatte einen Multicurrency Expert Advisor, der Indikatorwerte für 28 Symbole für 8 Zeitrahmen erhielt.

Es waren 28*8=224 Kopien von Indikatoren... Ich habe mich mit der Frage beschäftigt, wie ich den Prozess optimieren kann. Die Operation mit mehreren Währungen verbrauchte fast 700 MB RAM... Ich habe das Problem ganz einfach gelöst - ich habe einfach das Feld "Maximale Balken im Fenster" in den Terminaleinstellungen auf der Registerkarte "Diagramme" auf einen kleinen Wert gesetzt... Soweit ich mich erinnere, liegt das Minimum für dieses Feld bei 5 Tausend Barren...

Уменьшаем расход памяти на вспомогательные индикаторы
Уменьшаем расход памяти на вспомогательные индикаторы
  • 2011.03.18
  • Andrew
  • www.mql5.com
Если индикатор для своих расчетов задействует значения множества других индикаторов, то такая система расходует много памяти. В статье рассмотрены несколько способов снижения расхода памяти при использовании вспомогательных индикаторов. Сэкономленная память позволит вам увеличить число одновременно используемых в терминале валютных пар, индикаторов и стратегий, что повысит надежность вашего торгового портфеля. Вот так простая забота о технических ресурсах вашего компьютера способна превратиться в материальные ресурсы на вашем депозите.
 

Ich habe einen Anstieg der Testzeit um den Faktor 1,2 bis 1,3 gemessen, was im Vergleich zu den Vorteilen, die die benutzerdefinierten Indikatoren bieten, ziemlich unbedeutend ist.

Die Schlussfolgerung mit den 5 Puffern ist falsch. Wenn die Parameter gleich sind, wird nur ein Indikator geladen.

 

Integer:

Die Schlussfolgerung zu den 5 Puffern ist falsch. Wenn die Parameter gleich sind, wird nur ein Indikator geladen.

Ja, ich stimme zu.

Es wird 5 Aufrufe der Funktion CopyBuffer() mit unterschiedlichen Argumenten (Puffernummer) geben. Und die Kopie des Indikators - der Griff - wird derselbe sein.

Der Autor hat das Thema lautstark "Beschleunigungstheorie..." betitelt, aber er hat keine Ahnung von den grundlegenden Dingen.

-Aleks, es gibt viele Artikel zu diesem Thema!


 
denkir:

Ja, ich stimme zu.

Es wird 5 Aufrufe der Funktion CopyBuffer() mit unterschiedlichen Argumenten (Puffernummer) geben. Und es wird nur ein Exemplar des Indikators geben - handle.

Der Autor hat das Thema lautstark "Beschleunigungstheorie..." betitelt, aber er hat keine Ahnung von den grundlegenden Dingen.

-Aleks-, es gibt eine Menge Artikel zum Thema Indikator!


Ich habe einmal versucht, die Aufrufgeschwindigkeit von integrierten und analogen Indizes über iCustom zu messen. Eingebaute Geräte sind etwa 20-50 % schneller. Wahrscheinlich, weil sie in C++ und nicht in MQL geschrieben sind.
 

Denkir, ich spreche über die Arbeit des EA während der Optimierung, hat die Anzahl der Kerzen auf dem Chart Einfluss auf die Menge der Berechnungen? Ich habe den Artikel studiert, ich weiß, dass es Varianten von Optimierungsindikatoren gibt. In diesem Fall möchte ich jedoch glauben, dass der Indikator perfekt ist und die Methode zur Übergabe der Daten vom Indikator an den EA untersuchen. Ich bin kein Programmierer und finde es schwierig, den optimalen Code des Indikators zu überprüfen - höchstens kann ich in TOR eine Verzögerung von 1 Bar und eine Begrenzung der Historie für Berechnungen vorschreiben.

Integer:

Ich habe gemessen, dass sich die Testzeit um das 1,2- bis 1,3-fache erhöht, was im Vergleich zu den Vorteilen, die die benutzerdefinierten Indikatoren bieten, absolut unbedeutend ist.

Meine Schlussfolgerung zu den 5 Puffern ist nicht korrekt. Wenn die Parameter gleich sind, wird nur ein Indikator geladen.

Was haben Sie gemessen? Und 30 % sind für mich gar nicht so wenig.

Über die 5-Puffer, wenn ich Sie richtig verstanden, dann mit den gleichen Eingabeparametern des Indikators, die Berechnung wird für nur einen Indikator durchgeführt, wenn der Expert Advisor ruft die letzte mehrere Male und erhält Informationen aus verschiedenen Puffer?

Wenn das so ist, dann sollte die Kombination von benutzerdefinierten Indikatoren die Arbeit des Expert Advisors beschleunigen? Zum Beispiel kann in einem Indikator die Logik verschiedener Indikatoren mit unabhängigen Einstellungen implementiert werden. Wenn einer von ihnen aufgerufen wird, werden die Informationen von allen Puffern auf einmal empfangen und im Falle einer Informationsanfrage von einem anderen Puffer mit den gleichen Parametern verwendet?

VDev:
Ich habe versucht, die Geschwindigkeit des Aufrufs von eingebetteten Indizes und ihren Analoga durch iCustom zu messen. Eingebaute Geräte sind etwa 20-50 % schneller. Wahrscheinlich, weil sie in C++ und nicht in MQL geschrieben sind.

Das ist eine Tatsache.
 

Äußerst interessanter Artikel "Preisreihenmittelung ohne zusätzliche Puffer für Zwischenberechnungen " von GODZILLA.

Er wurde im Jahr 2010 geschrieben.

Es gibt einen Abschnitt 3 Vergleich der erhaltenen Indikator mit Klassen mit seinen Analoga mit Aufrufen von technischen und benutzerdefinierten Indikatoren im Code

Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
  • 2010.10.25
  • Nikolay Kositsin
  • www.mql5.com
Статья о традиционных и не совсем традиционных алгоритмах усреднения, упакованных в максимально простые и достаточно однотипные классы. Они задумывались для универсального использования в практических разработках индикаторов. Надеюсь, что предложенные классы в определенных ситуациях могут оказаться достаточно актуальной альтернативой громоздким, в некотором смысле, вызовам пользовательских и технических индикаторов.
 
denkir:

Ja, ich stimme zu.

Es wird 5 Aufrufe der Funktion CopyBuffer() mit unterschiedlichen Argumenten (Puffernummer) geben. Und es wird nur ein Exemplar des Indikators geben - handle.

Der Autor nannte das Thema lautstark "Beschleunigungstheorie" und hat von den Grundlagen überhaupt keine Ahnung.

-Aleks-, es gibt eine Menge Artikel zum Thema Indikator!


Und Sie können meine Hypothese einfach widerlegen (am besten auf 4), indem Sie meine Worte mit Zahlen untermauern?

Das Thema ist über meine Theorie - der Titel ist ok :)

 
-Aleks-:

Denkir, ich spreche über die Leistung des EA während der Optimierung, hat die Anzahl der Kerzen auf dem Chart Einfluss auf die Menge der Berechnungen gibt?

-Aleks-, über den Prüfer Sie müssen den Entwickler fragen ...

Aber ich denke, es gibt ein Problem mit den Begriffen in der Diskussion. Wollen Sie die Geschwindigkeit der Berechnungen verringern oder RAM für die Arbeit mit dem Indikator sparen?



 
denkir:

-Aleks-, über den Prüfer. Sie müssen die Entwickler fragen...

Meiner Meinung nach gibt es jedoch ein Problem mit den Begriffen in der Diskussion. Wollen Sie die Geschwindigkeit der Berechnungen verringern oder RAM für die Arbeit mit dem Indikator sparen?

Ich glaube, dass meine Methode beide Probleme lösen wird. Ich kann mich irren.

Bei der Optimierung ist die Geschwindigkeit wichtig, aber sobald der Arbeitsspeicher überlastet ist, sinkt nach meinen Beobachtungen die Verarbeitungsgeschwindigkeit pro Durchlauf.

 
-Aleks-:

Kann jemand die Geschwindigkeit dieses Ansatzes vergleichen, gibt es einen Grund dafür?

Dieser Ansatz verringert den Speicherverbrauch des Indikators (ungefähr ein Vielfaches der Differenz zwischen der Anzahl der Puffer davor und danach), erhöht aber die Belastung des Prozessors (sowohl das "Assembling" als auch die "Decomposition" müssen ständig durchgeführt werden).

Und wenn der Indikator 5 Puffer hat, dann wird der erste Aufruf von iCustom alle Puffer berechnen, die nachfolgenden Aufrufe und Anforderungen anderer Puffer werden nur die fertigen Informationen lesen (bis zum Erscheinen neuer Daten für die Berechnung).

Wenn Sie einen wirklich schweren Indikator haben, denken Sie sich ein eigenes Cache-System aus, so dass beim ersten Aufruf die Daten berechnet und in die Datei geschrieben werden, und bei den nächsten Aufrufen nur noch gelesen werden. Ich habe es auf diese Weise gemacht, es geht viel schneller.

Aber in 95 % der Fälle ist das alles nicht nötig, der Tester ist schon schnell genug, und in 5 Fällen kann man auch die Cloud anschließen.

Viel Glück!

Grund der Beschwerde: