Mittwoch, 18. Juli 2018, 14:40 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

sten

Erleuchteter

Registrierungsdatum: 6. September 2002

Beiträge: 2 879

1

Dienstag, 8. April 2014, 10:50

InvEntw.PC: Unterstützung von MehrkernCPU's bei ROB und GA

Hallo,

Investox ProduktivPC:
  • hier werden die MehrkernCPU's schon sehr gut unterstützt, d.h. man kann unter Investox mehrere Unterinstanzen installieren und dort die HS laufen lassen
  • so kann man die HS besser gruppieren, z.B. nach Brokern (IB, virtueller Broker) oder nach der Periodendauer (z.B. 60min-HS, 24h-HS, usw.)
  • das Konzept ist sehr anwenderfreundlich umgesetzt, z.B. werden bei Start des HauptInvestox auch gleich alle UnterInstanzen gestarten, viele Einstellmöglichkeiten, usw.
  • Fazit: das ist perfekt


Investox EntwicklungsPC:
  • die meiste Zeit geht bei der Entwicklung der HS, und hier speziell bei der Parametrisierung der Optimierungsvariablen verloren, d.h. hier gibt es viel Einsparpotential
  • man hat einmal den Robustheitstest und den GA, die leider nur auf einer CPU laufen
  • Verbesserungsvorschlag: der Investoxler hat ein 4KernCPU-PC und installiert Investox + 3 Unterinstanzen von Investox (für jeden CPU-Kern eine)
  • dann wird ein Investox-Berechungsklaster gebildet, wo der InvestoxHauptinstanz die 3 Unterinstanzen als "Worker" zugewiesen werden
  • a)Robustheitstest: da ist es ganz einfach, weil wenn man z.B. die Periode eines Indikators von 1 bis 400 variiert, dann sind alle 400 Berechnungen voneinander unabhängig, d.h. man kann den Berechnungsraum von 400 Berechungen durch 4 teilen und so berechnet jeder CPU-Kern über die 4 Investoxinstanzen parallel nur je 100 Berechnungen (die perfekte Arbeitsteilung). Zum Schluß sammelt die InvestoxHauptinstanz die Berechnungsergebnisse ein, fügt alles zusammen und zeigt das Ergebnis des Robustheitstest wie gewohnt an
  • b)GA: anstatt bei einer Generationsberechnung, diese nur auf einen Kern auszuführen, wird diese auf allen 4 Kernen gestartet, dann alle Ergebnisse eingesammelt und das beste Berechnungsergebnis verwendet und weiter geht es zur nächsten Generationsberechnung. Ich denke so könnte man den GA parallelisieren und ein Optimum wird so schneller gefunden werden.


Wie kann man es umsetzen?
  • die Parallelisierung des ROB und GA ist ja nichts neuen, alle Komponenten sind in Investox schon vorhanden und die Erweiterung setzt perfekt auf der bereits umgesetzten Parallelisierung über mehrere InvestoxInstanzen auf
  • man benötigt zusätzlich einen Mechanismus zur internen Kommunikation zwischen den verschiedenen InvestoxInstanzen, als Protokoll könnte man z.B. XML verwenden oder besser noch JSON(ist weniger "gesprächig")
  • im einfachsten Fall erfolgt die Kommunikation über das Filesystem: d.h. jede Investox-UnterInstanzen bekommt die Verzeichnisse "internInput" und "internOutput". Die InvestoxHauptInstanz verteilt die Arbeit an die "Worker", d.h. die Arbeitspakete werden in den Verz. "internInput" abgelegt. Jede Investox-UnterInstanzen schaut regelmäßig in dem Auftragsordner nach ob es Arbeit gibt und wenn ein JSON-Arbeitspaket vorliegt dann wird es abgearbeitet. Das Ergebnis der Berechnung wird im Verz. "internOutput" abgelegt. Zum Schluß sammelt der "Chef", d.h. die InvestoxHauptInstanz die Berechnungsergebnisse wieder ein, bereitet sie auf und bringt sie zu Anzeige bzw. beim GA fließt in den nächsten Berechnungsschritt mit ein.
  • die Fileschnittstelle ist der 1.Schritt, um erstmal zu sehen ob es so funktioniert und von den InvestoxUser angenommen wird. Bei 4 Kernen schafft man bestimmt eine Leistungssteigerung auf 300%, trotz der langsamen Fileschnittstelle. Später kann man die Fileschnittstelle dann noch ersetzen, z.B. durch Services oder eine direkte Client-Server-Kommunikation oder ähnlichem


