Hallo,

 

ist jemanden in etwa bekannt wie die schnellen Plattformen wie z.B. Amibroker beim Backtest die Historydaten von der Platte dem System bereitstellen? Entgegen zu EOD Tests ist es bei Tick/M1 nicht wirklich möglich den kompletten Datensatz in den Ram vorzuladen (kann mehrere GB groß sein), daher würde mich mal interessieren wie der Datenbezug von der Platte in die Systemlogik dennoch performant von statten gehen kann?

 

Viele Grüße

Ich kenne es nur von MT4, da wird für die Ticksimulation eine große Datei erzeugt die dann vermutlich durchgeschleift wird. MT4 ist aber sicher nicht so das beste Beispiel für sowas. Eine DB auf einer SSD durchzuschleifen ist sicher schon nicht schlecht aber vom Ram ist eben doch noch was anderes.

Ich stell ehrlicherweise das "Tickdaten gehen sich im Ram nicht aus" infrage:

Effizient gespeichert hat ein Tick ja nur tstamp (4Byte?) und Wert (reichen sicher auch 4Byte), ggf. noch aktuellen Spread (2Byte?).

Sprich 10 Byte pro Tick. Hab leider nur MT Daten zur Verfügung, aber es sieht aus als hätte man 40MB pro Monat: effizient gespeichert hast bissl über 2 Jahre an Tickdaten in 1 GB.

Mit 8GB Ram und Standardsystem (konkret: mein standardsystem Win10) hab ich gerade 5GB Ram frei -> also bis zu 10 Jahre Tickdaten gehen sich leicht aus, wenn man bedenkt das ich grad fast bei jedem Schritt Buffer eingebaut hab. Und selbst wenn du 20 Byte pro Tick brauchst, hast noch 5 Jahre. Ein Backtest über mehr als 5 Jahre am Stück klingt eh stark nach überoptimierung...

 

Aber zum Thema: SSD liefert AFAIK ~250MB/s oder mehr -> also effizient gespeichert 25 Mio Ticks. Du müsstest also jeden Tick in durchschn. 0,04 ns abarbeiten. Ein durchschnittlicher PC schafft ein paar Giga FLOPS aber die hast ja nicht alle zur Verfügung. Sprich ich würde vermuten das effizient gespeichert mit SSD die Lesegeschwindigkeit nicht dein Flaschenhals is. Vor allem weil fraglich is wieso dir 4 GB Tickdaten nicht reichen ;)

Je nachdem was das System so als Futter braucht, würden auch noch die OHLC Zeitcharts dazukommen aber dessen Liste ist, je höher der TF, auch viel kleiner als bei den Ticks. Wo es eng wird ist allerdings beim Multithreading wenn gleichzeitig und unabhängig die Daten im Ram bereit gestellt werden müssen. Was du zur SSD schreibst hab ich bisher nicht so betrachtet und find ich gut. Es wäre natürlich optimal gar keine Zwischenschicht zu bilden denn dann kann man sich das Gebastel mit dem Zwischenladen in den RAM sparen und alle Charts direkt aus der DB heraus beziehen. Man müsste es einfach mal testen. Vielleicht machen es die großen Plattformen auch nicht anders als Tabellen von der Platte zu iterieren. Allerdings selbst die Portfoliochecks sind echt schnell und das auch bei HDDs. Das war ja auch der Grund warum ich dachte, dass die ein bestimmten Trick zum durchschleifen nutzen auf den ich noch nicht gekommen bin.

Wenn man sich RAM vs SSD nochmal näher anschaut (Link) muss man schon deutlich feststellen das zwar SSD im Vergleich zu HDD einen großen Sprung gemacht hat aber RAM ist nochmal eine ganz andere Welt. Zugriffszeit Faktor ca 1550, lesen-MB/s Faktor ca 100 im Vergleich zu SSD. Daher würde ich schon sagen der Flaschenhals ist weiterhin die Festplatte/SSD (oder die Systemlogik wenn man damit übertreibt).

Bearbeitet 20. Februar 20179 Jr. von Forex1+

Multithreading seh ich nicht als problem. Wenn die Daten im RAM sind, kannst ja parallel lesend darauf zugreifen ohne Probleme.

