Gibt es eine Software, die einen Prozess auf mehrere Kerne verteilen kann? Also ich meine jetzt nicht einem anderen Kern zuweisen, sondern auf mehrere Kerne verteilen.

 

Konkret geht es um MT4 und eine Optimierung. Der lastet bei mir nur einen Kern der 4 Kerne aus, und das nervt mich, da eine umfangreiche Optimierung statt 40h ruhig nur 10h dauern könnte.

 

Ich habe schon gegoogelt, aber nichts gefunden. Schätze, das wird nicht gehen.

 

Also ist es für MT4 eigentlich besser, einen Einkernprozessor zu haben mit 3,9 GHz statt einen 4-Kern mit 4x 2,4 GHz. Na klasse.

Ich habe den schon übertaktet auf ca 3 GHz aber mehr geht leider nicht, ohne dass es instabil wird.

 

Es kennt keiner einen MT4-Mod oder ähnliches? Mit einer dll kann man das auch nicht lösen, oder?

 

Danke!

Da fällt mir nur ein "Divide and conquer": zerlege Dein Problem in Teile (anhand der Parametersteps) und werte die Einzelergebnisse, die Dir 2 MT-Instanzen liefern zu je einem Teilproblem am Ende per Hand aus (Finden der besseren Lösung). Die beiden MT-Instanzen/Prozesse müsste man ja auf die Prozessoren verteilen können, oder ?.

 

Wenn Du eh den gesamten Suchraum abgrast, kannst Du den auch vorab aufteilen und der eine Prozess sucht in der einen Hälfte, der andere Prozess nimmt sich die zweite vor.

Daran habe ich auch schon gedacht, indem man den Suchzeitraum aufteilt.

Aber das spätere Parameterzuordnen - darauf hab ich keine Lust bei 10000 Kombinationen. Weil das Ergebnis ist erst die AUsgangsbasis für weitere Parameter, also die Parameter kann ich auch nicht weiter einschränken, die habe ich schon so weit es geht eingeschränkt.

Na gut, man könnte beide Zeiträume in Exel importieren auf 2 Sheets und per Zellenvergleich der Parameter-Einstellungsspalte die beiden übereinstimmenden Parameterzeilen in ein 4. Sheet kopieren. Aber das ist doch auch ein riesen Aufwand, Profit könnte man ja addieren, aber der Rest...

 

Irgendwo hab ich mal gelesen, dass man per dll solche Sachen steuern könnte? Aber vermutlich nicht für Kernaufteilung :-/

Irgendwo hab ich mal gelesen, dass man per dll solche Sachen steuern könnte? Aber vermutlich nicht für Kernaufteilung :-/

 

Das kann ich mir nicht vorstellen, dann müßte das Programm ja den Prozess "auseinandernehmen" um ihn auf die Kerne aufzuteilen.

 

Also ich mache das bei mir so, dass ich 4 Instanzen zur Optimierung laufen habe und alle Ergebnisse in eine SQL-Datenbank schreibe. Die kann ich dann später bequem über SQL-Befehle auswerten bzw. aufbereiten.

Du müsstest MT selbst neuschreiben... Weil wie willst du im nachhinein eine serielle "Warteschlange" parallelisieren?

 

Einzige Möglichkeit ist echt das aufteilen. Wo liegt da das Problem? sobald du einen Parameter hast der mind. 2 verschiedene Werte annimmt, kannst es ja an dem aufteilen.

Instanz 1 rechnet alles wo Parameter1= x und die anderen halt in den Ranges

Instanz 2 rechnet alles wo Parameter1= y und die anderen in den Ranges

 

Egal was du dann mit den Ergebnissen machst du musst halt vorher die zwei Listen aneinanderhängen (einfach die eine unten an die andere dran, nix kompliziert rumrechnen).

Also nicht den Zeitraum aufteilen, sondern den Parameterraum.

Ah jetzt hab ich es kapiert, danke Mythos

Stimmt eigentlich, wieso bin ich nicht selbst drauf gekommen? Ist die Hitze

 

Das wäre auf jeden Fall eine halbwegs einfache Lösung.

