Hier mal ein paar Dinge die man über Multicore und Multithreading wissen sollte.
Multithreading gibt es erst seit Multicores (Dual/Tri/Quad/HEX/ usw)
Dual Core haben stärker profitiert als Quad und mehr Cores wieso?
Dann ist ganz einfach, weil man mit DualCoreTechnologie endlich mal die Threads in CPUs integriert hat. Das hatten die SingleCores nicht. Weshalb es auch kein wirkliches Multitasking gab. Sondern ein vorgegaukeltes.
Nun haben wir ja die Threads, und alles ist schön. Aber so einfach ist es dann doch nicht. Jetzt könnt man meinen, wir packen einfach schön 1 Thread pro Kern und man nutzt die Maximale Power seines Quad/Hex aus. Nur, was wenn Thread 1 jetzt nichts mehr zu tun hat? Dann verpufft die ganze Performance. Pech gehabt.
Dennoch ist es eh etwas Falsch ausgesagt. Es fängt nämlich anders an. Man hat eine CPU mit 4 Kernen, logisch wären 4 Threads aka 1 Thread pro Kern. Aber dem ist nicht so. Vielmehr ist es so, das die CPU 4 Tasks haben kann, die in Threads unterteilt werden. So kann man fleißig 20 Threads laufen lassen, und die werden vom OS dann selbst verwaltet. Das klingt doch schön. Das ist aber nur die Theorie. Und die Realität sieht anders aus.
Nun muss man erst mal alles mögliche parallelisieren. Um zwischen den Threads umher zu schalten gibt es alle x ms einen Switch, der selber natürlich Zeit kostet. Umso mehr Threads man also öffnet, desto mehr Zwischenzeit verplempert man mit dem schauen ob Thread 12 und 3, denn nun wirklich etwas machen können. Also umso größer die Anzahl der Threads, desto mehr Overhead durchs zappen durch die Threads. Damit könnte man ja evtl. leben. Aber es gibt Programmcode, der lässt es nicht zu, das man ihn parallelisiert, weil er z.B. einfach ein Komando des Users erforderlich ist. Kein Kommando vom User, also braucht die CPU nichts zu berechnen. Alle Dinge die man in Reichweite Vorberechnen kann, wurden schon berechnet. Was nun, mit der Rechenleistung? Weitere Dinge Vorberechnen? Aber, dann bewegt man sich in einen Event (öffnet eine Tür) und die CPU müsste dann abrupt umswitchen. Nur war es mit so vielen Threads beschäftigt, das die Scheibe der Threads schon auf 100 angewachsen ist. Um, wieder beim Thread mit der Benutzerschnittstelle anzukommen, dauert es jetzt schon nicht mehr nur 1ms, sondern dann schon locker 2-3 Sekunden. Das wäre eine Katastrophe. Maus wackeln, und so 2-3 Sekunden später bewegt sich die Figur. Da wären aber alle glücklich.
Um es mal klar zu sagen. Multithreading ist für Statische Berechnungen ideal. Für Dynamische, wie man sie in Spielen vorfindet, weitestgehend ungeeignet.
Zumal noch eine Sache hinzukommt. Die Daten, die man parallelisiert hat, müssen anschließend wieder synchron gemacht werden. Wie erfolgreich das ist, sieht man unter anderem bei SLI/CF. Das kostet natürlich auch wieder Zeit, die Daten müssen aus willkürlichen Threads gezogen werden und bis man die richtig zusammengefügt hat, vergeht wieder zusätzliche Zeit, durchs wechseln der Threads.
Und die Threads werden aus einen Threadpool gezogen, da hat der Programmierer kaum eine Entscheidungsmöglichkeit. Der Pool wird dann kalkuliert, und daraufhin, wird der dem entsprechenden Task übergeben. Interessant ist nur, wieso es eigentlich nicht Hyper Tasking heißt. Aber dieses verwirrspiel hat Microsoft geschaffen.
Ich selber programmiere, und dort wird gerne über die falsche Namensgebung gelästert. Und MS selbst rät, nur 6 Threads pro Anwendung laufen zu lassen. Gui, Userinterface, Daten schreiben, Daten lesen, Sound, KI.
Also die Illusion, das man so stark von Multicores profitiert, ist dahingestellt bei Games.
Multithreading gibt es erst seit Multicores (Dual/Tri/Quad/HEX/ usw)
Dual Core haben stärker profitiert als Quad und mehr Cores wieso?
Dann ist ganz einfach, weil man mit DualCoreTechnologie endlich mal die Threads in CPUs integriert hat. Das hatten die SingleCores nicht. Weshalb es auch kein wirkliches Multitasking gab. Sondern ein vorgegaukeltes.
Nun haben wir ja die Threads, und alles ist schön. Aber so einfach ist es dann doch nicht. Jetzt könnt man meinen, wir packen einfach schön 1 Thread pro Kern und man nutzt die Maximale Power seines Quad/Hex aus. Nur, was wenn Thread 1 jetzt nichts mehr zu tun hat? Dann verpufft die ganze Performance. Pech gehabt.
Dennoch ist es eh etwas Falsch ausgesagt. Es fängt nämlich anders an. Man hat eine CPU mit 4 Kernen, logisch wären 4 Threads aka 1 Thread pro Kern. Aber dem ist nicht so. Vielmehr ist es so, das die CPU 4 Tasks haben kann, die in Threads unterteilt werden. So kann man fleißig 20 Threads laufen lassen, und die werden vom OS dann selbst verwaltet. Das klingt doch schön. Das ist aber nur die Theorie. Und die Realität sieht anders aus.
Nun muss man erst mal alles mögliche parallelisieren. Um zwischen den Threads umher zu schalten gibt es alle x ms einen Switch, der selber natürlich Zeit kostet. Umso mehr Threads man also öffnet, desto mehr Zwischenzeit verplempert man mit dem schauen ob Thread 12 und 3, denn nun wirklich etwas machen können. Also umso größer die Anzahl der Threads, desto mehr Overhead durchs zappen durch die Threads. Damit könnte man ja evtl. leben. Aber es gibt Programmcode, der lässt es nicht zu, das man ihn parallelisiert, weil er z.B. einfach ein Komando des Users erforderlich ist. Kein Kommando vom User, also braucht die CPU nichts zu berechnen. Alle Dinge die man in Reichweite Vorberechnen kann, wurden schon berechnet. Was nun, mit der Rechenleistung? Weitere Dinge Vorberechnen? Aber, dann bewegt man sich in einen Event (öffnet eine Tür) und die CPU müsste dann abrupt umswitchen. Nur war es mit so vielen Threads beschäftigt, das die Scheibe der Threads schon auf 100 angewachsen ist. Um, wieder beim Thread mit der Benutzerschnittstelle anzukommen, dauert es jetzt schon nicht mehr nur 1ms, sondern dann schon locker 2-3 Sekunden. Das wäre eine Katastrophe. Maus wackeln, und so 2-3 Sekunden später bewegt sich die Figur. Da wären aber alle glücklich.
Um es mal klar zu sagen. Multithreading ist für Statische Berechnungen ideal. Für Dynamische, wie man sie in Spielen vorfindet, weitestgehend ungeeignet.
Zumal noch eine Sache hinzukommt. Die Daten, die man parallelisiert hat, müssen anschließend wieder synchron gemacht werden. Wie erfolgreich das ist, sieht man unter anderem bei SLI/CF. Das kostet natürlich auch wieder Zeit, die Daten müssen aus willkürlichen Threads gezogen werden und bis man die richtig zusammengefügt hat, vergeht wieder zusätzliche Zeit, durchs wechseln der Threads.
Und die Threads werden aus einen Threadpool gezogen, da hat der Programmierer kaum eine Entscheidungsmöglichkeit. Der Pool wird dann kalkuliert, und daraufhin, wird der dem entsprechenden Task übergeben. Interessant ist nur, wieso es eigentlich nicht Hyper Tasking heißt. Aber dieses verwirrspiel hat Microsoft geschaffen.
Ich selber programmiere, und dort wird gerne über die falsche Namensgebung gelästert. Und MS selbst rät, nur 6 Threads pro Anwendung laufen zu lassen. Gui, Userinterface, Daten schreiben, Daten lesen, Sound, KI.
Also die Illusion, das man so stark von Multicores profitiert, ist dahingestellt bei Games.
12 Threads maximal.
- Und da hab' ich eben mal ein Beispiel einer produktiven Anwendung angeführt, die gut von Multithreading profitiert.
