Software > Programmieren und Coding

Multitasking auf CPU und vor allem GPU !

(1/5) > >>

IceCube:
Hallo Leute,

Spätestens seit ich einen Conroe hab, bin ich auf den Geschmack gekommen und programmiere mit echtem Multitasking. Das ist nicht so schwer, Windows stellt alles nötige seit über 10 Jahren, seit der Einführung von Win32 zur Verfügung: Threads starten, Semaphoren, Mutexe, Warten auf Threads. Soweit so gut, kalter Kaffee für alle die sich auskennen.

Der Gag ist der Test eines neuen Programms (Giotto 2.06) auf meinem alten Win98SE-Rechner: Läuft ! Und profitiert auch vom Multithreading, obwohl Win98 ausdrücklich nur einen Core kennt. Na ja, die CPU kann ja schon mal was anderes tun, wenn woanders Daten auf die alten lahme Klapperplatte geschoben werden ...

Erkenntnis 2: Warum dieses Gehype um die neuen Dual oder sogar um die Quad cores ? Was mich erstaunt, wenn ich kleiner Hinterzimmerprogrammierer das nutzbringend hinbekomme, warum nicht dann die echten Entwicklerfirmen ? Schon jetzt gibts eine ganze Menge Standardsoftware, die von Dual core massiv profitiert: Adobe Photoshop z.B. Sogar mein alter Drucker zieht sich mit seinem verquasten Treiber (typisch HP - nie vor Einstellung des Produkts zu Ende entwickelt ...) schmollend auf einen Core zurück und stürzt dort alleine ab, ohne mich und den Rest der Software zu behelligen. Goil :nut:

Gibts hier noch andere Multithreading-programmierer, mit denen man sich mal austauschen kann ?

Gerade jetzt am Wochenende bin ich zwischen dem ganzen Quadcore-Getröte noch auf eine kleine News gestoßen, die mal sehr interessant werden könnte: ATI macht was, um GPUs, die ja nichts anders als hochparallele Einfach-Prozzies sind, allgemeine Rechenaufgaben (Vektormathe z.B.) zuzuweisen: Streaming computing nennen die das. Eine erste Anwendung gibts bereits für uns kleine Daddler: Auf ATI-Karten läuft Folding@home bis zu 30mal schneller als auf der CPU  :wow:

Gibts da schon ein SDK dazu oder komme ich auch über OpenGL/DirectX dahin ?

Ich selber vermute mal eher nicht, denn DirectX ist allzusehr auf Spiele optimiert (Die Welt besteht nicht nur aus (Baller)spielen) und steht im Verdacht, eher erstmal die MMX und SSE-Befehlssätze der CPU zu nutzen und nur auf die hochparallelen GPU-Resourcen zuzugreifen, wenn ganz spezielle Outputfunktionen gefragt sind ...

Weiß hier jemand mehr ?


Stay tuned, IceCube

IceCube:
Hallo Leute, einen Brückentag Recherche und schon ist man schlauer - was ich über eine kleine unscheinbare HeiseTickermeldung http://www.heise.de/newsticker/meldung/78948 erfuhr, ist mehr als einen edit meines Anfangsposts wert gewesen !

... Zuerst erfuhr man in der Tickermeldung, daß nVidia-Chips Programme von maximal 64k Länge abarbeiten können (etwas, was in den einschlägigen Ballerspielen natürlich nicht erreicht wird, aber echte Rechenanwendungen sehr schnell begrenzt ...), ATi kennt hier keine Grenzen ...

Hier gibt es das ersehnte SDK zur GPU-Programmierung aus eigenen Programmen heraus, eine spezielle C-Spracherweiterung namens Brook: http://graphics.stanford.edu/projects/brookgpu/index.html. Brook wird mit einem Art Linux-Aufsatz namens cygwin auf Windows verwaltet und erzeugt dann C++ Code, der mit VisualC++ 6 oder besser 7 in Code umgesetzt wird und per DirectX bzw OpenGL direkt an die GPU geht - Also doch !

Das schöne an Brook ist das sehr klare und einfache Konzept. Ebenso gut ist auch die Beschreibung, wie das alles funktioniert und die einem alles Schritt für Schritt erklärt und nach der man (im Gegensatz zu dem irre überladenen und ziemlich wirren DirectX) sehr straight forward abarbeiten kann.  :thumbup:

