8Kern Prozessor fast so schnell wie 16Kern

1kane

Newbie
Registriert
März 2020
Beiträge
2
Warum ist ein 16kern Prozessor nicht doppelt so schnell (+100%) wie ein 8 kerner bei gleicher Taktrate

Wenn ich mir Benchmarks von Prozessoren anschaue in denen Programme getestet werden welche Multi-Core support bieten dann bringt die höhere Anzahl an Kernen bei gleichem Takt meist nur wenige Prozent mehr Leistung.

Als Beispiel amd ryzen 7 3700 vs ryzen 9 3950

Womit hängt das denn Zusammen? Sind die Programme so schlecht programmiert oder die Prozessoren so dumm zusammengebaut(Kommunikation der Cores) dass mehr Kerne bei gleichem Takt nichts bringen?

Was rechtfertigt denn dann den viel höheren Preis wenn in der Praxis nur minimale Unterschiede feststellbar sind?
Oder hab ich hier einen Denkfehler? Die Taktrate z.b. 3,5GHZ bezieht sich doch auf einen einzelnen Kern?
 
Wenn das Programm nur max 8 Kerne unterstützt kann der 16 Kerner nicht bzw nur ganz minimal schneller sein, da Windows ja auf den "freien" 8 Kernen läuft. Und der Prozessor der nur 8 Kerne hat muss Windows ja noch mit stemmen.

Und der Preis ist damit gerechtfertigt das wenn du damit arbeitest und 16 Kerne auslastest doppelt so schnell bist wie mit nur 8 Kernen.
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Das Stichwort ist "Parallelisierung".

Ja. Spiel X läuft auf einem 16-Kerner auch nicht besser. Dafür kann ich neben Spiel X vielleicht noch easy Task A, B und C laufen lassen, ohne das die Performance von Spiel X einbricht.
Bei einem 8-Kerner würde sie dagegen einbrechen.
 
  • Gefällt mir
Reaktionen: K3ks
Nicht alle Aufgaben lassen sich beliebig parallelisieren und damit viele Kerne nutzen. Gut geht das z.B. beim Rendering oder Encodieren von Videos dort gibt es ein fast lineares Wachstum der Perfomance bis etwas anderes zum Flaschenhals wird.
Es hängt also immer davon ab was du mit dem Rechner machen willst, Benchmarks sind nicht alles.
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Nicht jede Aufgabe lässt sich unendlich parallelisieren.

Braucht ein einzelner Handwerker 1 Jahr um ein Haus zu bauen, schaffen es 365 Handwerker trotzdem nicht in einem Tag ;-)
 
  • Gefällt mir
Reaktionen: TorenAltair, bikerider, Kailix und 5 andere
1kane schrieb:
Wenn ich mir Benchmarks von Prozessoren anschaue in denen Programme getestet werden welche Multi-Core support bieten dann bringt die höhere Anzahl an Kernen bei gleichem Takt meist nur wenige Prozent mehr Leistung.
Es sind z.B. bei HandBrake 65% mehr.

Hier mal ein Test, der auf das eigentliche Szenario von mehr als acht Kernen eingeht:
AMD Ryzen 9 3950X und 3900X im Workstation-Test gegen Intels Skylake X, Coffee Lake und natürlich sich selbst im 65-Watt-Eco-Mode | Igor'sLAB
1kane schrieb:
Womit hängt das denn Zusammen?
Jeder parallele Prozess/Thread muss auch wieder synchronisiert werden. Daher auch der Schluss, dass sich eine Aufgabe nicht beliebig parallelisieren lässt. Es kommt an den Punkt, wo die anderen Prozesse/Threads abgearbeitet sind und dennoch gewartet werden muss. Zu beachten ist auch das kein Deadlocks auftreten. Das Ganze kann sehr komplex werden.
1kane schrieb:
oder die Prozessoren so dumm zusammengebaut(Kommunikation der Cores) dass mehr Kerne bei gleichem Takt nichts bringen?
Die Aufteilung auf die Kerne/Thread übernimmt der Scheduler des Betriebssystems, und, wie soll ich es jetzt schreien, kurz und knapp, der von Windows ist nicht gut.
 
Zuletzt bearbeitet:
1kane schrieb:
Oder hab ich hier einen Denkfehler?
Single Core/Tread -> Programm kann nur auf einem Kern ausgeführt werden

