Diskussion zum Artikel "Schnellere Berechnungen mit dem MQL5 Cloud Network"
Was ist mit der Genetik? Dort ist das "100-fache" unerreichbar. Nun, wenn es 20-30 Mal ist, oder sogar weniger.
Was ist mit der Genetik? Dort ist das "100-fache" unerreichbar. Nun, wenn es 20-30 Mal ist, oder sogar weniger.
https://www.mql5.com/ru/forum/4927/page114
stringo 2012.02.02 15:50
Bei der Berechnung des genetischen Algorithmus wird die gesamte nächste Generation (64 bis 256 Rechenaufträge) in die Cloud gegeben
Bei einer vollständigen Suche wird ein Stapel von 512 Aufträgen an jeden Cloud-Server gegeben. Wenn eine bestimmte Anzahl von Aufträgen abgeschlossen ist, wird die doppelte Anzahl von Aufträgen hinzugefügt (d.h. wenn ein Cloud-Server 5 abgeschlossene Aufträge meldet, fügt er sofort 10 Aufträge hinzu).
Die Beschleunigung von GA beträgt also nicht 20-30, sondern mindestens das 64-fache, höchstens das 256-fache.
GA kann nicht schneller sein als die Aufzählung einer ähnlichen Anzahl von Parametern. Der Engpass von GA ist das Warten auf den langsamsten Agenten. Und das geschieht (im Durchschnitt) zwischen 10240 / 256 und 10240 / 64 Mal (zwischen 40 und 160 Mal, basierend auf den stringo-Daten). Und es ist der langsamste Agent, der die Geschwindigkeit bestimmt. Außerdem hatte Rosh in dem Artikel 4 eigene lokale Agenten -> die Beschleunigungsgrenze für GA kann 256 / 4 = 64 mal sein (um über vergleichbare Werte zu sprechen), aber im Leben ist es viel weniger.
Wie viele bemerkt haben, erkennen Cloud-Server langsame Agenten automatisch und verteilen "verlangsamte" Pässe an andere Agenten um (sowohl in der vollständigen Aufzählung als auch in der Genetik).
Darüber hinaus werden Agenten mit PR>100 in der Genetik akzeptiert, was die Folgen der Verwendung langsamer Agenten erheblich verringert.
Also, Testbedingungen - 4 Intel Core i5-2500 @ 3,3 GHz, 4GB RAM, Windows XP 64 bit, Terminal x64 bild 581 (PR = 160-180). Während des Tests wurde ein Browser ausgeführt und einen Film ansehen. Die gleichen Bedingungen wie in dem Artikel verwendet wurden (Moving Avarege Expert Advisor, H1, auf OHLC bei 1 m. + Genetik). Einstellungen:
Test auf lokalen Kernen:
Test auf Cloud:
Ohne zu zögern sehen wir, dass die Cloud 8,7 Mal schneller ist. Das ist alles. Aber in Wirklichkeit ist das Netzwerk noch langsamer, weil der Berechnungscache verwendet wurde.
Die lokalen Kerne haben also 8704 - 3666 = 5038 Durchläufe in 30 Min. durchgeführt. 2 sec = 1802 Sekunden -> durchschnittlich 0,3577 Sekunden pro Durchlauf.
Die Cloud führte 8704 - 4455 = 4249 Durchläufe in 3 Min. durch. 28 sec = 208 seconds -> die Wartezeit für einen Durchlauf von Cloud beträgt durchschnittlich 0,049 Sekunden.
Insgesamt hat Cloud die Berechnung um den Faktor 0,3577 / 0,049 = 7,3 mal (!) beschleunigt.
Meine anfänglichen Annahmen, dass die Zahl wahrscheinlich das 20-fache erreichen würde, erwiesen sich als etwas optimistisch. Und wir können nicht einmal von Hunderten sprechen.
Ja, ich habe leistungsstarke Kerne verwendet, d. h. ich habe ein wenig geschummelt. Aber die Tatsache bleibt, dass selbst diese 4249 Durchläufe mit Genetik das Netzwerk in 208 Sekunden und 14040 Durchläufe mit vollständiger Suche in 164 Sekunden schafften (Wartezeit für einen Durchlauf ist 0,0117 Sekunden). Insgesamt ist das genetische Testen eines Durchgangs auf der Cloud im Durchschnitt langsamer als Brute-Force (am Beispiel des fraglichen EA) um 0,049 / 0,0177 = 2,8 Mal.
Ich kritisiere das Netzwerk nicht - sicherlich ist Cloud Network das Beste, was gemacht wurde, seit es Handelssoftware gibt. Und eine sehr notwendige Sache (wenn auch nicht viel genutzt, aber das wird mit der Zeit kommen).
Ich würde mir mehr Korrektheit bei den Werbeslogans wünschen. Okay, Schwamm drüber
Wenn Sie Tests durchführen, bei denen die Zeit für einen Durchlauf weniger als eine Sekunde beträgt, müssen Sie die Netzwerklatenz berücksichtigen, die oft größer oder gleich der Zeit einer "schnellen" Aufgabe ist. Wir haben große Anstrengungen unternommen, um den System-Overhead der Netzwerklatenz durch das Stapeln von Aufgaben zu beseitigen. Und es ist uns gelungen, auch wenn dieses Problem nicht vollständig beseitigt werden kann.
Ihr Beispiel zeigt deutlich, dass Sie in einem kurzfristigen Kampf mit einer Transitzeit gekämpft haben, von der bekannt ist, dass sie geringer ist als die Netzverzögerung. Um die Leistungsfähigkeit von claud wirklich beurteilen zu können, müssen Sie sich von Aufgaben mit Ausführungszeiten von weniger als einer Sekunde weg und hin zu kostspieligeren Aufgaben bewegen.
Ich habe Genetik mit einer ähnlichen Aufgabe, aber mit einer Durchlaufzeit von mehr als 10 Sekunden auf einem i7-Prozessor ausgeführt. Ich werde die Ergebnisse nach Abschluss innerhalb einer Stunde veröffentlichen.
Während 3 min. 28 Sekunden der Netznutzung wurden mir entweder 2 oder 3 Cent berechnet (im Terminal - 3, auf der Website - 2 und 3 eingefroren). Lassen Sie es 3 sein, oder sogar der Einfachheit halber, mit dem Netzwerk für Genetik kostet 1 Cent für eine Minute. Insgesamt kostet eine Stunde 60 Cent, 24 Stunden = 14,4 $. Das klingt für mich sehr teuer. Die Preise sollten mindestens dreimal gesenkt werden, um es für die Verbraucher attraktiv zu machen (viele Leute testen EAs, aber nicht jeder ist in der Lage/willig, etwa 15 $ pro Tag für Cloud zu zahlen, und wenn es 5 $ oder weniger wären - es gäbe mehr Leute, die bereit wären).
Außerdem habe ich bereits für mich selbst herausgefunden, wie man die Kosten für die Optimierung eines jeden EAs im Voraus abschätzen kann (im Durchschnitt, natürlich). Algorithmus für die Genetik (ähnlich wie für die rohe Gewalt):
1) Moving Avarage genetics auf lokalen Kernen laufen lassen (+ man kann auch seine Remote-Agenten anschließen); am Ende die Wartezeit für einen Durchgang berechnen -> T1
2) Berechnen Sie T1 / 0,049 = T2 - wie oft die Optimierung durch Genetik in der Cloud beschleunigt wird.
3) Führen Sie die Optimierung auf den lokalen Kernen (+ Sie können auch Ihre Remote-Agenten anschließen; es sollte wie in Schritt 1 konfiguriert werden) des gewünschten EA aus und warten Sie z.B. 100 Durchläufe ab. Berechnen Sie die Zeit eines Durchlaufs (durch das Protokoll - suchen Sie den ersten und letzten Datensatz) -> T3
4) 10240 * T3 / T2 = T4 -> geschätzte Testzeit in Cloud.
5) T4 / 60 = Testkosten in Cents.
(Sie können auch Ihre Kerne berücksichtigen, dafür verwenden wir T2' = T2 + 1).
Dies alles ist eine Schätzung auf der Grundlage der Moving Avarage-Optimierung. Vielleicht kommen in ein oder zwei Monaten leistungsfähigere Kerne ans Netz und die Zahlen werden sich ändern, ebenso wie die Kosten.
Ich denke, mein Gedankengang ist klar
Ihr Beispiel zeigt deutlich, dass Sie in einem kurzfristigen Kampf mit einer Durchlaufzeit konkurrierten, die bekanntermaßen geringer ist als die Netzverzögerung.
Ja, das habe ich vermutet, aber nicht in Betracht gezogen. Warten wir also auf Ihre Ergebnisse.
Und mein vorheriger Beitrag, Abs. 2 wird nach Ihren Tests korrigiert werden müssen.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Schnellere Berechnungen mit dem MQL5 Cloud Network :
Wie viele Kerne hat Ihr Computer zu Hause? Wie viele Computer können Sie zur Optimierung einer Handelsstrategie nutzen? Hier zeigen wir Ihnen, wie Sie das MQL5 Cloud Network nutzen können, um Berechnungen zu beschleunigen, indem Sie mit einem einzigen Mausklick Zugriff auf Rechenleistung aus aller Welt erhalten. Die Phrase "Zeit ist Geld" wird von Jahr zu Jahr relevanter und wir können es uns nicht leisten, etliche Stunden oder Tage auf wichtige Berechnungen zu warten.
Autor: MetaQuotes Software Corp.