Jump to content
Tom Next - Daytrading Community

performante Simulation


Forex1+

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ;)

  • Upvote 3
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Edited by Forex1+
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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

Edited by joshsmi
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 nictation.gif Muss sowieso dann mal schauen ob bei Optimierungen dann die Tickgeschichten nicht zu lahm werden.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...