Multi C/T -> Programm kann auf mehr als einem Kern ausgeführt werden. Wie weit sich die Aufgabe zerlegen lässt, ist unterschiedlich.
Das können zwei Threads sein, 4, 6, 8, 1365...
Wenn jemand ein Programm benutzt, das über dementsprechend viele Threads skaliert, dann ist ein 3950x auch (taktbereinigt) doppelt so schnell wie ein 3700X.
 
Ich hätte mich über Eigeninitiative und Eigenrecherche gefreut, die Frage ist nicht neu.

Wenn nichts limitiert weil Resourcen geteilt werden müssen und die Aufgaben perfekt skalierbar sind dann ist der Prozessor mit doppelter Kernanzahl auch doppelt so schnell (wenn Architektur und Takt gleich sind und kein Flaschenhals blablabla etc.), minus dem Verwaltungsaufwand für die Aufteilung. "Jürgen, du machst x, Hanna, du machst y, Peter, Max, Marina, Sandra, Nina, ihr geht nach Hü und macht Hott und ich mach..." <- Zeit für die Koordination verbraten.

Du hast nicht auf die "richtigen" Programme geschaut, siehe #3.

Was rechtfertigt denn dann den viel höheren Preis wenn in der Praxis nur minimale Unterschiede feststellbar sind?
Denkfehler, für Aufgabe x keine Mehrleistung oder vlt. sogar Verlust, für y marginalen Gewinn und für z massive Mehrleistung. Wofür brauche ich eine Brotsäge für meine Garnelen? Passendes Werkzeug für jede Aufgabe, nichts anderes sind Computer oder Autos (Dingens bringt einen von a nach b ^^).

Wenn ein Handwerker 12 Tage braucht, brauchen dann 12 Handwerker einen Tag? Vlt.? Vlt. deutlich weniger? Vlt. brauchen die trotzdem 2-3 Tage. Vlt. müssen die eh auf den Zement und den Zimmermann warten der Tag 5 oder 4 kommt, vlt. muss x erst härten oder montiert werden....

Dann gibt es auch noch andere witzige Sachen wie Sprungvorhersage.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: kachiri und H3llF15H
Stichwort: Amdahlsches Gesetz.

Und wenn Zeit Geld ist, kann sich die "teure" Mehrleistung durchaus lohnen.
 
  • Gefällt mir
Reaktionen: K3ks
Vielen Dank, das ist sehr einleuchtend. Die Testst die ich mir angesehen habe wurden also mit Programmen gemacht die nicht für mehr als 8 Kerne optimiert sind. Das war irgendwie nicht ersichtlich.

Dann sag ich mal Sorry für die dumme Frage 😞
 
  • Gefällt mir
Reaktionen: Wintermute, H3llF15H und K3ks
Hauro schrieb:
Es sind bei HandBrake 65%.

Jeder parallele Prozess/Thread muss auch wieder synchronisiert werden.

Es ist eher so, daß gewisse Aufgaben leicht parallelisierbar sind, andere je nach Programmierung entweder parallel oder seriell abgearbeitet werden können und wiederum andere sehr schlecht parallelisierbar sind.

Graphische und geometrische Berechnungen sind z.B. meist gut parallelisierbar, Core 1 kümmert sich um um Objekt 1, Core 2 um Objekt 2 usw.

Wohingegen bei Officeprogrammen häufig Teilaufgaben so voneinander abhängig sind, daß sie nicht ohne Wartezeiten auf verschiedene Recheneinheiten verteilt werden können (siehe Beispiel Baustelle: man kann nicht den Dachstuhl bauen, wenn das Kellerfundament noch nicht gegossen ist.).

Deswegen ist die entscheidende, korrekte Frage nicht: Was ist der beste Prozessor, sondern: Was ist der beste Prozessor für die Programme, die ich verwenden will.

Für Gamer ist dann z.B. eine Ryzen 3700 finanziell sinnvoller als 400 Euro mehr für einen Ryzen 3950 auszugeben. Zumal man bedenken muß, daß ich mit den gesparten 400 Euro das System ggf. an anderer Stelle schneller machen kann. Für Videoschnitt sieht dann die Überlegung ggf. ganz anders aus.
 
  • Gefällt mir
