Warum Single Core Performance immer noch wichtiger in games?

cat_helicopter schrieb:
Der Vergleich ist nicht ganz Korrekt. Er sollte IPC > CPU Takt sein. Kerne haben mit dem IPC per se nichts zu tun.

IPC oder Instruction per Cycle ist ein begriff der Aussagt wie viele Anweisung können pro Zyklus verarbeitet werden. Aber um das genauer zu definieren muss man sich mit der Hardware und den CPU Befehlssatz auseinander setzten.

https://en.wikipedia.org/wiki/Instructions_per_cycle
The calculation of IPC is done through running a set piece of code, calculating the number of machine-level instructions required to complete it

Ein kleines Beispiel vom Assembler (nur 8Bit) aus der FH
MOV AL,15 wird im RAM/ROM z.B. wie folgt als HEX abgelegt: D0 00 15
Dieser Befehl ladet die Konstante 15 in das Register AL.

Für uns sieht es so aus, als würde der Prozessor dies in einem CPU Takt einlesen. Was aber genau geschieht ist wie folgt: Der Prozessor liest in einem Mikro Takt den Wert D0 ein (Opcode Fetch), der Prozessor entscheidet um welchen Befehl es sich handelt und wie die Nachfolgende Werte interpretiert werden müssen. Im nächsten Mikro Takt liesst er den Wert 00 ein (unser Register AL) und erst am Ende (beim letzten Mikro Takt) wird die Konstante 15 in das Register AL geschrieben.
All diese Mikro Takts zusammen ergeben einen CPU Takt. - In diesem Beispiel von oben arbeitet die CPU z.B. mit einem 8 mal höheren Internen Takt.
Als Nutzer der CPU sehen wir aber nicht die Mikro Takts (IPC) sondern nur den CPU Takt.

Wenn man jetzt natürlich viele Instruktionen (gleichzeitig) pro Zyklus verarbeiten kann, erhöht dies auch den CPU Takt (in direkt). Er wird zwar nicht höher in der form von 3GHz zu 4Ghz. Es ist aber ein wesentlichen Unterschied ob du 20 Anweisungen/Instruktionen pro 1Hz Takt ausführen kannst oder nur 2 Anweisungen/Instruktionen pro 1Hz Takt.

Anderst gesagt, wenn Intel CPUs 100 Anweisungen/Instruktionen pro Takt durchführen kann, und AMD CPU "nur" 80 Anweisungen/Instruktionen pro Takt, so ist die Differenz bei 4Ghz (Annahme Intel und AMD CPU haben die gleiche Taktrate) bereits 80 Millionen Anweisungen/Instruktionen, die die Intel CPU zusätzlich verarbeitet können.

Du siehst ein Vergleich von einer CPU AMD und Intel wird sehr schwer, wenn sie nicht die gleiche IPC Werte haben. Daher ist der CPU Takt alleine auch nichts aussagekräftiges mehr.

So ich hoffe ich konnte dir Helfen um das Thema der IPC und CPU Takt besser zu verstehen. Jetzt könnten wir uns noch dem nächsten Punkt widmen mit den CPU Kerne. Ich denke hier haben aber viele bereits etwas dazu geschrieben und wenn erst nach dem Mittag ;)

KlaasKersting schrieb:
Wenn du tatsächlich einen Workflow hast, der am Ende nicht absehbar durch einen Thread limitiert wird, heißt das noch immer nicht, dass es sich finanziell lohnt, teure Entwicklungskosten in Parallelisierung zu versenken.
Er sagt dazu fast alles - zuzüglich bringt die Parallelisierung auch viele gefahren, z.B. Thread Safety! Wenn die Applikation nicht Thread Safe gebaut wurde, darf man fast die ganze Applikation umbauen - Gefahren von Bugs etc.
 
  • Gefällt mir
Reaktionen: cm87, Baal Netbeck und cat_helicopter
IPC is leistung pro takt
intel is da nicht mehr allzuweit vorne
da die cpus aber höher takten ist die leistung auch dementsprechend höher

https://www.techspot.com/article/1616-4ghz-ryzen-2nd-gen-vs-core-8th-gen/

jetz kommts halt noch drauf an wiegut die spiele engine mit den intel oder ryzen eigenheiten im compiler und co umgeht

versuch mal zu streamen und dann schau die fps an ;)
der 7700k arbeitet mehr oder weniger am limit

wenn noch was nebenzu läuft wirst das bei den FPS merken
der ryzen hat mehr kerne als benötigt, kann daher nebenzu noch was machen

was hast denn für RAM? 3200er aufwärts is für ryzen sehr gut
 
Zuletzt bearbeitet:
@playthestation

Geballte Kompetenenz in deinem Post.

Ich find sehr wohl, dass sich viele User bei Computerbase Mühe geben differenzierte und sehr gute Antworten zu geben. Und selbst wenn es ein Fanboy ist, erscheint mir so ein Beitrag deutlich produktiver als deiner.
Aber vermutlich bin ich nur zu doof das zu verstehen :)

