Diskussion zu: Zur Performance von Core i7-7960X & -7980XE

[Leonidas]

Link zum Artikel:
https://www.3dcenter.org/artikel/zur-performance-von-core-i7-7960x-7980xe

[AMDoderNvidia]

Mal eine simple Frage zum Thema Overclocking dieser CPUs: Warum kann man die so locker Richtung 4.6-5 GHz übertakten und warum ist die Vcore dann immer noch im Bereich 1,2x Volt?

Ich habe einen Haswell-E und muss für 4,5 GHz das Ding in Richtung 1,4 Volt prügeln (hallo Wasserkühlung!) und der IMC ist absoluter Schrott, denn alles über den spezifizierten DDR4-2133 bringt meine CPU recht schnell zum Absturz beim OC.

[MrSpadge]

Ausgereifter 14 nm Prozess und tatfreudiger Skylake-Kern. Dazu sicher ein auf hohen Takt (und hohen Verbrauch) physisches Layout (welchen Transistor wo verwendet). Welchen Einfluss letzteres hat, sieht man z.B. an Broadwell-C, der zwar auch im 14 nm Prozess kam, aber stromsparend ausgelegt und weniger takfreudig war.

Edit: der 12-Kerner könnte zum Übertakten die "beste" SKL-X CPU sein, da er die größte Kühlfläche pro Kern hat. Auch die Speicherbandbreite pro Kern sieht dort noch besser aus als bei den größeren Modellen. Und nicht zu vergessen weniger Ärger mit Herrn Amdahl (https://de.wikipedia.org/wiki/Amdahlsches_Gesetz).

MrS

[Iscaran]

@MrSpadge:

Schau dir lieber Herrn Gustafson (https://de.wikipedia.org/wiki/Gustafsons_Gesetz) an (auch als pdf (http://users.ece.gatech.edu/~leehs/ECE6100/papers/p532-gustafson.pdf) zu empfehlen wenn man englisch kann.

Der hat nämlich 30 Jahre nach Amdahl mal untersucht wie sich das in realen Applikationen verhält und findet dass das Speed-Up nach Amdahl den tatsächlichen Speed-Up stark unterschätzt.

In der Realität kann man eben doch z.T. 40-80% der Taskleistung parallelisieren. Aber selbst wenn der Wert nur 10% ist ist der Speed-Up in der Realität immer noch größer als von Amdahls maximal WORST CASE szenario vorhergesagt.

[Gast]

Schau dir lieber Herrn Gustafson (https://de.wikipedia.org/wiki/Gustafsons_Gesetz) an (auch als pdf (http://users.ece.gatech.edu/~leehs/ECE6100/papers/p532-gustafson.pdf) zu empfehlen wenn man englisch kann.



Das Problem mit Herrn Gustafson ist allerdings, dass er von der Grundannahme ausgeht, dass sich Problemgrößen beliebig vergrößern lassen.
Für Probleme auf die das auch zutrifft sind aber hochparallele Vektorrechner wie z.B. GPUs wesentlich effizienter.

Der Sinn von CPUs mit derart vielen Kernen ist damit am Desktop stark begrenzt.

Wir haben einerseits Probleme die sich gut parallelisieren lassen. Für diese sind GPUs aber eben wesentlich besser geeignet.

Dann haben wir Probleme mit signifikantem sequentiellen Anteil, für welche die vielen CPUs auch nicht hilfreich sind.

Für die CPUs mit vielen Kernen bleibt nur die Nische, wo viele unabhängige Probleme parallel abgearbeitet werden sollen und dabei auch noch eine möglichst kurze Antwortzeit wünschenswert ist. Das ist nämlich die Schwäche von Vektorrechnern, wann genau ein spezifisches Problem fertig bearbeitet ist lässt sich schlecht vorhersagen und ist zudem immer wesentlich später als mit einer CPU.
Dieses Anwendungsgebiet hat man beispielsweise auf Datenbankservern oder ähnlichem, aber kaum am Desktop.

[Iscaran]

Ja. Gustafsson geht davon aus dass reale Probleme eher so "groß" gewählt werden dass die Zeit um diese zu berechnen der limitierende Faktor ist.

Ein CPU-Cache ist wenige MB groß. Der micro-Op cache noch viel kleiner...

Diese Menge an Befehlen ist also de-facto nicht weiter "parallelisierbar"...

Ein Reales programm ist heutzutage aber oft einige GB groß...was meinst du in wie viele "kleine" paralellelisierbare unterprobleme man so etwas "im idealfall" unterteilen kann ?

Herr Gustafsson hat außerdem Benchmarks mit 3 Unterschiedlichen Problemen an einem 1024 CPU-Cluster durchgeführt und mit ein paar Tweaks eine "parallelisierbarkeit" seiner Probleme von 40 bis 80% erreicht. Mit entsprechend skalierendem Speed-up.

Herr Amdahl hat nur theoretisch beschrieben dass man bei "sehr kleinen" Problemen in der Tat sehr schlecht parallel skalieren kann. (Womit wir wieder beim micro-op cache) der CPU sind.
In erster Näherung gilt Amdahl also genau DANN wenn das Problem so klein ist dass es vollständig in den CPU cache einer einzelnen CPU passt. Dann sieht man auch mit 1000 dieser CPUs quasi KEIN Speedup.

Herr Gustafsson hat das in den 90er Jahren mal etwas analysiert und festgestellt das dieses Worst case Szenario mit realer Software eigentlich nicht existiert.

EDIT: Die latenzen die du oben ansprichst sind bei "sehr vielen kleinen" Task aber sehr gering so dass man sehr viele davon erstmal parallel loslaufen lassen kann und im worst case muss dann der eine oder andere Nachfolgethread ein paar micro bis mili sekunden warten bis es weiter geht.

Wie gesagt Gustafsson hat ja im Gegensatz zu Amdahl auch mal praktische Messungen gemacht - mit dem Publizierten Ergebnis.
Auch im Desktop-Bereich und selbst wenn ich nur 1 Programm laufen habe, so kann man sehr vieles davon ja auch parallelisieren...sofern die Software etwas mehr macht als nur auf den Input des Users zu warten.

[Gast]

Ja. Gustafsson geht davon aus dass reale Probleme eher so "groß" gewählt werden dass die Zeit um diese zu berechnen der limitierende Faktor ist.

Genau diese Probleme lassen sich aber auf einer GPU noch um ein vielfaches schneller berechnen.

Warum ein Problem das mit Leichtigkeit 1000-fach parallelisierbar ist auf einer CPU mit 2-Stelligen Kernzahlen berechnen wenn ich es auf einer GPU mit 4-Stelligen Kernzahlen berechnen kann? (Ja ich weiß man kann CPU-Kerne und "GPU-Kerne" nicht 1:1 vergleichen, aber was die Parallelisierbarkeit stimmt das sehrwohl, während eine GPU gleichzeitig irgendwas im Bereich 20-30 Threads gleichzeitig bearbeiten kann, kann eine GPU 1000de Threads gleichzeitig bearbeiten)


Ein CPU-Cache ist wenige MB groß. Der micro-Op cache noch viel kleiner...


Es wäre so ziemlich das einfachste, Caches weiter zu vergrößern, bringt aber real defacto zu wenig.


Ein Reales programm ist heutzutage aber oft einige GB groß...was meinst du in wie viele "kleine" paralellelisierbare unterprobleme man so etwas "im idealfall" unterteilen kann ?

Reale Programme, und mit Programm meine ich hier den ausführbaren Maschinencode sind auch heutzutage immer noch recht klein und nicht mehrere GB groß.
Wenn man jetzt noch im Programmcode jene Teile betrachtet die >99% der Arbeit erledigen hat man oft wirklich nur einige KB bis MB.
Was Programme groß macht sind die verwendeten Assets, nicht der Code selbst.



Herr Gustafsson hat außerdem Benchmarks mit 3 Unterschiedlichen Problemen an einem 1024 CPU-Cluster durchgeführt und mit ein paar Tweaks eine "parallelisierbarkeit" seiner Probleme von 40 bis 80% erreicht. Mit entsprechend skalierendem Speed-up.

Nur warum einen 1024 CPU-Cluster verwenden, wenn es genauso gut eine Hand voll GPUs sein könnten, bei geringerem Flächenbedarf und wesentlich geringerer Leistungsaufnahme.

Ich weiß schon, als Herr Gustafson seine Benchmarks gemacht hat, gab es diese noch nicht.
Aber heute gibt es GPUs und evtl. noch andere Spezialrechner, die hochparallele Aufgaben wesentlich effizienter abarbeiten können als CPUs.

[Iscaran]

Naja. Wie du meinst.

Aber die Annahmen von Amdahl sind alle zu 100% korrekt und zutreffend auf die Situation ja ? Aber die von Gustafsson gefundene Abweichung von Amdahls-Prognose ist nach deiner Ansicht also irrelevant ?

Na also wenn du mich fragst liegt die Wahrheit dann wohl mindestens irgendwo dazwischen. Mehr wollte ich eigentlich gar nicht feststellen.

[Gast]

Aber die Annahmen von Amdahl sind alle zu 100% korrekt und zutreffend auf die Situation ja ? Aber die von Gustafsson gefundene Abweichung von Amdahls-Prognose ist nach deiner Ansicht also irrelevant ?



Beide sind korrekt und beide widersprechen sich auch nicht wirklich.

Gustafson zeigt lediglich, dass es reale Probleme geben kann in denen der sequentielle Anteil hinreichend klein ist, dass die Limitierung von Amdahls Gesetz in der Realität in der Praxis keine großen Auswirkungen hat.

Bestes Beispiel wären Grafikberechnungen. Auch wenn du mit doppelt so vielen "Grafikprozessoren" nicht unbedingt die gleiche Grafik doppelt so schnell berechnen kannst, so kannst du damit (annähernd) doppelt so viele Pixel in der selben Zeit berechnen.

Und damit kommen wir zu dem Problem was ich schon seit unzähligen Posts erklären versuche, nämlich dass die Sinnhaftigkeit dieser CPUs relativ begrenzt ist.

Für die Probleme die Amdahl aufzeigt bringen >10 Kerne nicht mehr wirklich was.

Die Probleme die Gustafson gezeigt hat lassen sich wesentlich effizienter auf GPUs berechnen (wie logischerweise auch mein Beispiel der Grafikberechnung)

Natürlich gibt es dazwischen noch eine Nische, die nicht gut für GPUs geeignet ist und trotzdem von >10 CPUs noch signifikant profitiert.

Diese Nische wird in den meisten Desktopanwendungen aber nicht sichtbar sein und ist hauptsächlich in Serveranwendungen vorhanden.

[MrSpadge]

Aber die Annahmen von Amdahl sind alle zu 100% korrekt und zutreffend auf die Situation ja ? Aber die von Gustafsson gefundene Abweichung von Amdahls-Prognose ist nach deiner Ansicht also irrelevant ?
Nichts davon hat er gesagt und vermutlich auch nicht gemeint. Es kam eher dein Post so rüber, als wärst du 100%ig von Gustafsson überzeugt. Unser Gast hat IMO gut argumentiert, dass Probleme die Gustafsson perfekt lösen kann heute nicht mehr so relevant für CPUs sind wie früher. Demnach liegt auch bei ihm die Wahrheit zwischen den Beiden - an welcher Stelle genau bestimmt der jeweilige Algorithmus bzw. Code.

MrS