Vielleicht läst sich da was machen.
Es wäre wirklich ein gewaltiger Fortschritt, wenn man die sehr aufwendigen Berechnungen bei ROB und GA um ein vielfaches, unter Verwendung der bestehenden Ressourcen (4 KernCPU's sind heute fast schon Standard und der Trend geht zu immer mehr Kernen), beschleunigen könnte.
Danke.

Viele Grüße,
Sten

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »sten« (8. April 2014, 11:04)


Nicola Männlich

Fortgeschrittener

Registrierungsdatum: 11. November 2008

Beiträge: 136

2

Freitag, 13. Juni 2014, 14:34

Und jetzt stelle sich mal einer vor man könnte noch auf die ganzen Prozessoren der GPU zugreifen 8o
Gruß
Nicola

Lenzelott Männlich

Erleuchteter

Registrierungsdatum: 30. Dezember 2002

Beiträge: 2 897

Wohnort: Giessen

3

Freitag, 13. Juni 2014, 16:47

Und jetzt stelle sich mal einer vor man könnte noch auf die ganzen Prozessoren der GPU zugreifen 8o


Da träume ich durchaus schon länger davon.
Für R gibt´s da durchaus mittlerweile die Möglichkeit zb. CUDAzu integrieren.
If you think it´s expensive to hire a professional, wait until you hire an amateur.

sten

Erleuchteter

Registrierungsdatum: 6. September 2002

Beiträge: 2 879

4

Samstag, 25. April 2015, 16:29

Idee: Verteilung der RobIterations-Berechung auf mehrere InvestoxPC's per Filesystem über externes Zusatztool

Hallo,

ich wollte mal fragen, ob es bezüglich Parallelisierung schon was neues gibt.
Ich hatte ja in dem Beitrag weiter oben mal ein paar Ideen hierzu vorgestellt gehabt.

Viele Grüße,
Sten

PS1:
Update - Idee einer low-level Parallelisierungs-Variante: ... solange die deluxe-Variante noch nicht verfügbar ist
- durch die neue Rob-Iterationsmöglichkeit in V7 gäbe es noch eine ganz einfache Variante auf Filesystem-Ebene
1.) man bereitet auf dem Inv.EntwicklungsPC ein InvProjekt vor, macht alle Einstellungen und speichert es ab
2.) man markiert das InvProjekt, z.B. mit einem @-Zeichen am Ende, z.B. so: projektname@.inv ... z.B. über einen externen DateiViewer mit *.inv
3.) das InvProjekt verschiebt man auf einen der WorkInvPC's, z.B. --> X:\workspaceInv\ ... diese Einstellung sollte man gleich speicherbar auf Button legen können, z.B. invProj1->workPC1, InvProj2->workPC2, usw. für die regelmäßigen/wöchentlichen Nachjustierungen
4.) das Verzeichnis "workspaceInv" wird überwacht und sobald ein neues Projekt dort abgelegt wird, startet Investox auf dem WorkInvPC und läd das InvProjekt
5.) im Idealfall startet Investox dann automatisch: die RobIteration von dem voreingestellten HS und speichert nach getaner Arbeit das InvProjekt ab
6.) der "Wächter" erkennt den neuen Zeitstempel der Datei: X:\workspaceInv\projektname@.inv ... und movt das Projekt nach Inv.EntwicklungsPC zurück
7.) Rückbenennung von projektname@.inv --> projektname.inv und akustisches Signal wird ausgelöst "bin fertig"

