Handelsplattform neu aufsetzen
-
Vielen Dank für eure bisherige Diskussion. Der Kommentar von Schalalalaladida geht schon genau in die Richtung, in der ich das Problem vermute. Selbst, wenn eine Datenquelle komplett abgefragt wurde, wartet das Programm noch weiter, bis auch die letzte Datenquelle abgefragt wurde.
Ein anderes Problem über das ich mir noch den Kopf zerbreche ist die Frage der Datenverwaltung. Die Datenmenge liegt noch in einem Rahmen, in dem ich alle Daten im RAM halten kann und an dieser Stelle wird es wohl auch auf absehbare Zeit keine Probleme geben. Wir reden von ~200MB Daten. Das sollte also in jedem Fall schneller sein, als wenn ich noch eine Datenbank dazu nehme, oder?
Ich habe bisher mit Vector'en gearbeitet und bin damit eigentlich auch sehr zufrieden. Was passiert aber, wenn ich ...
... jeden Thread direkt in den Vector schreiben lasse? Der Fachbegriff fehlt mir gerade aber sind dafür nicht genau CriticalSections gedacht? Ich meine mal gelesen zu haben, dass es Fehler geben kann, wenn alle Threads prallel im Vector schreiben und lesen.
... man könnte natürlich auch die Daten auf einen Stack legen und dann nur einen einzelnen Thread alle Daten aus dem Stack in den Master-Vector schreiben lassen.Läuft das hier darauf hinaus, dass ich mir verschiedene Archtikturen überlege und die dann in kleinen Testanwendungen nach dem trial and error-Prinzip teste oder wie gehe ich am Besten bei der Planung vor?
-
Probleme gibts immer dann, wenn zwei Threads an der gleichen Speicherstelle was machen. Wenn du z.B. Pointer hast die an unterschiedliche Stellen im Vector zeigen und die Threads nur diese Daten und nicht den Vector selber ändern, ist das kein Problem. Welche Sprache nimmst du überhaupt? Du musst natürlich auch aufpassen, dass nicht schon ausgelesen wird, vor der Thread fertig geschrieben hat.
-
Ähhh schrieb:
Merkst du ja schon selber, dass dein Denkmodel veraltet ist.
Veraltet vielleicht ja, aber deswegen noch nicht grundsätzlich falsch. Das Denkmodell "Alles läuft gleichzeitig" dagegen halte ich nach wie vor für falsch und gefährlich, weil es die Problematik ignoriert.
Ähhh schrieb:
Übrigens widerlegst du damit selber deine Aussage, dass der Overhead durch Context-Switches so ein großes Problem ist, weil er sowieso passiert nur eben zu einem Thread der nicht dir gehört.
http://en.wikipedia.org/wiki/Context_switch
http://msdn.microsoft.com/en-us/library/ms682105(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms684261(VS.85).aspx
Zitat msdn
The system consumes memory for the context information required by both processes and threads. Therefore, the number of processes and threads that can be created is limited by available memory.
Keeping track of a large number of threads consumes significant processor time. If there are too many threads, most of them will not be able to make significant progress. If most of the current threads are in one process, threads in other processes are scheduled less frequently.
-
loks schrieb:
Ähhh schrieb:
Merkst du ja schon selber, dass dein Denkmodel veraltet ist.
Veraltet vielleicht ja, aber deswegen noch nicht grundsätzlich falsch. Das Denkmodell "Alles läuft gleichzeitig" dagegen halte ich nach wie vor für falsch und gefährlich, weil es die Problematik ignoriert.
Der "Threads laufen sequentiell" Gedanke ist falsch und viel gefährlicher. Das führt nur dazu, dass man Critical Sections nicht richtig behandeln, wenn man meint, dass es keine parallelen Zugriffe gibt. Nur weil es ein paar DAUs gibt, die meinen 100000 Threads sind immer besser als 10, muss man nicht so denken, als ob alles sequentiell läuft.
-
Zum Thema Threads habe ich verstanden, dass mehr nicht unbedingt besser ist. Aber nur damit die Diskussion nicht in die falsche Richtung läuft, wir reden hier nicht über tausende von Threads, sondern über max. 40, wobei auch das schon für mich viel klingt.
Ich werde einfach mal testen müssen, ob ich bessere Ergebnisse mit
- ein Thread pro Datenquelle bekomme, oder
- Innerhalb einer Datenquelle noch weiter DifferenzierenWahrscheinlich lässt sich die Performance auch noch dadurch steigern, dass ich die Datenabfrage und -verarbeitung noch stärker auf relevante Daten fokussiere. Momentan verfolgt mein Programm eher einen Vollständigkeitsanspruch, obwohl der für meinen eigentlichen Handel gar nicht notwendig ist.
--
Das Thema Pointer auf den Vector klingt interessant. Sogar sehr interessant. Momentan durchläuft mein Aggregierungs-Thread noch ständig den Master-Vector, um zu suchen, wo ein Datensatz aktualisiert werden soll. Wenn ich aber den Pointer auf die entsprechende Stelle direkt speichere, dann müsste ja dieser ganze Prozess wegfallen, oder?
--
Das ganze ist mit VC++ geschrieben, wobei ich momentan stark am Grübeln bin, ob ich auf Linux umsteigen soll. Ich habe gehört, dass inbesondere bei sehr rechenintensiven Anwendungen eher Linux zu empfehlen ist. Ich zögere aber noch etwas vor dem Schritt, weil die Umstellung wahrscheinlich zu Beginn etwas holperig wird, wenn man von seinen hübschen bunten GUIs kommt und dann mit Linux wieder in Konsolen arbeitet. Ich weiß schon, dass es auch Linux Distributionen mit GUI gibt aber die Idee ist ja genau sich die Rechenzeit für die GUI zu sparen.
Grüße,
Michael
-
Michu schrieb:
Das ganze ist mit VC++ geschrieben, wobei ich momentan stark am Grübeln bin, ob ich auf Linux umsteigen soll. Ich habe gehört, dass inbesondere bei sehr rechenintensiven Anwendungen eher Linux zu empfehlen ist.
Lass es bleiben. Linux bringt hier keinen Vorteil.
-
Die Antwort hätte ich jetzt nicht erwartet. Normalerweise liest man doch überall, wie alle davon schwärmen.
-
Michu schrieb:
Die Antwort hätte ich jetzt nicht erwartet. Normalerweise liest man doch überall, wie alle davon schwärmen.
Ja, aber nicht wegen roher Geschwindigkeit von schlichten Berechnungen.
-
@Michu
Mir drängt sich so ein bischen die Befürchtung auf das Du über Lösungsansätze nachdenkst ohne das eigendliche Performanceproblem analysiert zu haben. Hast Du z.B. mal nen Profiler eingesetzt?
-
Michu schrieb:
Die Antwort hätte ich jetzt nicht erwartet. Normalerweise liest man doch überall, wie alle davon schwärmen.
Würde dir empfehlen das Plattformunabhängig zu implementieren, mit boost::thread und asio/lib pion für die Netzwerkabfragen kannst du dann die Plattform immer noch recht einfach wechseln.
Das Linux da aber große Vorteile bringt bezweifel auch ich.