Grundlage von Brook sind Datenstreams, die man von C aus lädt die Streams dann an Operationen namens kernel vergibt und sich dort dann das Ergebnis wieder abholt, die GPU als klassischer Coprozessor. Die Daten sind dabei Vektoren, Vektorarrays (3D-Objekte z.B.) oder ganze Felder (Bilder zum Beispiel). Ums Parallelisieren braucht man sich nicht zu kümmern, das erledigt Brook für einen. Damit haben wir einen ganz entscheideneden Unterschied zur klassischen Multitaskingprogrammierung in der CPU: dort muß alles von Hand geschehen, aber dafür sind auch die Daten universell. ... aber das braucht man ja eigentlich eher selten, zumeist sind die Daten zwar Massenhaft, aber vom Typ völlig gleich ....

So neben bei gibts auch ne Menge Beispielcode, der mal echt wertvoll werden kann wie FFT und so. Und alles ist OpenSorce und unterliegt der GNU Public License. Ich brenne schon drauf, mit ein paar zeilen Probiercode meiner GPU was zu tun zu geben und bin auch echt mal auf die tatsächlichen Unterschiede zwischen ATi und nVidia aus Programmierersicht gespannt.


Begeistert und sehr auf die ersten Resultate gespannt, euer IceCube  :cool:

i0n0s:
Bin auch gespannt über die Resultate.
Ich hätte übrigens nach dem Lesen des ersten Postings geschrieben, dass OpenGL sowas nicht kann. Ok, ist natürlich Quatsch wie aus dem 2. Posting hervor geht, micht interessiert aber wirklich in welcher Geschwindigkeit das geht, denn Grafikkarten sind eigentlich nur One-Way und vor dem anderen Weg wird immer gewarnt.


--- Zitat ---... Zuerst erfuhr man in der Tickermeldung, daß nVidia-Chips Programme von maximal 64k Länge abarbeiten können (etwas, was in den einschlägigen Ballerspielen natürlich nicht erreicht wird, aber echte Rechenanwendungen sehr schnell begrenzt ...), ATi kennt hier keine Grenzen ...
--- Ende Zitat ---
Ok, du redest hier von der X1900-Reihe, ansonsten wäre ich schon etwas erstaunt, da alleine bei Shader 2.0 ne Grenze existiert, die manche Shaderentwickler anscheinend schon durchbrechen, ansonsten sehe ich nämlich keinen Vorteil für Shader 3.0 :|

