Multi Core Programmierung?

[Asmodeus]

Eins vielleicht gleich zum Anfang, mit Programmierung für Multiprozessorsysteme habe ich mich bisher nie beschäftigt, habe also schlichtweg Null Ahnung. Deshalb auch meine simple Frage, wie wird die Programmierung für die kommenden Multi Core Systeme aussehen? Wird es auf Programmcode-Ebene Möglichkeiten geben, verschiedene Cores direkt anzusprechen? Ich habe in meinem Programmprojekt z.B. einen Loader-Thread implementiert, der neben dem eigentlichen Programm auch mit im Hintergrund läuft und Daten auf Anfrage kontinuierlich nachlädt, während sich das Hauptprogramm eben um die Darstellung der Daten kümmert. Würde auf einem Multi Core System nun mein Hauptprogramm und der Loader-Thread automatisch auf jeweils einen eigenen Kern gelegt werden, um die Sache optimal auszulasten, oder müsste ich das von der Programmcode-Ebene aus irgendwie spezifizieren? Und wie wird heutzutage so etwas auf einem Multiprozessorsystem gelöst?

Gruss, Carsten.

[Ganon]

Also soweit ich weiß ist MultiCore nichts anderes als 2 CPUs "in einer".

D.h. nach außen hin ist es so, als wenn du 2 komplette CPUs hast. Also hat man das was man vor Jahren auch schon hatte, nur kleiner. ;)

[Asmodeus]

Also soweit ich weiß ist MultiCore nichts anderes als 2 CPUs "in einer".

D.h. nach außen hin ist es so, als wenn du 2 komplette CPUs hast. Also hat man das was man vor Jahren auch schon hatte, nur kleiner. ;)

Gut, dann bleibt aber weiterhin meine Frage, wie man das heute auf Multiprozessorsystemen macht? :wink: Einmal denke ich eben, ein einzelnes Programm kann auf einem Multiprozessorsystem gegenüber einem Einprozessorsystem doch nur beschleunigt werden, wenn man als Programmierer erstmal selbst die Voraussetzungen dafür schafft, oder? Und da frage ich mich eben, ob es z.B. schon ausreicht, Teile des Programmes eben in einem eigenen Thread auszulagern, der quasi parallel zum eigentlichen Hauptprogramm laufen kann. Und ob ich mich als Programmierer dann noch damit beschäftigen muss, dass Hauptprogramm und Thread auch auf unterschiedlichen Prozessoren laufen, oder ob das dann automatisch verteilt wird.

Gruss, Carsten.

[Ganon]

Du musst bloß dafür sorgen das du dein Programm in Threads aufteilst. Dabei dann darauf achten, dass diese sich nicht selbst blocken.

Den Rest macht das Betriebssystem.

[Trap]

Es gibt 2 Arten von Programmiersprachen:
a) parallele Programmiersprachen (Erlang, Sisal)
b) sequentielle Programmiersprachen (überwiegende Mehrheit)

Man kann mit beiden Arten von Programmiersprachen Anwendungen schreiben die multithreading nutzen. Bei den sequentiellen Programmiersprachen muss man allerdings viel von Hand machen und das ist eine Quelle von viel Komplexität und Fehlern.

Guck dir mal Erlang an. www.erlang.org

[ScottManDeath]

Mit OpenMP (http://www.openmp.org/) kann man durch pragmas in C++ z.B. eine for schleife auf mehrere Threads verteilen, jeder Thread führt einen Teil aus. Man kann auch einzelne Codeabschnitte als unabhängig voneinander deklarieren, dann können mehrere Threads (die dann auf mehreren CPUs laufen) parallel arbeite. Visual C++ 2005 (http://msdn2.microsoft.com/library/tt15eb9t.aspx)bietet Support dafür.

[Coda]

Woa keine funktionalen Programmiersprachen erwähnen in den Semesterferien bitte. Ich bin vom letzten Semester noch restlos bedient ;)

Weiß jemand wann Whidbey jetzt veröffentlicht wird?

[Shink]

Fortran 95 hat eigentlich sehr viele parallele Befehle eingebaut, die Frage ist ob der Compiler das dann tatsächlich multithreaded macht.

[Coda]

Ich nehme an dass das eher für SIMD ist.

[Shink]

