10.06.2013, 13:56
Also generell ist es mit modernen Entwicklungssystemen (z.B. c# & Dot Net 4.5) sehr einfach mehrere Kerne anzusprechen.
Man muss allerdings auch eine Aufgabe haben die sich parallelisieren lässt.
Bei spielen bieten sich da in der Regel komplexe KI oder Physikberechnungen an.
Manchmal noch komplexes Postprocessing von Bildern.
Bei umfangreichen multiplayer Titeln bietet es sich an die ganze Netzwerkkommunikation von einem extra Kern machen zu lassen um die Latenzen zu minimieren.
Das alles kommt in der Schicksalsklinge aber nicht vor.
Die Grafik berechnet eh die GPU, die CPU schickt hier vereinfacht gesagt nur die Anweisungen was die GPU berechnen soll ab. Der Aufwand dafür hält sich meist in grenzen.
Der Mehraufwand der auch mit modernen Systemen bleibt ist das alles wieder zu synchronisieren.
Wenn man im Singeltread Code einfach x y und z nacheinander berechnet macht man das bei multicore parallel und muss dann aber bevor man dem Spieler eine wie auch immer geartete rückmeldung gibt drauf warten das auch alle fertig sind. Es bringt dem Spieler ja wenig wenn z.B. die GPU das monster schon gezeichnet hat, die Physik dann aber nachher sagt, "nix da, da liegt doch jetzt der dicke Felsen..."
Die von dir genannten Beispiele (ganz besonders die Videobearbeitung) ist für Mehrkern CPUs ideal.
Da muss man ja eh tausende von Einzelbilder berechnen/komprimieren. Das kann man wunderbar parallelisieren indem man jedem Kern ein einzelnes Bild (oder einen Teil davon) gibt und ihn machen lässt. sobald alle Kerne was zu tun haben wartet man bis der erste fertig ist und der bekommt dann das nächste.
Beim Compile ist es auch so, da werden ja in der Regel eine Vielzahl von Dateien und Projektteilen gleichzeitig erstellt und das kann man auch prima verteilen.
Man muss allerdings auch eine Aufgabe haben die sich parallelisieren lässt.
Bei spielen bieten sich da in der Regel komplexe KI oder Physikberechnungen an.
Manchmal noch komplexes Postprocessing von Bildern.
Bei umfangreichen multiplayer Titeln bietet es sich an die ganze Netzwerkkommunikation von einem extra Kern machen zu lassen um die Latenzen zu minimieren.
Das alles kommt in der Schicksalsklinge aber nicht vor.
Die Grafik berechnet eh die GPU, die CPU schickt hier vereinfacht gesagt nur die Anweisungen was die GPU berechnen soll ab. Der Aufwand dafür hält sich meist in grenzen.
Der Mehraufwand der auch mit modernen Systemen bleibt ist das alles wieder zu synchronisieren.
Wenn man im Singeltread Code einfach x y und z nacheinander berechnet macht man das bei multicore parallel und muss dann aber bevor man dem Spieler eine wie auch immer geartete rückmeldung gibt drauf warten das auch alle fertig sind. Es bringt dem Spieler ja wenig wenn z.B. die GPU das monster schon gezeichnet hat, die Physik dann aber nachher sagt, "nix da, da liegt doch jetzt der dicke Felsen..."
Die von dir genannten Beispiele (ganz besonders die Videobearbeitung) ist für Mehrkern CPUs ideal.
Da muss man ja eh tausende von Einzelbilder berechnen/komprimieren. Das kann man wunderbar parallelisieren indem man jedem Kern ein einzelnes Bild (oder einen Teil davon) gibt und ihn machen lässt. sobald alle Kerne was zu tun haben wartet man bis der erste fertig ist und der bekommt dann das nächste.
Beim Compile ist es auch so, da werden ja in der Regel eine Vielzahl von Dateien und Projektteilen gleichzeitig erstellt und das kann man auch prima verteilen.