dertrader schrieb:
An was für Aufgaben und Software denkst du dabei?Perfect Trader schrieb:
[...]
warum für manche Aufgaben vielleicht die eine oder andere Open Source Software doch weit besser tut als manches proprietäre Produkt.[...]
Da PT jetzt hoffentlich endlich ins Bett gegangen ist - ich hab ihn hier heute morgen um 4 Uhr noch rumgeistern sehen als ich von meiner nächtlichen Youtube-Umbra-Et-Imago-Ich-denk-an-meine-wilde-Jugend--Session nochmal kurz vorbeigeschaut habe -, werde ich mal versuchen, ob ich trotz Tinnitus eine relativ sinnvolle Antwort hinbekomme:
Man kann grob zwischen leicht "parallelisierbaren" Rechenaufgaben unterscheiden und solchen, die nicht ganz trivial sind. Und wie so oft im Leben bleibt dann ein Rest übrig. Das sind Probleme, die mit der aktuellen Hard- und Software nicht lösbar sind oder wo man den Witz mit der Langspielplatte adaptieren könnte: "In Ihrem hohen Alter sollten Sie solche langlaufenden Prozesse besser nicht mehr starten". Oder es wächst einem "nur" über den Kopf, und man hat nach X gescheiterten Lösungsversuchen keinen Bock mehr, was ja nicht zwangläufig heißt, dass das Problem nicht lösbar ist, sondern nur, dass man selbst keine Lösung gefunden hat.
Fall1: Was ist "relativ leicht" paralellelisierbar ?
Es gibt Probleme wie bspw. das systematische Untersuchen von Eingangsvariablen (unterschiedlichste Kombinationen von Stopp und Takeprofit, Haltedauern/Timestopp etc. pp.) von Handelssystemen. Je feiner man rastert (z.B. 0.1 Abstände zwischen verschiedenen Stoppwerten statt 1er Abstände) und/oder je mehr Eingangsvariablen man betrachtet, umso aufgeblähter wird das Problem.
Kleines Beispiel:
2 Eingangsvariablen: SL und TP
Variante 1:
SL läuft von 10 % in 10er Schritten bis 50 %: 10,20,30,40,50 (5)
TP läuft von 5 % in 5er Schritten bis 30 %: 5,10,15,20,25,30 (6)
Will man alle Kombinationen durchtesten, muss man die Funktion/das Programm/das Handelssystem 5*6 m= 30 mal mit einer der möglichen Kombinationen laufen lassen.
Nun kann man sich vorstellen, was passiert, wenn man statt 10er (bzw. 5er) Schrittweiten eine feinere Auflösung wünscht.
Variante 2: Statt +10 rechnet man z.B. +0.1.
Dadurch ergeben sich entsprechend mehr Kombinationen. Irgendwelche Heuristiken, die man noch anwenden könnte, weil man bestimmte Kombinationen wegen Unsinnigkeit filtern könnte oder sonst was lass ich mal außen vor.
In der Grundproblematik macht man also X-mal dasselbe, nur mit einer anderen Konfiguration (die spezielle Eingangsparameter-Kombination). Da das Ergebnis eines Durchlaufs keine Einflüsse/Abhängigkeiten von einem beliebigen anderen Durchlauf hat/haben sollte, kann man diese Problematik gut parallelisieren. "Teile und herrsche" ist hier die Devise.
Man zerlegt im einfachsten Fall die Liste der Kombinationen in soviele Teile, wie man Rechensklaven hat. Dadurch ist die Liste mit durchzusimulierenden Kombinationen viel kürzer und man ist entsprechend schneller fertig. Man kann z.B. primitiv dem (Teilproblem)Programm eine spezielle Datei mit auf den Weg geben, wenn man es startet, in der alle zu durchlaufenden Kombinationen stehen.
Sind alle Rechenknechte mit ihrer Arbeit fertig, sammelt man die Ergebnisse (z.B. wiederum in Dateien geschrieben) ein, fügt sie zusammen und tut dann so, als hätte ein Prozess am Stück alles gemacht. Sowas lässt sich in der Regel auch recht gut programmieren.
Wo drängt sich das zwangsläufig auf? Wenn man nur eine begrenzte Zeit hat, die beste Lösung zu finden. Z.B. will man auf den Vortagesdaten plus anderen Daten was ausrechnen, hat aber nur die Nacht über Zeit, da man 8 Uhr morgens die Ergebnisse braucht. Auf einem Prozessor benötigt man aber dafür 6 Tage. Dann MUSS man teilen, sonst kann man das Ergebnis auch instant löschen. In anderen, weniger zeitkritischen Fällen kann man das Ganze natürlich auch aussitzen und rechnet nur auf einem Prozessor/Rechner/... Man muss nicht immer alles hochtunen, nur weil es theoretisch geht, meiner Meinung nach.
Fall 2: Das Problem ist nicht trivial:
Man will z.B. irgendwas Raffiniertes optimieren und das Ergebnis von Schritt 1 wird benötigt, um Schritt 2 zu machen. Es macht in dem Fall wenig Sinn, das Problem aufzuteilen und Schritt 2 GLEICHZEITIG zu Schritt 1 starten zu lassen. Schritt 2 weiß ja noch nicht, was bei 1 rauskam. Man muss nun entweder das Programm in Schritt 2 so programmieren, dass es trotzdem schon mal was tun kann und man abschließend das Ergebnis von Schritt 1 und Schritt 2-Teil1 durch eine simple Gleichung zu Schritt 2-Teil 2 und somit zum Gesamtergebnis zusammenführen kann oder oder oder... hier ist Kreativität gefragt. Das meine ich mit "Nichttrivial".
Ziel bei der Parallelisierung ist daher oft: Datenmengen zerhacken, Kommunikation zerhacken, Ressourcennutzungen beachten (gemeinsam genutzte Dateien usw.), Probleme so in Teilprobleme zerlegen, dass sie möglichst nicht voneinander abhängig sind und dann diese Teilprobleme den einzelnen Prozessoren unterschieben.
Fall 3:
Richtig eklig sind eigentlich nur Probleme wie z.B. Virtuelle Welt-Simulationen, die sich nicht so gut zerlegen lassen, da man ja davon ausgeht, dass das Ganze mehr ist als die Summe der Teile (wie es bei den einfacheren Problemen der Fall ist). Meine heimische Zuckerwelt, die ich mir in Mathematica programmiert habe, läuft recht zügig bei 50 mal 50 Zellen. Aber wenn ich das ganze doch etwas realistischer haben will und auf 500000 mal 500000 gehe, die Welt entsprechend mit Akteuren fülle, dann reißt mein heimischer Rechner irgendwann die Hufe hoch. Solche Größenordnungen zu zerhacken geht sicherlich auch irgendwie, aber das ist dann sportlich. Vielleicht geh ich das mal an, die Amazon Cloud scheint ja da doch recht komfortabel zu sein (Danke PT für Deine Bemühungen an der Stelle
).Ein anderes Beispiel wäre: Fahrplansimulation bei der Deutschen Bahn (in dem Zusammenhang lernt man dann auch schönen neue Worte wie "Zugteilbelegungszeit"), wo man auch zusätzliche Heuristiken einfließen lassen muss, um sowas noch sinnvoll zu zerlegen, denn man will ja eigentlich schon, dass der ICE von Hamburg nach München auf halber Strecke für 4 Stunden hält, weil leider da der Programmierer das Problem, 35000 Züge zu koordinieren zerhackt hatte und die Ergebnisse der Teiloptimierungen nicht so ganz matchen *hust*.
Aber im Tradingbereich sind meiner Meinung nach die auftretenden Probleme in der Mehrheit recht gut zerlegbar. Da ich mir die Amazon-Cloud noch nicht so im Detail angeschaut habe, kann ich nur vermuten, dass man eigentlich ca. alles verwenden könnte. Ich weiß, dass es gut mit R klappt (zumindest hab ich R schon auf Clustern verwendet), vermutlich sind aber kompilierte C-Programme, Dot-Net-Assemblies, verschiedene Metatrader-Instanzen, auch das von mir nach wie vor ungeliebte Python (ich bin nun mal verwöhnt) denkbar, weil Amazon ja dem Kunden eigentlich eine angenehme Lösung anbieten will. Ich glaube, die haben in ihrer gesamten Servicesparte mittlerweile bessere Margen als mit dem Warenverkauf- und versand. Das kommt ja nicht von ungefähr.
@sayula:
Ich kenn es so, dass man zu Beginn seinen ganzen Kram (Programm, Daten) auf das Cluster schiebt oder halt nun in die Cloud, dann startet man es, kann den eigenen Rechner und das I-Net auch abschalten und die einzelnen Programme rödeln gemütlich vor sich hin. Wenn sie länger laufen, schaut man gelegentlich mal nach, indem man sich "Remote" einloggt, was aber auch cooler klingt als es ist (ich vermute mal, Amazon hat dafür auch ne schnuffelige Web-Application) und tscha, irgendwann ist es fertig, dann downloaded man sich die Ergebnisse wieder auf den heimischen Rechner.
Stell es Dir so vor: Du legst Deiner Sekretärin einen Berg Akten auf den Tisch (oder dem gesamten Team), befiehlst ihnen, zu arbeiten, gehst einen Kaffee trinken und ne Runde Golf spielen und kommst zurück, holst Dir die Ergebnisse ab und das war's. Eventuell installierst Du noch nen Email/SMS-Service a la "Chef, wir sind fertig."
, mit mattem Display. Das ist sehr leise, aber hat halt nicht viel Leistung. Bin damit auch zufrieden.
aber es ist fast nichts anderes auf dem Markt, daher kann das nicht das Kriterium sein 
