C0B schrieb:
Das ist pures Pseudo-Wissen.
Ohne Programmierkenntnisse rede bitte nicht über Code Splitting.
Dazu sag ich jetzt mal nix. Dafür habe ich schon zu viel Zeit an zu vielen "Experten" verschwendet, um ihnen meine Sichtweise zu erklären. Ich habe bewusst die Sache sehr vereinfacht und ich weiß genug über Parallelisierung, um die Finger davon zu lassen, wenn es nicht wirklich notwendig ist, sie zu benutzen.
Und die CPU übernimmt eben nicht immer die Hauptlast bei Spielen. Ist natürlich auch abhängig von API (DirectX, OpenGL, Mantle), dem jeweiligen Part (Physik, Grafik, Sound, Spiellogik, Netcode etc pp) und einfach auch vom Programmierer. Die Sache ist halt nur die, dass wenn ich mir die Mühe mache und versuche 8 oder 16 Threads zu füttern, dann suche ich mir Teile aus, die eh gut zu parallelisieren sind. Und dann kann ich auch gleich den Schritt zu Many-Core machen und die GPU anzapfen. Und die ist der CPU halt um den Faktor 10 überlegen. Jetzt mal ganz unabhängig davon, ob es sich um Spiele handelt. Beispiel: Folding at Home. Hier werden fast nur noch GPUs verwendet.
Wieder zu viel vereinfacht, ich weiß. Und meinetwegen auch Äpfel mit Birnen verglichen. Aber jetzt komm bitte nicht wieder damit, dass die CPU eh alles vorberechnet. Ich kann mich noch gut an die Zeit ohne 3D-Beschleuniger erinnern, als die CPUs alles übernommen hatten und schon bei den Matrixmultiplikationen überfordert waren, die nötig waren, um ein paar perspektivisch korrekte Linien (ohne Texturen!) auf den Bildschirm zu zaubern. Und das wird spätestens seit TnL zum großen Teil von der Grafikkarte übernommen. Und schonmal Shader programmiert, die von der CPU verarbeitet werden? Nein? Also.
Es gibt halt auch Aufgaben, die gar nicht oder extrem schlecht zu parallelisieren sind. Und hier lautet die Devise: Single-Core-Performance. Und jetzt rate mal, welche Prozessoren da die Nase vorn haben... kleiner Tipp: es sind nicht die FX-Prozessoren von AMD...