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:
Original von bernd
.. stimmt. Aber zusätzlich muss sich die zu programmierende Problemstellung auch für eine Parallelisierung eignen!
8
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »bernd« (25. Februar 2007, 16:53)