Das könnte ein völlig eigenständiges Tool neben Investox sein.
Lediglich der Punkt 5) ist knifflig ...
- alle hierfür benötigten Aktionen müssten per Tastenkommando Investox übermittelt werden +
- Wie kann das externe Tool dann feststellen, das die RobIteration beendet ist, damit der InvProjektSpeicherBefehl richtig getriggert werden kann?

PS2:
- ergänzend zu PS1 ... noch besser wäre es, wenn man anstatt des ganzen inv-Projektes nur das zu berechnende HS versenden würde
- das geht, d.h. man kann ein HS mit Namen "nimmMich2workPC2" abspeichern und es ist dann im Inv-Basisverz./Systemvorlagen als KSESV-File (nimmMich2workPC2.KSESV) verfügbar

Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von »sten« (25. April 2015, 16:55)


Nicola Männlich

Fortgeschrittener

Registrierungsdatum: 11. November 2008

Beiträge: 136

5

Mittwoch, 20. April 2016, 12:14

Nachdem Investox hinsichtlich Parallelisierung weiterhin "bodenständig" bleibt, frage ich mich gerade ob es nicht möglich ist mit Hilfe einer VM "Quasi-Parallelisierung" zu erzielen? Bedeutet: angenommen man erstellt auf einem multicore System mit Hyper-V eine VM und weist ihr nur 1 CPU zu. Würde das durch das Scheduling auf Hypervisorebene nicht ein multithreading der VM mit Investox und single Core bedeuten?
Gruß
Nicola

Lenzelott Männlich

Erleuchteter

Registrierungsdatum: 30. Dezember 2002

Beiträge: 2 897

Wohnort: Giessen

6

Mittwoch, 20. April 2016, 13:33

Warum so umständlich?
Du kannst Dir doch auch 8 Instanzen anlegen und alle gleichzeitig werkeln lassen.
If you think it´s expensive to hire a professional, wait until you hire an amateur.

Nicola Männlich

Fortgeschrittener

Registrierungsdatum: 11. November 2008

Beiträge: 136

7

Mittwoch, 20. April 2016, 14:36

Ja natürlich, aber die einzelnen Threads werden dadurch auch nicht parallelisiert.
Mir ist gerade auch kla.r geworden, dass das durch VMs auch nichts ändert. Die Threads werden ja trotzdem immer nur sequentiel ausgeführt und der Hypervisor koordiniert den Supervisor... Hat sich also auch erledigt.
Gruß
Nicola

Nicola Männlich

Fortgeschrittener

Registrierungsdatum: 11. November 2008

Beiträge: 136

8

Mittwoch, 27. April 2016, 11:22

Ich habe noch eine Frage, und zwar wenn in einer Instanz mehrere HS laufen, werden die Berechnungen der einzelnen HS in dieser einen Instanz denn auf mehrere Threads verteilt?
Gruß
Nicola

Lenzelott Männlich

Erleuchteter

Registrierungsdatum: 30. Dezember 2002

Beiträge: 2 897

Wohnort: Giessen

9

Mittwoch, 27. April 2016, 13:13

Nein.
Eine Instanz = 1 Kern
If you think it´s expensive to hire a professional, wait until you hire an amateur.

Nicola Männlich

Fortgeschrittener

Registrierungsdatum: 11. November 2008

Beiträge: 136

10

Mittwoch, 27. April 2016, 14:28

Ayy, Danke Lenze!

Aber dennoch, eine Instanz erzeugt mehrere Threads im Taskmanager und eine Instanz mit mehreren HS als eine andere Instanz hat bei mir mehr Threads als die mit weniger HS. Allerdings sind es nicht soviele Threads wie HS in der Instanz aktiv sind.
Weisst du zufällig auch was das alles für Threads sind und wovon es abhängt wieviele Threads eine Instanz erstellt?
Gruß
Nicola

Lenzelott Männlich

Erleuchteter

Registrierungsdatum: 30. Dezember 2002

Beiträge: 2 897

Wohnort: Giessen

11

Mittwoch, 27. April 2016, 17:29

nein weiß ich nicht
If you think it´s expensive to hire a professional, wait until you hire an amateur.