Sonntag, 25. Februar 2007, 00:31
Hallo Udo
Was Du da schreibst ...
... stimmt. Aber zusätzlich muss sich die zu programmierende Problemstellung auch für eine Parallelisierung eignen! Dazu sollte sich eine Aufgabe in viele kleine, möglichst unabhängige, Teile zerlegen lassen, die ASYNCHRON voneinander abgearbeitet werden können und am Schluss ihr Ergebniss in ein Patchwork einliefern. Jeder nötige Synchronisations-Mechanismus (nötige Semaphore, Enqueue/Dequeue Handling etc.) stellt einen neuen Flaschenhals dar!
Dazu darf man sich bei der Konzeption der Parallelisierung nicht auf Dual-Cores beschränken. Im profiessionellen Bereich sind seit langem schon mehrere Dutzend CPUs pro Maschine üblich, und auch im Hobby Bereich kündigen sich nun Quad-Cores etc. an.
Wenn wir das aus INV Sicht sehen (und wie sollten wir es im INV Forum sonst sehen wollen) bedeutet dies: bisher läuft INV native auf dem OS. Windows (wie auch Linux, das hätte hier gar keinen Vorteil) ist kein Transaktions-Monitor und dazu stellt dieses OS keinerlei echten Batch-Support zur Verfügung, den man für Massiv-Parallele Ansätze braucht. D.h. wenn Herr Knöpfel die Teile von INV, welche sich für die Parallelisierung eignen (z.B. Optimierung, NN Training, Berechnung von Berechnungstiteln) parallelisieren möchte, müsste er eine Menge selbst programmieren. Vor allem einen Batch-Scheduler, und das ist nicht so trivial, wie es sich da hin schreibt. Oder sich nach einem geeigneten Trägersystem umsehen, was sicher nicht gratis ist.
Bis dahin versuche ich M+ besser kennen zu lernen. Ob INV irgendwann ein bisschen schneller ist oder nicht, am Ende zählt der Einblick in den Markt; Bruto Force Ideen werden wohl nicht zu besseren Handels-Ideen führen :]
Was Du da schreibst ...
Zitat
Original von Udo
Die Software muss für Dual-CPUs programmiert werden-dann ist die Chance auf einen deutlichen Leistungsschub hoch!. ..
... stimmt. Aber zusätzlich muss sich die zu programmierende Problemstellung auch für eine Parallelisierung eignen! Dazu sollte sich eine Aufgabe in viele kleine, möglichst unabhängige, Teile zerlegen lassen, die ASYNCHRON voneinander abgearbeitet werden können und am Schluss ihr Ergebniss in ein Patchwork einliefern. Jeder nötige Synchronisations-Mechanismus (nötige Semaphore, Enqueue/Dequeue Handling etc.) stellt einen neuen Flaschenhals dar!
Dazu darf man sich bei der Konzeption der Parallelisierung nicht auf Dual-Cores beschränken. Im profiessionellen Bereich sind seit langem schon mehrere Dutzend CPUs pro Maschine üblich, und auch im Hobby Bereich kündigen sich nun Quad-Cores etc. an.
Wenn wir das aus INV Sicht sehen (und wie sollten wir es im INV Forum sonst sehen wollen) bedeutet dies: bisher läuft INV native auf dem OS. Windows (wie auch Linux, das hätte hier gar keinen Vorteil) ist kein Transaktions-Monitor und dazu stellt dieses OS keinerlei echten Batch-Support zur Verfügung, den man für Massiv-Parallele Ansätze braucht. D.h. wenn Herr Knöpfel die Teile von INV, welche sich für die Parallelisierung eignen (z.B. Optimierung, NN Training, Berechnung von Berechnungstiteln) parallelisieren möchte, müsste er eine Menge selbst programmieren. Vor allem einen Batch-Scheduler, und das ist nicht so trivial, wie es sich da hin schreibt. Oder sich nach einem geeigneten Trägersystem umsehen, was sicher nicht gratis ist.
Bis dahin versuche ich M+ besser kennen zu lernen. Ob INV irgendwann ein bisschen schneller ist oder nicht, am Ende zählt der Einblick in den Markt; Bruto Force Ideen werden wohl nicht zu besseren Handels-Ideen führen :]
Gruss
Bernd
Bernd
Sonntag, 25. Februar 2007, 12:33
Hallo,
Es wäre zwar ganz schön, wenn der GA oder das NN-Training statt 15min nur noch 10min brauchen würde, aber meine Motivation mich mit Beschleunigungsmöglichkeiten auf Hardware- & Softwareseite zu beschäftigen liegt an einer ganz anderen Stelle.
Es geht mir hauptsächlich um die Beschleunigung der Berechungsvorgänge beim Trading, d.h. wie kann man noch schneller die Orders zu IB "schießen", also wie kann die Strecke:
neuer Kurs -> Inv. HS-Berechnung --> Signal --> OM-Berechung --> Order zu IB abschicken --> Order ist bei IB angekommen & scharf geschaltet
beschleunigt werden.
Ein paar Millisekunden mehr oder weniger entscheiden darüber wie hoch mein Slippage ist und letztendlich entscheidet sich damit auch, ob das HS in der Summe Gewinne oder Verluste macht. An dieser Stelle geht es also um alles oder nicht.
Die Eigenhandelsabteilungen bei den Banken werde alles unternehmen, das die Gewinne bei ihnen auflaufen. Wir konkurrieren also gegen einen Gegner der über ein 100.000 faches an finanziellen Ressourchen, exclusive Hardwareausstattung, Börsen-Standleitungen, Spezialisten für Hardware & Software & Optimierungsfragen und ganzen Teams die sich den ganzen lieben langen Tag nur mit Handelsstrategien die eine positive Gewinnerwartung haben beschäftigen & diese umsetzen.
Man sollte schauen, dass man zumindestens bei ein paar Punkten auf Augenhöhe mit den Banken-Eigenhandelsabteilungen liegt, um nicht völlig auf verlorenen Posten zu stehen.
Deshalb war meine Überlegung, ob man ein paar ms herausholen könnte, wenn Investox eine CPU ganz für sich alleine bekommt und Betriebssystem, TWS, RTT auf dem anderen Core laufen. Aber ganz so einfach scheint die Sache nicht zu sein.
Viele Grüße
Torsten
welche sich für die Parallelisierung eignen (z.B. Optimierung, NN Training, Berechnung von Berechnungstiteln)
Es wäre zwar ganz schön, wenn der GA oder das NN-Training statt 15min nur noch 10min brauchen würde, aber meine Motivation mich mit Beschleunigungsmöglichkeiten auf Hardware- & Softwareseite zu beschäftigen liegt an einer ganz anderen Stelle.
Es geht mir hauptsächlich um die Beschleunigung der Berechungsvorgänge beim Trading, d.h. wie kann man noch schneller die Orders zu IB "schießen", also wie kann die Strecke:
neuer Kurs -> Inv. HS-Berechnung --> Signal --> OM-Berechung --> Order zu IB abschicken --> Order ist bei IB angekommen & scharf geschaltet
beschleunigt werden.
Ein paar Millisekunden mehr oder weniger entscheiden darüber wie hoch mein Slippage ist und letztendlich entscheidet sich damit auch, ob das HS in der Summe Gewinne oder Verluste macht. An dieser Stelle geht es also um alles oder nicht.
Die Eigenhandelsabteilungen bei den Banken werde alles unternehmen, das die Gewinne bei ihnen auflaufen. Wir konkurrieren also gegen einen Gegner der über ein 100.000 faches an finanziellen Ressourchen, exclusive Hardwareausstattung, Börsen-Standleitungen, Spezialisten für Hardware & Software & Optimierungsfragen und ganzen Teams die sich den ganzen lieben langen Tag nur mit Handelsstrategien die eine positive Gewinnerwartung haben beschäftigen & diese umsetzen.
Man sollte schauen, dass man zumindestens bei ein paar Punkten auf Augenhöhe mit den Banken-Eigenhandelsabteilungen liegt, um nicht völlig auf verlorenen Posten zu stehen.
Deshalb war meine Überlegung, ob man ein paar ms herausholen könnte, wenn Investox eine CPU ganz für sich alleine bekommt und Betriebssystem, TWS, RTT auf dem anderen Core laufen. Aber ganz so einfach scheint die Sache nicht zu sein.
Viele Grüße
Torsten
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sten« (25. Februar 2007, 12:41)
Sonntag, 25. Februar 2007, 16:44
Original von sten
also wie kann die Strecke:
neuer Kurs -> Inv. HS-Berechnung --> Signal --> OM-Berechung --> Order zu IB abschicken --> Order ist bei IB angekommen & scharf geschaltet
beschleunigt werden.
Sind wir denn sicher, dass am Ende nicht die Strecke Order zu IB abschicken --> Order ist bei IB angekommen das Problem ist, und eine Millisekunde im INV Kern da irgenwas dran ändern kann?
Meine Erfahrung aus dem diskretionären Handel ist, wenn es WIRKLICH hektisch wurde an der Börse, dann bekam ich einfach keine gute Verbindung mehr. Es war nie innerhalb nützlicher Frist zu entscheiden wer schuld war (Provider, Broker, Backbone oder was), es ging einfach nicht.
Ich drücke es mal anderst herum aus: solange Du auf einer Dual Core Maschine im aktiven Handel INV weniger als 49% CPU nehmen siehst - liegen Verzögerungen auch nicht an INV sondern man muss ringsherum suchen. Hast Du aber in diesem Bereich Probleme und kannst die 49% bei INV sehen im realen Handel?, dann verstehe ich, warum Du den INV Kern gerne paralellisiert und für Multicore optimiert sehen möchtest (aber vielleicht sind die Handels-Regeln auch ungünstig formuliert; mit einem geeigneten 3 Zeiler kann man jede Maschine auf 100% CPU bringen :] )
Original von Udo
Überflüssig wird das sicherlich nicht denn irgendwann muss auch Investox an die schnell voranschreitende Technik angepasst werden...
Fully agree! Ich sehe da nur viiiiel Arbeit auf den armen AK zukommen :]
Und hier noch ein Gedanke, um die Multicore Idee mal zu relativieren:
Alle reden in diesem Hobby Segment (mit Hobby ist NICHT der Handels-Anspruch, sondern die Wintel Umgebung gemeint!) dieser Tage von Dual- und gar Quad Core. Die Anzahl der Prozessoren sind auf einer Maschine aber höchsten die halbe Miete (wenn überhaupt). Noch wichtiger sind die Anzahl der I/O Channels und die Geschwindigkeit der Busse und der Caches. Stellt Euch vor, eine Intel-Büchse mit 2 Quad-Cores - und des gibt eine Platte die das alles supporten soll. Haha
Massiv-Parallele Maschinen (48 Prozessoren und mehr) eleminieren daher auch I/O Wait States; billig ist das aber nicht.Noch ein Joke am Rande: wenn es Handels-Verzögerungen gibt und INV nicht 49% einer Dual Core CPU nimmt - könnte es an den überlasteten Patten- oder I/O Channels oder dem Netzwerk oder dem Backbone oder dem Provider oder dem Broker liegen. Parallelisierung eines Wintel-Programmes (in diesem Fall INV) löst in diesem Bereich diese Probleme nicht ...
So ist eben dies ...
Original von bernd
(z.B. Optimierung, NN Training, Berechnung von Berechnungstiteln)
das Einzige, wo man mit Sicherheit durch Parallelisierung etwas herausholen kann (Berechnungstitel schon mit Einschränkungen, weil der I/O Bereich hier wieder mit reinspielt). Desswegen habe ich diese Bereiche angeführt, und nicht den Real-Handel.
wie gesagt:
8
Original von bernd
.. stimmt. Aber zusätzlich muss sich die zu programmierende Problemstellung auch für eine Parallelisierung eignen!
Gruss
Bernd
Bernd
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »bernd« (25. Februar 2007, 16:53)