Bei aller Parallelisierung übersehen die meisten Nicht-IT-Leute (und leider auch einige IT-Leute in ihren schwachen Stunden), daß jede unintelligente Bearbeitung eines Problemes mit Brute Force (also reiner Rechenpower ohne zusätzliche Strukturierung oder punktuell raffinierte Ideen) gegen die kombinatorische Explosion (exponentielles oder noch schnelleres Wachstum mit der Problemgröße) grundsätzlich bei nur minimaler Vergrößerung des Problems (geringfügig größerer Auswahlraum, eine Parameter-Dimension mehr etc.) zum totalen Scheitern verurteilt ist.

 

Statt brachialem Brute Force können durch Einsatz von Intelligenz bei der Problem-Zerlegung die meisten Probleme für praktische Zwecke ausreichend gut gelöst werden.

 

Statt eine unermeßliche Zahl von Parameter-Kombinationen kann man den optimalen Bereich einschachteln, indem man mit einem gröberen Raster anfängt und es an den Stellen besseren Outputs verfeinert. Wenn das Problem so strukturiert ist, daß man damit wegen der beliebigen Lage einiger weniger guter Kombinationen die richtigen nicht findet, ist die Suche ohnehin weitgehend sinnlos, da das Problem dann meistens (bei Trading-Problemen sogar immer) nicht stabil in Bezug auf seine Parameter ist.

 

Unabhängig, welche tolle Hardware, System-Software und Backtest-Software man hat: Um einen intelligenten Ansatz sollte man sich von Anfang an nie herummogeln wollen, weil es am Ende eh nur in Sonderfällen ausnahmsweise mal klappt.

Ja, wenn man typische Bereichswerte hat, zB von 1 bis 50 in 1er - Schritten, trifft das zu.

 

Wenn man aber genau diese Bereiche hat und dann noch ein paar Parameter mit nur 1 bis 2 Schritten, die zB eine verschiedene Eröffnungsstrategie beinhalten, ist das schon blöd mit der zufälligen Verteilung, die wird dann noch zufälliger.

 

Beim Brute Force sieht man bei der Optimierungsgrafik auch sehr schön die "Wolken", und erkennt, wo Ausreisser sind.

Das hört sich nach der typischen Komplexitätsfalle beim Verstoß gegen das KISS-Prinzip an.

 

Entweder wird ein System deduktiv aus irgendwelchen bewiesenen Annahmen oder Glaubenssätzen konstruiert oder/und empirisch in mehreren Parameter-Dimensionen optimiert.

 

In beiden Fällen ist überbordende Komplexität sehr schädlich. Im ersten Fall weiß man bei zu vielen Annahmen nicht mehr, wie sich welche Annahme auf das Ergebnis auswirkt, im zweiten Fall erstickt man an der numerischen Explosion.

 

Trotz aller Altväterlichkeit hilft da nur das KISS-Prinzip. Die berühmten 7 Dinge +/-2, die ein Mensch überblicken kann, kann man auch in allen Kombinationen durchrechnen. Ein Computer-Schmankerl sind dann vielleich 2 oder 3 Dinge mehr oder einige Werte mehr als eine binäre Belegung in einigen Dimensionen. Bei vielmehr hilft auch kein Computer gegen die exponentiell wachsende Dimensions-Kombination.

 

Die Parameter-Dimensionen müssen aber bestimmt nicht zwingend in allen denkbaren Kombinationen getestet werden. Es gibt bestimmt Haupteinfluß-Faktoren, die man für weitere Teilberechnungen fest setzen kann.

Das hört sich nach der typischen Komplexitätsfalle beim Verstoß gegen das KISS-Prinzip an.

...

In beiden Fällen ist überbordende Komplexität sehr schädlich. Im ersten Fall weiß man bei zu vielen Annahmen nicht mehr, wie sich welche Annahme auf das Ergebnis auswirkt, im zweiten Fall erstickt man an der numerischen Explosion.

 

Na ja, dazu muss ich aber abmildernd sagen, dass Henrik sich als ambitionierter Endanwender schon sehr wacker schlägt und zum Teil Erfahrungen per Trial & Error machen muss, da er auf kein Vorwissen durch ein für solche Tätigkeiten relevantes Studium/Ausbildung/Arbeit zurückgreifen kann (wenn ich das richtig verstanden habe, Henrik ?! ;))