Ich bin jedem User dankbar der versucht was sinnvolles zum Verständnis beizutragen.
 
@playthestation
BTW kann man nur noch Anfügen, wir alle sollten jetzt erst mal ca ein Jahr warten. Da Intel endlich nachgezogen hat und auf der Consumer Plattform ebenfalls 6 und 8 Core CPU veröffentlicht hat, wird die multi-core CPU Unterstützung bald besser aussehen. Davor gab es ja für die Spieleentwickler nicht genug Anreiz für eine bessere Unterstützung. Knapp 60% der verwendeten CPUs (unter Windows) im Gamingbereich sind gemäss Steam 4 Cores CPUs.
https://store.steampowered.com/hwsurvey/cpus/

2 Cpus 28%
4 Cpus 58%
6 Cpus 9%
8 Cpus 1.4%
 
Kenny [CH] schrieb:
@playthestation
Knapp 60% der verwendeten CPUs (unter Windows) im Gamingbereich sind gemäss Steam 4 Cores CPUs.
https://store.steampowered.com/hwsurvey/cpus/
2 Cpus 28%
4 Cpus 58%
6 Cpus 9%
8 Cpus 1.4%
Viel krasser finde ich, dass knapp 90% 4 Kerne oder weniger haben.
Man sieht halt immer wieder, dass das CB-Forum nicht der Nabel der PC-Welt ist.

Es sind halt wirklich viele auf alten i5 oder Pentiums unterwegs, gepaart mit ner 750ti oder 6 Jahre alten Midrange-Radeons. Das ist die Realität.
 
Dandelion schrieb:
Es sind halt wirklich viele auf alten i5 oder Pentiums unterwegs, gepaart mit ner 750ti oder 6 Jahre alten Midrange-Radeons. Das ist die Realität.

Das meiste werden Notebooks mit i3 und i5 sein, die dann zwei Kerne und 4 Threads haben.
 
Das ist grundsätzlich ja kein Problem mit der Entwicklung. Klar kann man bei der Entwicklung darauf achten mehrere Kerne zu nutzen aber: Das was der Gamer will und in was er misst, nämlich möglichst viel FPS, ist nun mal im Idealfall eine Echtzeitberechnung. Diese lassen sich aber nur sehr schwer parallelisieren.

Was passiert wenn man Dinge wie Spiele mit Gewalt parallelisieren will sieht man ja an den ganzen SL/CF Problemen wunderbar.
Alles was du zerhackst und parallel rechnen lässt, musst du am Ende irgendwie auch wieder zusammensetzen. Alleine schon das zerhacken und zusammen fügen kostet Zeit, welche du aber nicht hast wenn dein Ziel maximale frames per second sind.

Würdest du den Weg durch ein CoD Level fest definieren incl. aller Blinkwinkelwechsel kannst du das natürlich auch auf 64 Cores parallel berechnen.
Da du dich ja aber beim spielen konstant durch die Welt bewegst und das Spiel nicht weiß was du als nächstes machen willst, muss die Engine eben auf den Userinput reagieren und dann möglichst schnell anworten. Und bei schnell sind wir wieder beim Thema Echtzeit.
 
Grimba schrieb:
Du hast in Spielen ja viel Ursache->Wirkung. Also deine Spielfigur tut was, dannach passieren dann weitere Dinge usw.

Du musst halt immer auch den Zeitfaktor sehen. Du kannst theoretisch auf den Kernen gleichzeitig rechnen. Die Frage ist nur, wann wird das Ergebnis gebraucht? Oder braucht vielleicht ein Job auf Kern 3 Ergebnisse vom Job auf Kern 4 usw.?
Sprich: In der Programmlogik wirst du immer Programmteile haben, die aufeinander warten.

Mit einer hohen SingleCore Leistung ist dann halt der Job auf dem Kern schneller fertig, d.h. kürzere Wartezeit für andere Jobs, egal ob die auf dem selben Kern liegen oder auf einem anderen. Eine höhere Kernanzahl ist hier also nicht von größter Bedeutung.

Wenn du jetzt aber die Situation hast, dass es egal ist, wann ein Kern mit seiner Rechnung fertig ist, sondern nur irgendwann alle Ergebnisse vorliegen müssen (z.B. Video Encoding), dann sparst du sofort mit jedem weiteren Kern mehr Zeit, weil mehr gleichzeitig arbeiten können.

Da die schiere Möglichkeit, ob groß parallelisiert werden kann oder nicht, sehr von der Spiellogik abhängt, und das auch nicht gerade ein Schalter ist, den man umlegt, sondern eine knifflige Designfrage, liegt hier häufig der vermeindlich einfachere Weg auf einem Kern näher.
Daher wird SingleCore Leistung nie unwichtig werden. Gerade in Spielen nicht.


Fantastisch erklärt. Danke dir!
 
Zurück
Oben