Nö, eigentlich nicht. Das heißt: Theoretisch könnts schon jemand in den Compiler einbauen, aber das wär sicher nicht grad einfach oder überall möglich. Ein Beispiel: FORALL, eine DO-Schleife, bei der die Reihenfolge keine Rolle spielt, ist ein Befehl von F95. Ob der Compiler dann wirklich mehrere Threads draus macht, ist eine andere Frage. Bin auch mal auf ein (theoretisch) paralleles F95-Quicksort ohne externe Libraryaufrufe gestoßen.

[Stone2001]

Mit OpenMP (http://www.openmp.org/) kann man durch pragmas in C++ z.B. eine for schleife auf mehrere Threads verteilen, jeder Thread führt einen Teil aus. Man kann auch einzelne Codeabschnitte als unabhängig voneinander deklarieren, dann können mehrere Threads (die dann auf mehreren CPUs laufen) parallel arbeite. Visual C++ 2005 (http://msdn2.microsoft.com/library/tt15eb9t.aspx)bietet Support dafür.
OpenMP ist ein Shared-Memory basiertes Programmiermodell, gedacht um SMP-Systeme oder SMP-Knoten von größeren Clustern zu programmieren, deswegen kann man OpenMP auch recht leicht für MultiCores einsetzten.
(Hey, falls jemand einen freien Compiler für OpenMP hat, sonst muß ich noch auf Visual Studio 2005 warten) Shared-Memory-Konzepte sind recht einfach zu programmieren und recht schnell, leider skalieren sie nur sehr schlecht mit der Anzahl der Prozessoren, bei 64 Prozessoren dürfte schluß sein.

Als Gegenstück zu OpenMP gibt es noch das nachrichtenbasierte Message Passing Interface. MPI wird aber eigentlich nur für Nachrichtengekoppelte Cluster eingesetzt, da mit MPI ein fast beliebige Skalierung erreicht werden kann (Hey, BlueGene hat über 60000 Prozessoren). Naja, aber die Programmierung ist nicht ganz so leicht und für MultiCores wohl ungeeignet. (Solange man nicht 64 Cores auf einem Die integriert ;) )

Neben diesen zwei Standards gibt es noch eine Reihe anderer Möglichkeiten, das oben erwähnte Fortran in der High Performance Fortran Variante oder Unified Parallel C zum Beispiel.
Bei Fortran ist man aber stark vom Compiler abhängig, da es keinerlei Konstrukte zur expliziten Beschreibung von Parallelität gibt.

[Shink]

Also ich finde MPI-Programmierung noch immer um ein Stück einfacher als Programmierung mit mehreren Thread; ist vermutlich aber Gewohnheitssache.
Dann gibts natürlich noch die einfachste, zur Zeit für eher wenige Zwecke verwendbare Methode: Man verwendet Libraries, in denen für den gewünschten Zweck parallele Algorithmen eingebaut sind (z.B. PBLAS/ScaLAPACK für Vektor/Matrix-Operationen).

[icemanemp]

Was soll an Threadprogrammierung so umständlich sein, solange man vorher weiss, was unabhängig berechnet, besorgt, erzeugt oder sonst was wird! Aufpassen muss man nur bei den Kritischen Teilen bzw. Synchronisation Objekten die in anderen Formularen (was auch immer ihr verwendet eben Objekte ausserhalb des Threads) verwendet werden!
Schwieriger finde ich ein Anwendungsgebiet zu finden! Hier in der Firma haben wir schonmal versucht Datenbankanfragen in Threads zu kapseln, leider setzen wir hier Delphi ein und da macht uns nach kurzem Ausprobieren und suchen im Netz leider die Datenbankconnection ein Strich durch die Rechnung! Ob Abfragen im Thread auch schneller wären, ist auch zu bezweifeln, da wahrscheinlich das Netzwerk/Datenbankserver/Datenbank der Flaschenhals sind...
Spiele auf SMP umzustellen bzw. neuzuerstellen ist auch nicht so einfach... Grafik/Physik/KI im Einklang zu halten. Wissenschaftliche Berechnung und Grafik/CAD Anwendung sind ja heute schon so weit, aber wer arbeitet bei so einer Firma bzw. hat als Hobby ein Projekt in diesem Bereich?

[Demirug]