Da gerade Henriks Motive einer Mehrkernoptimierung moniert wurde mal was zum lesen damit Ihr ihn/uns besser versteht.

 

Meine Systeme haben verschiedene Grundsteine.

- --------------------------- Sytem

- Systemidee

- Markt

- Zeiten

- Entry

- Exit

- Optimierungsparameter

- --------------------------- Sicherheit

- Exitzusatz

- NotSL

- MM

- --------------------------- Automatisierung

- Optimierungsmodul

- Filter (z.B.Newsfilter)

 

Henrik und ich traden ja bereits live mit unserem neuen System (beim DAX) und sind gerade dabei die Sicherheitsmodule einzubauen.

Diese 3 Punkte im Sicherheitsmodul hängen stark miteinander zusammen und können nicht unabhängig von einander betrachtet werden. Besonders da wir gerade 2 Grund-Exitzusätze (also nicht Parameter) haben und den „besseren“ herausbekommen wollen.

Diese höhere Notwendigkeit an Optimierung dient nur der Entscheidungshilfe welches der Exitzusätze wir nehmen wollen.

Im laufenden Betrieb werden ganz andere Parameter optimiert (Optimierungsparameter).

Die Sicherheitsmodule sollen Verluste zwar minimal halten aber für einen relativ geringen Preis. Es soll nicht allzu viel Gewinne weggefiltert werden. Entsprechend müssen „schlechte“ und „gute“ Parameter vom System durchgetestet werden und das jeweils mit den verschiedenen Exitzusätze.

 

Da ich mich hier noch mit einem XP1800 rumschlage und der Henrik eindeutig den besseren PC hat übernimmt er die ganzen Optimierungen incl. der Auswertungen und das kann er gut.

 

Ich glaube nicht an KISS. Ein KISS kann man bei einfachen Systemen anwenden die IMHO wegen der fehlenden Sicherheit nicht funktionieren können. Spätestens beim einbauen mehrerer Exits und das anfügen von Sicherheitsmodulen und dessen Komplexität besonders in der Entwicklung dieser ist es kein KISS System mehr. Da sind wir aber noch nicht mal bei dem Automatisierungsmodul angelangt der dem User die späteren täglichen bzw. wöchentliche Optimierung abnehmen und (bei mir zumindest) ehr auf Sicherheit als auf Performance gefiltert handeln soll. MT4-Optimierung hat diese Funktion bei der manuellen Optimierung (auf Sicherheit) leider nicht. Wenn jetzt jemand was von Überoptimierung schreibt (wegen dem Wort „täglich“) so kann ich davon ausgehen dass er kein Optimierungsmodul in seinen Systemen eingebaut und sich noch nicht mit dem Thema beschäftigt hat.

Entweder wird ein System deduktiv aus irgendwelchen bewiesenen Annahmen oder Glaubenssätzen konstruiert oder/und empirisch in mehreren Parameter-Dimensionen optimiert.

 

Über KISS kann man glaub ich lang diskutieren (fällt für mich in die gleiche "Glaubensansatz"-Kategorie wie jeder techn. Indikator) und was das Problem der Überoptimierung angeht geb ich dir auch großteils Recht, aber bewiesene Annahmen? Ich würd mich wirklich freuen, in der Tradingwelt einmal was bewiesenes zu sehen.

 

Zur Überoptimierung: Ich denke KISS kann man Anwenden auf einzelne Module (so wie siscop es auch beschrieben hat), dann bekommt man meist mehrere Wolken die teils unterschiedliche "Grundideen" von der Parameterwahl repräsentieren. Gehts dann aber darum das Zusammenspiel von mehreren Modulen zu erforschen (ich sag bewusst erforschen, denn hier geht es noch lang nicht darum aus diesen Ergebnissen ein System zu ziehen, sondern erstmal Zusammenhänge zu verstehen und ein besseres Allgemeinverständniss über den Markt und die Funktionalität der Module zu erhalten) so kommt man schnell in hohe Dimensionen.

 

Natürlich kann man hier argumentieren das manche Modulkombinationen von vornherein ausgeschlossen werden könnten, aber die Frage ist dann wiederum "warum? Wodurch funktioniert diese Kombination nicht?".

 