Reaktionen: pvcf und K3ks
Es gibt keine dummen Fragen (naja...) nur einen Mangel an Eigeninitiative ;):D. Selbst ist der Mann die Frau der Mensch. Wie erwähnt, je nach Aufgabe brauch man ein anderes Werkzeug. In dem Fall vlt. einen Daddelprozessor und in dem anderen einen Ryzen-Bomber. Entschuldigt mich nun, ich werde meine 1-2cm Eismeergarnelen mit einer 20cm Brotsäge ausweiden.... :freak:
 
Neben dem Problem das sich nicht alles beliebig parallelisieren lässt und je mehr Synchronisierung nötig ist, umso schlechter geht dies gewöhnlich, gibt es noch das Problem der durch die höhere Leistungsaufnahme bei Last auf vielen Kernen unter Last oft geringer ausfallenden Taktraten. Man erfährt bei den Reviews leider meistens nicht mit welchem Takt eine CPU bei einem konkreten Benchmark lief, aber i.d.R. ist der Takt eben gering je mehr Kerne unter Last laufen. Dies führt auch dazu, dass die Leistung nicht linear mit der Anzahl der Kerne steigt und ein dritter möglicher Effekt könnte, je nach Anwendung, die RAM Bandbreite sein. Aber selbst wenn die Bandbreite noch ausreicht, so kommt es zu Verzögerungen bei den RAM Zugriffen, je mehr Kerne darum konkurrieren.
 
Masamune2 schrieb:
Nicht alle Aufgaben lassen sich beliebig parallelisieren und damit viele Kerne nutzen. Gut geht das z.B. beim Rendering oder Encodieren von Videos dort gibt es ein fast lineares Wachstum der Perfomance bis etwas anderes zum Flaschenhals wird.
Es hängt also immer davon ab was du mit dem Rechner machen willst, Benchmarks sind nicht alles.


Kommt da aber auch drauf an. Ich habe gelesen das es beim H264 Pass 1 auf die Eigenschaften der CPU ankommt. Was auch immer das heißen mag. Und beim pass 2 kommt es dann auf einmal auch auf cache und RAM Bandbreite an.
Aber was heißt denn Eigenschaften der CPU, sind damit die Beschleuniger Einheiten wie z. B avx gemeint oder die archetektur. Oder ist es gar was anderes? Cache kann es ja eben nicht sein oder?
Ergänzung ()

Hauro schrieb:
Es sind z.B. bei HandBrake 65% mehr.

Hier mal ein Test, der auf das eigentliche Szenario von mehr als acht Kernen eingeht:
AMD Ryzen 9 3950X und 3900X im Workstation-Test gegen Intels Skylake X, Coffee Lake und natürlich sich selbst im 65-Watt-Eco-Mode | Igor'sLAB

Jeder parallele Prozess/Thread muss auch wieder synchronisiert werden. Daher auch der Schluss, dass sich eine Aufgabe nicht beliebig parallelisieren lässt. Es kommt an den Punkt, wo die anderen Prozesse/Threads abgearbeitet sind und dennoch gewartet werden muss. Zu beachten ist auch das kein Deadlocks auftreten. Das Ganze kann sehr komplex werden.

Die Aufteilung auf die Kerne/Thread übernimmt der Scheduler des Betriebssystems, und, wie soll ich es jetzt schreien, kurz und knapp, der von Windows ist nicht gut.
Was für ein Ding, deadlocks was ist das denn? Was passiert da und was macht sowas also geht dann der PC aus oder berechnet dieser etwa dann alles falsch?
 
Zuletzt bearbeitet:
latiose88 schrieb:
Was passiert da und was macht sowas also geht dann der PC aus oder berechnet dieser etwa dann alles falsch?
Wenn die Software gut programmiert ist, wird der Vorgang mit einer Fehlermeldung abgebrochen, da der Prozess nicht korrekt beendet werden kann. Andernfalls hängt sich der Prozess auf. Falls es dazu kommt, muss dieser über den Task-Manager beendet werden. Auf die CPU hat dies keinen Einfluss.

Systeme I: Betriebssysteme Kapitel 6 Deadlocks | ais.informatik.uni-freiburg.de
 
Zuletzt bearbeitet:
Zurück
Oben