Fehler, Irrtümer, Fragen - Seite 2285

 
Alexey Navoykov:

Ja, aber der Begriff "schnell" ist in Ihrem Fall sehr relativ. Es ist eine Sache, wenn ein Benutzer ein Array von Balken anfordert - er kopiert einfach einen Bereich des Speichers oder fordert eine bestimmte Zeitreihe an, dann ist es auch ein einfaches Kopieren von Daten mit konstantem Schritt, gleich der Größe der Struktur. Ein weiterer Punkt sind zusätzliche Berechnungen und Umrechnungen für jede Zahl.

Obwohl ich persönlich eine komprimierte Historie bevorzugen würde, um keinen Speicher zu verschwenden, da ich ohnehin meine eigenen Arrays für die Speicherung organisiere. Ich bin also bereit, eine kleine Verzögerung in Kauf zu nehmen. Aber die meisten anderen Benutzer würden Sie dafür in Stücke reißen)

p.s. Obwohl es idealerweise schön wäre, eine solche Option im Terminal zu haben, um die Art der Speicherung des Verlaufs im Speicher zu wählen. Wenn das System z. B. wenig Arbeitsspeicher, aber einen schnellen Prozessor hat, wäre das sehr nützlich.

Nun, sehen Sie. Ich habe gerade die Schreib- und Lesegeschwindigkeiten auf meiner SDD gemessen. Es stellte sich heraus, dass die Schreib- und Lesezeit von 8 Bytes (1 Werttyp double oder datetime oder long) ~ 48 ns beträgt. Und nach meinen Berechnungen beträgt die Lesezeit für 8 Byte Informationen aus einem gepackten Array 1-2 ns. Während wir also 1-2 ns beim Zugriff auf ein Strukturelement verlieren, gewinnen wir 48*0,8 = 38 ns beim Schreiben und Lesen von der Festplatte. Außerdem sparen wir 5-fachen RAM- und Festplattenspeicher, von der HDD ganz zu schweigen.

 
Nikolai Semko:

Nun, sehen Sie. Ich habe gerade die Lese- und Schreibgeschwindigkeit auf meiner SDD gemessen. Es stellt sich heraus, dass die Schreib- und Lesezeit von 8 Bytes (1 Werttyp double oder datetime oder long) ~ 48 ns beträgt. Und nach meinen Berechnungen beträgt die Lesezeit für 8 Byte Informationen aus einem gepackten Array 1-2 ns. Während wir also 1-2 ns beim Zugriff auf ein Strukturelement verlieren, gewinnen wir 48*0,8 = 38 ns beim Schreiben und Lesen von der Festplatte. Außerdem sparen wir das Fünffache an Arbeitsspeicher und Festplattenplatz - von der Festplatte ganz zu schweigen.

Ich bestreite das nicht. Wenn es speziell um das Herunterladen von Daten von der Festplatte geht, haben Sie sicherlich Recht. Vor 4 Jahren hatten wir eine Diskussion mit Renat zu diesem Thema, zu der Zeit, als SSD noch recht unüblich war und die große Mehrheit der Benutzer auf langsamen HDD saß.Also habe ich (am Beispiel meiner SSD) versucht, ihn davon zu überzeugen, dass der Betrieb der Festplatte das langsamste Glied im System ist und wir versuchen sollten, die von ihr verbrauchte Datenmenge zu minimieren, nicht umgekehrt. Aber er hatte solche Argumente: keine Notwendigkeit, die CPU mit zusätzlicher Arbeit zu überlasten, und ihr seid alle Dummköpfe, versteht nichts usw. Im Allgemeinen, alles wie immer )

Es stimmt, dass SSD heutzutage erheblich beschleunigt werden.

Es stellt sich heraus, dass die Schreib- und Lesezeit 8 Bytes beträgt

Aber warum sollte das Schreiben zusammen mit dem Lesen gemessen werden? Daten sollten einmal geschrieben werden, wenn sie vom Server empfangen werden, oder wenn ein Cache angelegt wird. Und dann nur lesen. Also Koteletts separat, Fliegen separat.
 

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Wanzen, Wanzen, Fragen

fxsaber, 2018.09.10 21:28

Erstens: das Optimierungsprotokoll.

Tester  optimization finished, total passes 714240
Statistics      optimization done in 7 hours 31 minutes 06 seconds
Statistics      local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
Core 1  connection closed
Core 2  connection closed
Core 3  connection closed
Core 4  connection closed
Core 5  connection closed
Core 6  connection closed
Core 7  connection closed
Core 8  connection closed
Tester  714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'

Während dieser 7,5 Stunden wurde sehr häufig auf die SSD zugegriffen. Wenn die Ticks bei jedem Durchlauf gelesen wurden, ergibt das einen Durchschnitt von 26 Mal pro Sekunde für 7,5 Stunden. Daher ein so wildes Geblinke - mehr als 700 Tausend Lesungen.


Protokoll eines einzelnen Laufs

Core 1  FILTER_EURUSD.rann_RannForex,M1: 132843 ticks, 60283 bars generated. Environment synchronized in 0:00:00.140. Test passed in 0:00:00.827 (including ticks preprocessing 0:00:00.109).
Core 1  FILTER_EURUSD.rann_RannForex,M1: total time from login to stop testing 0:00:00.967 (including 0:00:00.140 for history data synchronization)
Core 1  322 Mb memory used including 36 Mb of history data, 64 Mb of tick data

