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.
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 ...