@siscop: Ich hab mich zwar noch nie mit automatischen Optimierungsmodulen beschäftigt, klingt aber spannend. Ich sage es hängt vom Erfahrungsstand des Anwenders/Entwicklers ab. Man kann täglich Optimieren und nicht überoptimieren und man kann jährlich optimieren und ein heilloses Curvefitting betreiben...

Da gerade Henriks Motive einer Mehrkernoptimierung moniert wurde mal was zum lesen damit Ihr ihn/uns besser versteht.

Danke. Wenn man nur Bruchstücke an Infos bekommt, ist es klar, dass man ein eventuell falsches Bild entwickelt.

 

Diese 3 Punkte im Sicherheitsmodul hängen stark miteinander zusammen und können nicht unabhängig von einander betrachtet werden. Besonders da wir gerade 2 Grund-Exitzusätze (also nicht Parameter) haben und den „besseren“ herausbekommen wollen.

Diese höhere Notwendigkeit an Optimierung dient nur der Entscheidungshilfe welches der Exitzusätze wir nehmen wollen.

Wenn es die Software eben nicht hergibt, mehrere CPUs zu nutzen, auch nicht mit irgendwelchen Tricks, und Ihr nicht auf die neue MT-Version warten wollt, werdet Ihr wohl oder übel die Hardware nachrüsten und/oder aber das Problem abrüsten/parallelisieren müssen (z.B. anhand der zu testenden Exit-Strategie).

...Bruchstücke von Infos

Ich wollte ja nur wissen ob man eine Mehrkern-CPU irgendwie nutzen kann oder nicht.

 

Danke auf jeden Fall für eure Antworten, mein Problem hat sich auch gerade von selbst gelöst (nach 40h ist er fertig mit Optimieren ^^)

 

Bei der nächsten Aktion höre ich aber auch euch und teile die Optimierungen auf 4 MT4-Stationen auf.

...Bruchstücke von Infos

Es ging ja um das Bild, was sich offenbar bei Technix ergeben hat. Er sah Dich wahrscheinlich in einem vierstellig-dimensionalen, kurz vor der Implosion oder Explosion (was da passiert, weiß man nicht so genau, denn es gibt nie Überlebende, die Einzelheiten zu berichten wissen) stehenden Raumes sitzen.

 

 

Ich wollte ja nur wissen ob man eine Mehrkern-CPU irgendwie nutzen kann oder nicht.

Vielleicht kennt Technix ja diese Frage von anderen Opfern, und es ist sowas wie der berühmte letzte Satz, bevor es "Rumps" macht .

 

Bei der nächsten Aktion höre ich aber auch euch und teile die Optimierungen auf 4 MT4-Stationen auf.

Sehr gut.

Was noch ganz wichtig ist, um die Optimierung auch euf einem 1-Kern Prozessor zu optimieren:

1. Keine unnötigen Debug-Ausgaben per print-Befehl während der Optimierung. Da können manchmal Unmengen an Daten anlaufen, die in die Log-Datei geschrieben werden. Das kann den Optimierungsprozess schon stark ausbremsen.

 

2. Geeignete Abbruchkriterien für die Optimierung (max. Drawdown, min. Balance etc.) wählen.

Die Nutzung mehrerer Kerne ist eine Lösung, die nur dann eine Leistungssteigerung bringt, wenn das Problem in der benutzten Software soweit dekomponiert wurde, daß es überhaupt in mehreren Threads laufen kann, die auf mehrere Kerne verteilt werden können. Die Aufteilung eines Problems in mehrere Threads ist bei vielen Problemen meist überhaupt nicht trivial, da durch die von Zeit zu Zeit notwendige Synchronisation der Zwischen-Ergebnisse und die Verwaltung des dafür notwendigen gemeinsamen Datenpools neue Probleme entstehen, die vor der Parallelisierung nicht da waren.

 