Also wenn du 2 Jahre Tickdaten (~1GB) im RAM hast, dazu noch OHLC (inkl. Volume = 6*4Byte ... sagen wir 30) für M1 für 2 Jahre (= ~750K Minuten -> 22.5 MB)... mit 1.5 GB RAM hast Daten für 2 Jahre inkl. beliebigem Overhead.

 

Deswegen: ich glaub nicht das es notwendig ist während dem Test auf die Platte zuzugreifen. Außer du willst 10 Jahre Tickdaten testen...

Auf einem Underlying geht das wirklich gut das stimmt. Mit dem Threading bezog sich auf Portfoliotests wo es dann viele unterschiedliche Quellen gäbe. Aber bis dahin hab ich sowieso noch genug andere Baustellen

Hmm ok, dann wirds sicher eng. Portfoliosystem das auf Tick-daten beruht und 10 Underlyings parallel betrachtet wird eng im RAM...

Aber wenn du solche Systeme baust macht eine entsprechende Maschine Sinn. Da hast dann auch schnell 20 GB RAM frei und du bist wieder save

Entgegen zu EOD Tests ist es bei Tick/M1 nicht wirklich möglich den kompletten Datensatz in den Ram vorzuladen (kann mehrere GB groß sein)

Unsinn. Das einzige Limit ist deine Hardware und dein OS.

 

Du musst 64-bit und nicht 32-bit verwenden! 32-bit Betriebssystem hat eine Grenze von effektiv nutzbarem Arbeitspeicher.

Somit einfache Lösung: 64-bit OS und 64-bit AmiBroker - max. 1 TERABYTE.

Siehe "Adressable memory space"

http://www.amibroker.com/guide/compat.html

Bearbeitet 22. Februar 20179 Jr. von joshsmi

Klar mit genügend teurer Hardware kann man das hinbekommen (was für Singletests, wie Mythos vorgerechnet hat, nicht mal nötig wäre). Mal vom Preis abgesehen müssen die Motherboards das auch erst mal unterstützen.

32bit schafft natürlich Limits und 2038 gibts dann auch noch time-Probleme.

Das Aufrüsten von RAM macht sicher mehr Sinn als komplizierte und langsameren Notlösungen zu basteln auch wenn hier praktische Limits durch Preis oder Motherboard gesetzt sind.

 

Aber für den interessierten User wie mich war die spannende Frage, was machen Amibroker oder Kollegen wenn zu wenig Ram zur Verfügung steht, dass es zum Vorladen nicht reichen kann? Die kommerziellen Plattformen müssen so programmieren, dass es kompatibel mit vielen Computern unterschiedlicher Ausstattung ist.

Die Mindestanforderungen sind z.B. bei Amibroker sehr genügsam mit 128 MB RAM, empfohlen 512 MB RAM. Also kann man davon ausgehen, dass das Programm mit 128 MB noch funktionsfähig wäre. Und man kann davon ausgehen, dass 128 MB für einen Test mit fein skalierten Daten wie Tick oder eben worstcase Portfolio, nicht reicht um es vorzuladen.

Entweder dieser Fall wurde von den Proggern komplett ignoriert und man verlässt sich auf das OS welches den Speicher auf die Festplatte auslagert (pragmatisch aber langsam), oder die Daten werden dann direkt (oder werden sowieso) von der Platte gezogen.

Unsinn. Das einzige Limit ist deine Hardware und dein OS.

 

Du musst 64-bit und nicht 32-bit verwenden! 32-bit Betriebssystem hat eine Grenze von effektiv nutzbarem Arbeitspeicher.

Somit einfache Lösung: 64-bit OS und 64-bit AmiBroker - max. 1 TERABYTE.

Siehe "Adressable memory space"

http://www.amibroker.com/guide/compat.html

 

Wenn du so entspannt postest gleich die direkte Antwort: Zeig mir einen Rechner für Endkunden mit 1 TB RAM. Kannst vermutlich sogar das "Endkunden" streichen: Zeig mir einen Rechner mit 1 TB RAM.

 

Aber für den interessierten User wie mich war die spannende Frage, was machen Amibroker oder Kollegen wenn zu wenig Ram zur Verfügung steht,

 