Wie man sieht, werden ~130K Ticks und 60K Balken verwendet (der Modus "All history" ist im Tester ausgewählt). D.h. ein sehr kleiner Teil der Geschichte.

Die Historie des benutzerdefinierten Symbols im Terminal enthält die folgende Menge an Historiendaten

Saved ticks = 133331
Generated Rates = 60609

D.h. in der Geschichte des Symbols ist sehr wenig mehr als das, was Tester verwendet.


ZS Es ist eine Schande, sich die SSD anzusehen... Wie viel schneller könnte der Optimise sein? Seltsam, dass das Betriebssystem diese Daten nicht zwischenspeichert, da es sich um weniger als 7 MB an Ticks in unkomprimierter Form handelt.


Welcher Ordner von Terminal über mklink auf RAM-Disk, so dass die Daten nicht von SSD, sondern aus dem Speicher gelesen/geschrieben werden? Ich bin bereit, die Daten zur Verfügung zu stellen, welche Art von Geschwindigkeitssteigerung dies bei der Optimierung bewirken würde.

 
Nikolai Semko:

Ja, dies ist eine Archivierung. Wenn ich es richtig verstehe, werden jetzt Ticks und Minutenbalken unverpackt gespeichert, d. h. für einen Balken(MqlRates-Struktur) sind es 60 Byte und für einen Tick(MqlTick-Struktur) 52 Byte.
Es ist furchtbar! Dagegen muss schon lange etwas unternommen werden.

Ich verstehe, dass das Hauptproblem bei komprimierten Arrays die Organisation des schnellen Zugriffs auf jedes Arrayelement ist.

Aber selbst wenn wir nur jedes 256. Element eines Arrays ungepackt speichern und in den anderen Elementen nur Inkremente zu den ungepackten speichern, können wir sehen, dass die Array-Größe 4-5 mal kleiner sein wird und die Zugriffszeit auf jedes Element nicht zu sehr zunimmt (vielleicht 1-2 Nanosekunden), aber es wird enorme Zeit beim Speichern und Lesen des Arrays von der Festplatte und auf die Festplatte sparen.

"Alles ist schon vor dir gestohlen worden" (cz)

Zu Beginn des Tages ist es ein volles Häkchen. Dann Bid und/oder Ask und/oder Flipper Full, alles andere in Inkrementen, falls verfügbar. Durchschnittlich 10 Bytes pro Tick.

Da der Zugriff auf Ticks streng sequentiell erfolgt, ist es kein Problem, einen schnellen Zugriff auf jedes Element des Arrays zu arrangieren

 

Eine große Bitte, die Quelle des Eintrags "Tester\cache\*.opt" zu veröffentlichen. Wie Sie aus dem Inhalt ersehen können, ist das Format sehr einfach.

Die Arbeit mit den Ergebnissen der Optimierung ist sehr wichtig. Ich danke Ihnen!

 

Aus irgendeinem Grund sinkt die Leistung des Testers mit zunehmender Anzahl von Geschäften. Es gibt keinen Hinweis auf die Handelshistorie seitens des Expert Advisors.

Dies scheint nicht der Fall zu sein.

 

Im Tester wird das Intervall gespeichert, das dem Modus "Gesamter Verlauf" entspricht. Wenn ich dem benutzerdefinierten Symbol einen Verlauf hinzufüge und das Terminal neu lade, bleibt das Intervall für den "gesamten Verlauf" unverändert.

Ich kann den Standardmodus nicht ändern, aber wenn ich den gesamten Verlauf auswähle, kann ich den gesamten Verlauf manuell einstellen. Bitte korrigieren.

 

Es fehlt ein Kreuz an der markierten Stelle - die entsprechende Zeile des Cache-Eintrags wird gelöscht.

Ich nehme viele Optimierungen vor. Einige sind schon seit langem veraltet. Und es gibt keinen Mechanismus, um diese Optionen zu löschen. Manchmal bekommt man eine riesige Liste und fängt an, unter unnötigen Varianten zu suchen.

Bitte entfernen Sie daher überflüssige Daten durch Ankreuzen an der im Bild markierten Stelle.

 
A100:
Fehler bei der Ausführung

Ergebnis: wahr:falsch:7:4

Wie kommt es, dass unterschiedlich lange Saiten plötzlich gleich lang sind? Während der Vergleich mit StringCompare das gegenteilige == Ergebnis liefert

Vielen Dank für den Beitrag, wir haben das Verhalten der Zeichen für Zeichen Zeichenfolge Vergleich geändert.

Bisher wurden Strings als Z-String (bis zum Nullzeichen) verglichen, jetzt werden sie als PASCAL-String (unter Berücksichtigung der Länge) verglichen.

Bestehende Codes mit "normalen" Zeichenketten (ohne Z-Zeichen darin) sind von dieser Änderung nicht betroffen.

 
Ein großer Wunsch des Testers ist es, mit Bid/Ask zu schließen, wenn der letzte bekannte Wert Null ist.