Aber lass was hören IceCube!
Das Thema Threading interessiert mich total, einfach weil ich leider nie weiss was ich in Threads "abschieben" kann :(

Dark Obsecraere:
Bei der Multythread Programmierung werden schon lange Forschungen betreiben. Wie man sehen kann beherrschen dies Technik schon seit Ewigkeiten Video bearbeitungs- oder Rander- Software.

Bei diesen Anwendung kann man technisch unendlich viel Threads Parallel abarbeiten.

Bei Spielen jedoch gibt es im Klassischen Sin ein gewaltiges Problem die Abhängigkeiten zueinander. Da bei Spielen alles in Echtzeit stattfindet muss jede Parallelisierte Aufgabe Synchronisiert werden. Dabei entsteht na menge abglich arbeit.

Derweil sind momentan Ansetze einzelnen Abläufe in der Simulation auf 2 oder 4Cores vorzubereiten, jedoch werden bei der Programmierung, bei einer 8 Kern CPUS wider 4 brachliegen. Vorteil der Code ist von 1 Kern CPU´s noch normal abarbeitbar.

Die Lösungen bestechen schon zur Unendlichen Threads in einer Simulation. Grob Friert man die Simulation ein arbeitet Parallel alles ab und fährt fort mit dem Ergebnis. Problem momentan würde die Simulation jede 1 Sekunde stehen bleiben. Dieser alten standard müsste man aushebeln. Weiters Problem 1 Kern Chips währen mit dieser Aufgabe überfordert. Deswegen scheuen noch die Software Firmen diesen Sprung da momentan noch zu wenig echte Multythread Chips auf dem Markt sind.

Sobald der Grosteil der Zocker 2oder mehr Kern Chips zuhause hat, werden wohl die Spiel Firmen den Sprung wagen.

IceCube:

--- Zitat von: Dark Obsecraere am 03. Oktober 2006, 17:37:35 ---Derweil sind momentan Ansetze einzelnen Abläufe in der Simulation auf 2 oder 4Cores vorzubereiten, jedoch werden bei der Programmierung, bei einer 8 Kern CPUS wieder 4 brachliegen. Vorteil der Code ist von 1 Kern CPU´s noch normal abarbeitbar.

--- Ende Zitat ---

Hi, ich kann dich beruhigen ... keine Cores werden brachliegen, denn ...

... es sollte völlig wurscht sein, wieviele Cores da arbeiten. Die Kunst ist eher die, die Aufgabe so zu zerlegen, daß möglichst viele parallele Prozesse entstehen, die aber während der Abarbeitung möglichst wenig mit einander reden müssen. Etliche Probleme lassen sich ganz wunderbar zerlegen wie z.B. Codecs, Bildbearbeitung, Rendering, weil hier millionenfach dasselbe zu tun ist.

Bei Spielen ist das anders: Hier gibt es sehr unterschiedliche Aufgaben wie die Szenen nachladen, die 3D-Figuren berechnen, die Physik und das Bildrendering. Diese Einzelaufgaben müssen sehr stark miteinander kommunizieren, daher lassen sie sich nicht beliebig zerlegen (noch ...) Man kann davon ausgehen, daß Spieleprogrammierer sehr erfahrene Leute sind, die das sehr genau wissen: Es ist halt noch einiges an Forschungsarbeit nötig, weil es erst seit ganz kurzer Zeit Multicore-CPUs und damit überhaupt Bedarf für echtes Multithreading gibt.

Aber einerlei, die CPU-Zahl ist beim Multithreading erstmal egal.

Wenn sehr viele parallele Cores (wenn auch nur für sehr einfache Brerechnungen) wie beim R580 zur Verfügung stehen, dann muß man sich natürlich Gedanken machen, allen diesen Cores in etwa gleichzeitig und gleichlang was zu tun zugeben.

Was uns zu ein paar Grundregeln des Multithreading führt:

A) Zerlege ein Problem so, daß die Abarbeitung eines Teils in etwa gleich lange wie die anderen Teile dauert und daß während der Abarbeitung keine Teile Informationen von anderen brauchen.

B) Das geht entweder ganz oben, wenn zwei Programme parrallel laufen (Multitasking, es müssen soviele parallele Programme wie CPUs da sein, was etwas unrealistisch ist ...) oder wesentliche Teilbereiche von Programmen einzelnen CPUs zugeordnet werden wie z.B. bei Spielen angedacht (Vorsicht: skaliert sehr inflexibel, hier wär dein Verdacht, zusätzliche CPUs liegen brach, berechtigt)

C) Das geht ganz unten, wenn man wirklich eine Berechnung in viele winzige Partikel zerlegt wie z.B. beim Bild berechnen: da werden alle Pixel gleich behandelt, es skaliert somit solange bis ein Core pro Pixel zur Verfügung steht. Hier sehe ich für die Spieleentwicklung (wenns denn sein muß, ich habe mit den derzeitigen Spielen nix am Hut ...) genügend Ansatzpunkte, soviele in etwa gleichdauernde Teilprobleme zu erzeugen, daß die Anzahl der realen CPUs bei weitem überschritten wird.

D) Multithreading erfordert ein neues Denken wie man eigentlich vorgeht, das ist eigentlich das einzig wirklich schwierige (oder besser neue )daran: Es ist wie auf dem Bau: Früher mit einer CPU hat man mutterseelenalleine vor sich hin gebaut, heute ist man die Bauleitung, die zig Gewerke parallel synchronisieren muß.

Fangen wir mal gaaaaaanz einfach an: Eine R580 GPU z.B. enthält 48 sehr primitive Single Precision Cores, die 48 mal dasselbe ganz parallel erledigen kann... Und dafür genau ist die C-Erweiterung Brook gut. Ich hab jetzt die Chance, wirklich rattenschnell nach Mustern in Bildern zu suchen oder Bilder gleichzeitig zu drehen und zu entzerren (ja ja, das verdammte Prob mit den rechteckigen Pixeln ...) Und zwar so, daß ich das auch noch verstehe ...  :think:

Navigation

[0] Themen-Index

[#] Nächste Seite