Darum geht die automatische Aufteilung eines streng sequentiell geschriebenen Programms nicht. Für das vernünftige Testen hochparalleler Programme sind wesentlich mehr Skills und in der Regel formale Parallelitäts-Modelle (z. B. Petri-Netze) mit speziellen Tools nötig, da die für eine präzise Programm-Funktion ausreichende Vorstellung von Parallelität für annähernd alle Menschen sehr schwierig ist. Erschwerend kommt bei den meisten Problemstrukturen (glücklicherweise weniger beim Backtest) hinzu, daß Parallelitäts-Probleme dazu neigen, daß die Ursachen für Blockaden (Thread A wartet auf Ressource X, die Thread B benutzt und Thread B wartet auf Ressource Y, die Thread A benutzt, ggf. indirekt über mehrere Threads, und keiner kann weiter) lange vor ihrer Erkennung festgelegt werden. Daher nutzen viele Systeme statt einer nicht immer möglichen Ressourcen-Steuerung zur Blockade-Vermeidung eine Blockade-Erkennung und ein Rollback mit verschieden raffinierten Strategien zur Vermeidung der gleichen Blockade beim nächsten Anlauf.

 

Da kommen also wirklich ganz neue Probleme hinzu, die rein sequentielle Programme nicht haben. Die hohe Kunst benutzbarer Systeme mit hoher Parallelität besteht darin, diese neue Komplexität der Basis-Software vor dem Anwender möglichst vollständig zu verbergen, indem ihm minimale oder bestenfalls gar keine Zusatzaufwände für die Parallelisierung abverlangt werden. Damit das gelingt und intern in der Software von Hause aus viele Threads automatisch verwaltet werden, ist ein umfassendes Redesign einer Software erforderlich, die einen sehr großen Release-Step darstellt.

 

Inwieweit KISS nur einen Glaubensansatz darstellt oder doch ein Grund-Prinzip, kann man hinterfragen. Kurt Biedenkopf sagte dazu mal, daß der typische Weg vom Primitiven über das Komplexe zum Einfachen ist. Auch Occams Prinzip geht in eine ähnliche Richtung.

 

Früher habe ich auch an sehr komplexe Systeme geglaubt und gerade unter Informatikern gibt es eine Tendenz unnötig komplexe Systeme zu entwerfen, um dann später daran mehr oder weniger zu scheitern (wie man leicht an fast jeder größeren Software sieht, wo selbst das fertige Resultat an der Oberfläche kaum noch verstehbar ist).

 

Es ging weniger um eine konkrete Kritik an der Komplexität eines einzelnen Aufgaben-Lösungsansatzes sondern um die prinzipielle Problematik, die ja jeden System-Entwickler betrifft, egal wer sie gerade akut artikuliert hat.

 

Komplexe Systeme in der Natur funktionieren dadurch, daß zusammenhängende Grundstrukturen durch Unmengen sich ergänzender Regelkreise überlagert werden. Ein Top-Down-Design solcher Strukturen in einem Entwicklungs-Zyklus ist normalerweise kaum möglich, da es die intellektuelle Kapazität des Menschen meist übersteigt. Solche komplexen Großstrukturen wachsen für gewöhnlich über viele Generationen, teilweise mittels Bootstrap der in vorherigen Phasen erarbeiteten Resultate nicht nur als Lösungsteil, sondern auch als Tool-Bestandteil späterer Phasen. Wie schwierig solche Systeme zu entwerfen sind und wie lange dafür gebraucht wird, sieht man z. B. in der Groß-Forschung (Chip-Industrie, Gen-Technik, Teilchen-Physik u. a.)

 

Das Hinzufügen weiterer Kerne erhöht die Leistung im allerbesten Fall gerade mal linear mit der Anzahl der Kerne. Damit kann eine exponentiell wachsende Problemgröße nur minimal besser abschneiden. Die einzige allgemeine Lösung ist die Problem-Entkoppelung.

 

In einem einzelnen Fall, wo es wirklich nur an der Hardware liegt - wobei ich immer noch meine, daß man es nicht mit Brute Force versuchen sollte und die Lösung so ändern sollte, daß nicht alles mit allem zusammenhängt - kann man auch externe Rechenpower für kurze Zeiträume mieten, wie z. B. bei Amazon's Elastic Cloud Computing. Beim Entwurf profitabler Trading-Systeme stehen die Kosten für solche Dienste in einem sinnvollen Preis-/Leistungs-Verhältnis. Da muß man sich keine schnell technisch veraltenden, extra-teuren Rechen-Boliden zulegen, um hier und da mal eine intensive Berechnung durchzuziehen und davon schlimmstenfalls noch mehrere.

Bearbeitet 8. August 200916 Jr. von Technix