Ohne es zu testen kann man nur vermuten. Wie du schon sagst ist die einfachste Form für den Programmierer es dem System zu überlassen und ggf. ein "Nicht genug Arbeitsspeicher zur Verfügung" zu melden. Ehrlicherweise kann ich mir gut vorstellen das 90% der Programme diese Lösung umsetzt. Nach dem Motto "Wenn du einen 2 Jahresbacktest auf Tickdaten fahren willst, bau entsprechend RAM ein".

Vorher zu checken wieviel RAM verfügbar ist und entsprechend auf Alternativen umschichten rentiert sich für die meisten Programme vermutlich einfach nicht (Also was jetzt die Kosten-Nutzenrechnung im Entwicklungsaufwand angeht).

Für den Endkunden und Amibroker Fan.....

http://gizmodo.com/5365029/sgis-personal-supercomputer-handles-80-cores-1tb-of-ram

 

Ist von 2009, sollte also schon günstiger zu haben sein....

Ich vermute für den Preis gibts nur die Basisversion sonst wäre es schon fast günstig. Eine Stromflatrate bräuchte man dann noch...

Ich kenn mich jetzt nicht mit Supercomputern aus: läuft auf dem ein Standard-OS? Ich meine rein theoretisch: welche Schritte wären nötig um darauf zB Amibroker laufen zu lassen?

Standard-OS eher nicht:

Octane III supports Microsoft HPC Server 2008, SUSE® Linux® Enterprise Server and Red Hat® Enterprise Linux operating systems. Linux configurations include SGI ProPack™ and ISLE™ cluster management software.

https://www.sgi.com/company_info/newsroom/press_releases/2009/september/octaneIII.html

http://www.designspace.com/staticassets/ANSYS/staticassets/partner/SGI/sgi-octane-III.pdf

Dann besser back to topic ;) Sofern wir keinen Entwickler von Amibroker etc. finden wirds wohl ne offene Frage bleiben :/

Naja, aber wieso schaut denn keiner nach was der Bottleneck beim Backtest ist?

Es wird eigentlich nur ein Bottleneck geben, wenn eben nicht alles in RAM passt. Ausserdem kann der Bottleneck nach der Platte auch alles Mögliche sein, Komplexität des Systems, Effizienz der Datenstrukturen, Kompilersettings, Sprache usw...

Die Frage lief ja darauf hinaus wie programmtechnisch damit umgehen wenn RAM nicht reicht. DB parallel lesend in der Regel kein Problem also keine csv nehmen. Sollte ich an den Punkt kommen wo der Platten-Bottleneck kommt zB bei Portfolioticktest, dann werde ich vermutlich mehrere Varianten testen und einfach Messen welche die schnellste ist. Aber vielleicht hab ich am Ende keine Lust, rüste soviel RAM wie möglich auf und synthetisiere bei dem usecase einfach die Ticks Muss sowieso dann mal schauen ob bei Optimierungen dann die Tickgeschichten nicht zu lahm werden.

Wenn RAM nicht reicht dann wird virtueller Speicher angelegt....

Aber das klingt eben so, als würdest du hier ein Problem lösen wollen welches du gar nicht hast.

Wenn es soweit ist kannst du immernoch schauen wo es klemmt.

 

Alles andere ist doch hier reines Rätselraten?

Wenn RAM nicht reicht dann wird virtueller Speicher angelegt....

Pragmatisch aber ich bin ziemlich sicher das es performantere Lösungen gibt (die natürlich aufwändiger sind)

 

Aber das klingt eben so, als würdest du hier ein Problem lösen wollen welches du gar nicht hast.

Wenn es soweit ist kannst du immernoch schauen wo es klemmt.

Es ist die Frage ob man Tickqualität gegen Performance eintauschen will indem man sie synthetisiert bzw. auf OHLC rechnet. Sobald man viele verschiedenen Tickquellen parallel verarbeitet fängt das Problem an. Da es nur ein Performanceproblem ist, ist es am Ende ein Optimierungsproblem und kein Backtestproblem.

Was Threading angeht denke ich kann man nie früh genug anfangen alles einzuplanen, bevor ich was anpacke checke ich lieber alles im Vorfeld, dauert zwar viel länger aber man muss dann nicht von vorn anfangen weil die Basis nicht stimmt.