Ich brauche Hilfe! Ich kann das Problem nicht lösen, ich stoße an die Grenzen der Hardware - Seite 19
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
Sie müssten also mehrere Millionen Angebote aus anderen Sequenzen durchgehen! Das ist genau das, was ich meine.
Nun, ich spreche von der Überprüfung einer einzigen Zahl (Sequenznummer), eine Million ist nicht so viel für eine so elementare Operation. Wenn wir das Kriterium rekursiv zählen, ist es nur ein Durchgang durch die Datei, und wir müssen es sowieso tun. Außerdem ist zu bedenken, dass die Rekursionsdatenkarte mehrere Millionen Elemente enthält (multipliziert mit der Anzahl der Parameter für eine Sequenz).
Eine weitere Alternative besteht darin, die Kriterien vor der Sortierung vollständig neu zu berechnen und zu speichern. Auch hier ist die Möglichkeit der Verwendung von Rekursionen entscheidend.
Es ist klar, dass es auf jeden Fall viele Operationen geben wird, aber ist es in der Originalversion weniger?
In C++ können Sie dies ohne Parser tun, wenn:
Wenn man die Idee 10-mal wiederholt, kann man eine weitere Datei mit den Startwerten der Sequenzpositionen in einer anderen Datei anlegen, dann braucht man nicht einmal die Anzahl der Trades in der Sequenzstruktur zu speichern.
Sie erhalten einen gewöhnlichen Index, der bereits zuvor erwähnt wurde.
Ich habe den oben beschriebenen Algorithmus implementiert.
Die Verarbeitung meiner Daten mit X = 20 (Kriteriumsberechnung bei 20 Geschäften) dauerte etwa112 Minuten (habe es nicht genau erfasst), der Löwenanteil wurde von Array Shift aufgefressen (40% laut Profiler).
Nach Schleifen von Arrays und einigen anderen Optimierungen wurde die Verarbeitung schneller:
Der Speicher reichte nur für 65 Transaktionen (multipliziert mit einer Million Sequenzen). Das ist natürlich nicht genug - ich hatte mit mindestens 100 gerechnet.
Der nächste Schritt bestand darin, alle überflüssigen Informationen zu den Geschäften zu streichen. Verlassen nur Öffnungs-und Schlusszeiten, und Gewinn in Pips, gelang es, mit X = 185 abheben.
Weiter - nur beschleunigen die Arbeit mit der Datei, FileReadXXX nimmt jetzt 30% der Zeit (und der Dispatcher sagt, es gibt keine Arbeit mit der Festplatte, aber die CPU ist geladen).
FileRead ist genau der erste nach FileSeek, d.h. sequentielles Lesen funktioniert schnell.
Ich werde Sie über neue Ergebnisse unterrichten.
In C++ wird dies durch fread in einem 64K-128K Puffer erledigt, wobei das Parsen besser durch einen eigenen Parser erfolgt, da sscanf-es sehr langsam sind.
Ich werde versuchen, mit den Dateien über WinAPI zu arbeiten, wie mir vom Service-Desk empfohlen wurde:
Ich schiebe die Idee 10-mal - eine andere Datei mit den Werten der Anfangspositionen der Sequenzen in einer anderen Datei zu machen, dann in der Struktur der Sequenz wird nicht einmal brauchen, um die Zahl der Geschäfte zu speichern.
Ich verstehe nicht, was der Index bewirken soll.
Das Aufschreiben der Anzahl der Gewerke macht keinen Unterschied, das sequentielle Lesen funktioniert schnell, das Problem ist das genaue Lesen des Blocks nach der Bewegung in der Datei.
Bitte schreiben Sie einen Algorithmusvorschlag.
Das Problem ist nicht trivial, aber es gibt noch nicht eine einzige Zeile Code. Andrey, viele Leute hier sind interessiert - formulieren Sie das Problem und bieten Sie Testdaten an. Lassen Sie uns ein Sportprogramm organisieren.
Wir brauchen Testdaten + Pseudocode, mit allgemeinen Grundsätzen der Arbeit mit Daten.
Die Aufgabe wird von Anfang bis Ende formuliert.
Und die Testdaten können mit einem leicht geänderten Skript generiert werden, das ich bereits veröffentlicht habe.
Ich werde es etwas später tun.
Warum sollte man die Optionen von der Basis aus durchgehen? Wäre es besser, den Handel nach den Kriterien in der Vergangenheit zu generieren? Nein? Wäre das nicht dasselbe wie das, was verlangt wird?
Wenn für Tests, natürlich, ja, aber wenn für die Lösung des Problems, natürlich, nein )
Kandidat:
Nun, wir reden hier über die Überprüfung einer einzigen Zahl (Sequenznummer), eine Million ist nicht viel für eine so elementare Operation. Wenn wir das Kriterium rekursiv betrachten, ist es nur ein Durchgang der Datei, wir müssen es sowieso tun. Zu bedenken ist auch, dass die Rekursionsdatenkarte mehrere Millionen Elemente enthalten wird (multipliziert mit der Anzahl der Parameter für eine Sequenz).
Eine weitere Alternative besteht darin, die Kriterienvor der Sortierung vollständig neu zu berechnen und zu speichern. Auch hier ist die Möglichkeit der Verwendung von Rekursionen entscheidend.
Es ist klar, dass es auf jeden Fall viele Operationen geben wird, aber ist es in der Originalversion weniger?
In der ersten Variante können Sie das Kriterium einmalig bei der Suche nach der letzten Transaktion aus der Durchlaufhistorie berechnen.
Und Sie müssen ein solches Fragment der Datei lesen, dass es X Anzahl von Geschäften aller Sequenzen enthalten würde. Sie wird viel größer sein als X *Anzahl der Sequenzen, weil es unterschiedlich viele Angebote gibt und diese nicht gleichmäßig verteilt sein können.
2 alle:
Jedenfalls danke ich für die Unterstützung.
Wenn Sie nichts dagegen haben, führen Sie bitte das Testskript aus und teilen Sie die Ergebnisse mit.
Und die Testdaten können mit dem leicht geänderten Skript erzeugt werden, das ich zuvor veröffentlicht habe.
Ich füge das aktualisierte Skript bei, jetzt zeichnet es nicht mehr nur identische Trades auf, sondern generiert zufällige Sequenzen mit bestimmten Einstellungen(Laufzeit - von und bis, Gewinn - von und bis).
Um eine Datei zu erhalten, die mit meiner vergleichbar ist, führen Sie das Skript mit den Standardeinstellungen aus:
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 140.000 Sek. abgeschrieben in 57.1 Se k.
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 6632 Mb geladen in 44.0 sec(150.7 MB/sec)
Danach können Sie den Algorithmus ausarbeiten.
Wer zu faul ist, kann die Datei auf Google Drive archivieren.
komposter:
1. In der ursprünglichen Variante können Sie das Kriterium einmal berechnen, wenn Sie das letzte Geschäft aus der vergangenen Historie finden.
In Ihrer Variante müssen Sie ein solches Stück Datei lesen, dass es X Angebote aller Sequenzen enthalten würde. Sie wird viel größer sein als X *Anzahl der Sequenzen, da die Anzahl der Geschäfte unterschiedlich ist und sie möglicherweise nicht gleichmäßig verteilt sind.
1 Das ist nicht ganz klar, wenn wir nach dem maximalen (minimalen) Kriterium suchen, müssen wir am Ende immer noch für alle Kandidaten ein Kriterium berechnen. Dabei spielt es keine Rolle, ob es sich um ein lokales oder ein globales Extremum handelt.
2. Vielmehr stellt sich die Frage, ob die Größe des benötigten Speichers akzeptabel ist oder nicht. Außerdem ist eine größere Blockgröße im Hinblick auf die Lesegeschwindigkeit der Festplatte noch besser. Das ist sicherlich noch kein Problem für den Arbeitsspeicher. Es ist von grundlegender Bedeutung, dass die Lektüre der Reihe nach erfolgt und nur einmal stattfindet.
Die Variante, die Kriterien vor der Sortierung zu berechnen, erfordert jedoch ein doppeltes Lesen. Es hat aber auch seine Vorteile, insbesondere wenn man die Möglichkeit in Betracht zieht, die Daten in mehrere kleinere Dateien aufzuteilen und sie anschließend gemeinsam zu bearbeiten.
Ohne Umsetzung würden jedoch alle Argumente abstrakt bleiben. An diesem Punkt der Diskussion werde ich mich also verabschieden müssen :)
Wie man Dateien zusammenfügt und dabei feststellt, welches Bit der Anfang und das Ende der Datei ist.
Erstellen Sie z. B. 1000 Metadateien aus 1000 Dateien, und wenn die Kriterien bekannt sind, erstellen Sie eine statistische Ordnung, um ähnliche Dateien in eine Metadatei einzupassen.
Experimentieren Sie lieber mit FileOpen, wie es schneller geht, eine große oder eine kleine Datei zu öffnen, im Sinne von 1000 Mal eine große Datei öffnen, die genauso groß ist wie 1000 kleine, oder 1000000 Mal eine kleine Datei öffnen?
Es kann sich herausstellen, dass die Dateien nicht zusammengeführt, sondern aufgeteilt werden sollten.
Wie man Dateien zusammenfügt und dabei feststellt, welches Bit der Anfang und das Ende der Datei ist.
Erstellen Sie z. B. 1000 Metadateien aus 1000 Dateien, und wenn die Kriterien bekannt sind, erstellen Sie eine statistische Ordnung, um ähnliche Dateien in eine Metadatei einzupassen.
Experimentieren Sie lieber mit FileOpen, wie es schneller geht, eine große oder eine kleine Datei zu öffnen, im Sinne von 1000 Mal eine große Datei öffnen, die genauso groß ist wie 1000 kleine, oder 1000000 Mal eine kleine Datei öffnen?
Es kann sich herausstellen, dass Dateien nicht zusammengeführt, sondern aufgeteilt werden sollten.
Ich arbeite derzeit mit einer großen Datei, wollte aber zu einer Million kleiner Dateien übergehen.
Erstens können sie angehängt werden, und zweitens kann auf sie über ihren Namen zugegriffen werden (es ist nicht notwendig, "Anfang jeder Sequenz" zu speichern).
Ich habe im Service-Desk nach einer Million Öffnungen verschiedener Dateien gefragt (ich habe den Cache auf diese Weise implementiert). Die Antwort ist klar und einfach.
Ich werde die Api-Funktionen sowohl für eine große Datei als auch für Millionen kleiner Dateien testen und die Ergebnisse veröffentlichen.
Ohne Implementierung bleiben jedoch alle Argumente abstrakt. An diesem Punkt der Diskussion wäre es also angebracht, dass ich mich zurückziehe :)
Ich hätte damit anfangen sollen ;)
Aber auf jeden Fall danke für Ihre Teilnahme, auch Ideen ohne Code sind wertvoll.
Mit einer Million Dateien werden Sie ntfs so ruinieren, dass Ihnen die Tränen kommen werden von diesem wahnsinnigen Geistesprodukt von Microsoft, das jeden für immer in seiner wahnsinnig zurückgebliebenen Implementierung des Dateisystems eingesperrt hat.
Alles, was ms in ihren Dateisystemen getan hat, ist ungeheuerlich schwer, verzögert und dumm. Verdammt, diese Idioten haben keine Anstrengungen unternommen, um die Geschwindigkeit zu optimieren, und die API ist einfach primitiv. Im Jahr 2014 kann dies eindeutig festgestellt werden. Brunnen und weinen.
Jeder, der die Effizienz der Handhabung einer Reihe von Dateien in Windows verbessern will, das erste, was sie tun, ist in Chunks gehen - Gruppierung und ihre eigene Datenstruktur innerhalb einer einzigen Datei.
Sobald man anfängt, mehr als tausend (geschweige denn zehn- oder hunderttausend) verschiedene Dateien in Windows zu speichern, ist man aufgeschmissen.
Datei-Operationen in MQL4/5 laufen über unsere sehr effizienten Caching-Mechanismen, die es uns ermöglichen, sehr effiziente und hohe Lese- und Schreibgeschwindigkeiten zu erreichen.
Sie können Daten Byte für Byte streamen - alle Daten werden schnell im internen Puffer gesammelt und nur in großen Stücken auf die Festplatte geschrieben. Die Anzahl der WinAPI-Aufrufe ist minimal, was eine hohe Arbeitsgeschwindigkeit ermöglicht. Beim Lesen verhält es sich ähnlich - es arbeitet proaktiv, liest in großen Blöcken, ruft sehr selten die WinAPI auf und gibt sehr schnell Daten aus seinem Cache mit minimalem Overhead zurück.
Grob gesagt, haben wir im Vergleich zu Build 509 die Geschwindigkeit von Dateioperationen in MQL4/5 um eine Größenordnung erhöht (wenn wir reguläre Chunk-basierte Operationen meinen und nicht "Schreiben von Megabyte-Blöcken zur Maximierung der Geschwindigkeitsmessungen").