Gerade im Bereich der I/O Flaschenhälse habe ich mit Multithreading gute Erfahrung gemacht. Das waren dann allerdings die Serveranwendungen bzw Clients die mit mehr als einen Server gleichzeitig kommunizieren mussten. Allerdings kann das ganze auch ganz leicht nach hinten lossgehen wenn die IO Thread dann auf eine gemeinsame Datenbasis losgehen. Da kommt es leicht zu blockierungen wenn man nicht aufpasst.

[Shink]

Programmierung mit Threads mag nicht umständlich sein, aber ich persönlich hatte eben mit MPI mehr Erfolg. Das mag auch an meinen anfänglichen, vom Studium beigebrachten Theorien bezüglich Threads liegen: Ein Thread = ein Ablauffaden; wenn man also mehrere Dinge gleichzeitig tut, die - abgesehen von gemeinsamen Variablen/Ressourcen - kaum was miteinander zu tun haben, ist das ein Beispiel für Threads. Wenn man genau so vorgeht, ist das für Einzel-CPUs massig unnötiger Aufwand. Wenn man MPI programmiert, ist man sich zumindest des Aufwandes einer Synchronisation bewusst. Das ist natürlich ein Fehler meinerseits und liegt nicht an den Threads aber was solls.
Das mit der Datenbank ist mE ein Beispiel für einen Einsatzzweck, wo Threads sehr wohl einen Vorteil bringen - da sind wir aber wieder beim Problem, dass viele APIs/Libraries nicht so richtig Threadsafe sind. Wie siehts da eigentlich mit DirectX aus (damit hab ich nix am Hut)? Muss man sich da selber eine Queue schreiben, wenn man aus mehreren Threads rendert?

[Demirug]

Man sollte nicht von mehr als einen Thread aus rendern. Man kann DX durch ein entsprechendes Flag beim erstellen des Devices durchaus Threadsicher machen. Allerdings bringt das letzten Endes auch nicht viel weil das Device ja eine State Maschine ist. Was passiert wenn man eine solche von zwei oder mehr Threads unkontrolliert verändert dürfte bekannt sein.

[icemanemp]

Wie gesagt wir habens ausprobiert und mit einer Query, die jetzt nciht umbedingt schwierig war und es war langsamer als ohne Threads! Ich hatte, wie ich auf die Idee kam, aber ein anderes Design, da wir hier ein so genannten Klasse Preisfinder einsetzten, die uns durch füllen mehrere Propertys (Delphi) und Methoden aufrufe eine Struktur von Preisen und Rabatten liefert (geh besser nicht näher drauf ein/ ist ja Firmeninterna, wenn ich zu technisch werde, aber auch die Megaidee, die man nicht kopieren könnte :) ) Ich z.B. habe ein Programm, das mehrer Listen z.B. von Artikel und Kunden hält und diese einzeln nacheinander durchläuft und die Preisfindug darauf anwendet! Das Durchlaufen dauert sehr sehr lange (bei Kundendaten und das sind nicht mal Echtdaten!). Hier bin ich erst auf die Idee gekommen, man könnte ja mal die Prozessoren der Mehrfach CPU-Systeme wie sie typischerweise bei unseren Kunden stehen, damit auslassten, da z.b. auf meiner Hypertreading Masichen der prozesse immer 50% Last braucht... wäre jetzt noch die Borland Database Engine in der Lage Threading bzw. mehrere Connects zuzulassen (ist vielleicht auch nur einstellungssache bzw. liegt an einer anderen Schnitstellen, aber wir können hier nicht so einfach was an den unteren Ebene / komponenten ändern, da wir hier nur Anwendung auf Basis der Komponenten erstellen...)
Interessant ist das Thema aber so oder so!

Mit MPI haste vielleicht recht. Ich kenn mich da net aus, kenne nur das Konzept der Threads... Aber da der Verwaltungsaufwand so gross ich bezweifele ich jetzt mal! Zwischen 6-10 Threads pro Prozess sollten heutzutage kein Problem sein! Ein krasses Beispiel wäre z.B. unser in der Firma benutzter Virenscanner, der im Hintergrund mal so eben 50 Threads auf hat...
Solange die 50 Threads jetzt net alle bzw. ein paar zum gleichen Zeitpunkt volle Last erzeugen ist die SingleCPU damit glücklich... Dualcore hätte eben noch weniger Probleme... aber da so oder so mehrere Prozesse in einem Multitasking System laufen ist es ja egal ob die noch zusätzlich mehrere Threads haben! Verwaltet ja alles der Betriebsystem "Task"-Manager...