Core i7-7800X: Ist der AVX512-Durchsatz beim Retail-Modell halbiert?

PCGH-Redaktion

Kommentar-System
Teammitglied
Jetzt ist Ihre Meinung gefragt zu Core i7-7800X: Ist der AVX512-Durchsatz beim Retail-Modell halbiert?

Intels Skylake-X-CPUs für den Sockel 2066 haben einen durchwachsenen Start hingelegt. Hinzu kommen Gerüchte, dass die Sechs- und Achtkerner Core i7-7800X und Core i7-7820X nur über halbierten AVX512-Durchsatz verfügen sollen. PC Games Hardware hat mit einem seit Kurzem in der Redaktion befindlichen Retail-Exemplar den Test gemacht.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

lastpost-right.png
Zurück zum Artikel: Core i7-7800X: Ist der AVX512-Durchsatz beim Retail-Modell halbiert?
 
Fürs Spielen hätte es (leider) 0 unterschied gemacht.
Wie auch im Artikel erwähnt -AVX gibt es leider bei so gut wie keinem Spiel, dabei kann es in vielen Szenarien zu absurd hohen Verbesserungen führen.
Von SSE zu AVX und von AVX zu AVX2 kann man jeweils mit gut 50-70% Performancegewinn rechnen, bei AVX3 (AVX512) nochmal etwas das selbe. Das ist für Sachen wie Skeletanimationen, Kamerabmanipulation oder Physikengine recht hilfreich.

Oder man kann es auch so sehen, nehmen wir einen 4 GHz Quadcore an.
'normale' float-operationen - 4GHz*4 kerne = 16 GFlops
Nehalem SSE4 - 4 FLOPS pro Taktzyklus, also 64 GFlops (SSE wird meist unterstützt).
Haswell AVX2 - 16 FLOPs pro Taktzyklus - macht 256 GFlops.

AVX2-Einheiten sind aber meist etwas niedriger getaktet, deshalb sind es in der Regel nur ~60% und nicht 100% Leistungssteigerung, das selbe dann auch für AVX512.
Wäre wirklich schön wen sowas nicht nur von Rendersoftware genutzt wird.
 
Fürs Spielen hätte es (leider) 0 unterschied gemacht.
Wie auch im Artikel erwähnt -AVX gibt es leider bei so gut wie keinem Spiel, dabei kann es in vielen Szenarien zu absurd hohen Verbesserungen führen.
Von SSE zu AVX und von AVX zu AVX2 kann man jeweils mit gut 50-70% Performancegewinn rechnen, bei AVX3 (AVX512) nochmal etwas das selbe. Das ist für Sachen wie Skeletanimationen, Kamerabmanipulation oder Physikengine recht hilfreich.

Oder man kann es auch so sehen, nehmen wir einen 4 GHz Quadcore an.
'normale' float-operationen - 4GHz*4 kerne = 16 GFlops
Nehalem SSE4 - 4 FLOPS pro Taktzyklus, also 64 GFlops (SSE wird meist unterstützt).
Haswell AVX2 - 16 FLOPs pro Taktzyklus - macht 256 GFlops.

AVX2-Einheiten sind aber meist etwas niedriger getaktet, deshalb sind es in der Regel nur ~60% und nicht 100% Leistungssteigerung, das selbe dann auch für AVX512.
Wäre wirklich schön wen sowas nicht nur von Rendersoftware genutzt wird.
Stimmt (fast) alles, es sollte aber angemerkt werden, dass sich AVX nicht in allen Fällen lohnt, und (eher seltene) ausschließlich serielle Rechnungen können damit auch nicht beschleunigt werden.

Der Grund warum das kein Spiel unterstützt ist ein anderer: Jede CPU, die AVX unterstützt, hängt in Spielen ohnehin im Grafiklimit. Die CPUs, für die sich eine Beschleunigung lohnen würde unterstützen den Befehlssatz nicht. Es würde also Optimierungsaufwand (=Zeit=Budget) erfordern, der sich lediglich in Benchmarks auszahlen würde.
 
Danke, dass du durchgehalten hast! :)

Haha, gern geschehen. So wird es ja auch ein bisschen spannender zu lesen und man lernt gleichzeitig was.
Bei jedem Artikel würde ich das aber nicht machen, bei so einem passt es aber gut.

Jetzt muss ich mich aber über AVX512 informieren gehen... ;< ... oder die tollen Beiträge der anderen User lesen! Cooler Tag heute (nur in der Arbeit reisse ich nicht viel) :D
 
Der Grund warum das kein Spiel unterstützt ist ein anderer: Jede CPU, die AVX unterstützt, hängt in Spielen ohnehin im Grafiklimit.
Der Grund dürfte viel eher sein, dass man sich nach wie vor nicht auf AVX-Support verlassen kann (Nehalem, Phenom II, und bei den ganzen Pentium-CPUs der letzten Jahre wurde es auch deaktiviert) und es nicht ganz trivial ist, mal eben mehrere Versionen einer Funktion zu generieren und dann zur Laufzeit die richtige auszuwählen. Gewisse Toolchains können das zwar (und sind dabei nicht immer ganz herstellerneutral, hallo Intel), aber bei anderen schaut man wahlweise in die Röhre oder muss so viel Hand anlegen, dass man auch gleich von Hand in Assembler programmieren kann.

Und ja, dass es sich einfach nicht immer lohnt, ist auch ein Punkt. Zumal Spiele auch nicht ausschließlich aus FPU-lastigen Workloads bestehen, die von der zusätzlichen Registerbreite profitieren würden. Und ganz ehrlich, wenn irgendwas von AVX-512 gegenüber AVX-256 wirklich stark profitiert, muss man sich fragen, ob die Arbeit nicht vielleicht besser von der GPU erledigt werden könnte (AVX-256 macht ja insofern noch Sinn, als dass man da vier 64-Bit-Floats gleichzeitig verarbeiten kann).
 
Also AVX2 zu nutzen ist nicht sonderlich viel aufwand und ein auf SSE zurückfallen sollte bei eigentlich jeder CPU funktionieren. Skelet-animation oder interaktive Physik, Objekttransformationen, Kameras - das sind alles einfache Matrix-Operationen und können mit AVX2 beschleunigt werden.
Weniger CPULast macht auch die FPS gleichmäßiger.
 
Der Grund dürfte viel eher sein, dass man sich nach wie vor nicht auf AVX-Support verlassen kann (Nehalem, Phenom II, und bei den ganzen Pentium-CPUs der letzten Jahre wurde es auch deaktiviert) und es nicht ganz trivial ist, mal eben mehrere Versionen einer Funktion zu generieren und dann zur Laufzeit die richtige auszuwählen. Gewisse Toolchains können das zwar (und sind dabei nicht immer ganz herstellerneutral, hallo Intel), aber bei anderen schaut man wahlweise in die Röhre oder muss so viel Hand anlegen, dass man auch gleich von Hand in Assembler programmieren kann.

Naja, so schwer ist das jetzt aber auch nicht. Prinzipiell muss man "nur" alle rechenintensiven Funktionen in eine Bibliothek auslagern, und diese dann zweimal implementieren: Einmal mit AVX, und einmal ohne. Je nachdem welchen Compiler man nutzt macht der die Vektorisierung sogar automatisch, auch wenn das meist nicht ganz optimale Ergebnisse liefert.

Dann muss nur noch zur Laufzeit prüfen ob AVX unterstützt wird oder nicht, und die passende Version der Bibliothek nachladen.

Wie gesagt, es lohnt sich einfach nur nicht. Würde ein Hersteller ein wirklich CPU intensives Spiel entwickeln (muss nicht mal nur FP sein, AVX kann auch Integers und DP), würde man vermutlich AVX einsetzen. Aber die meisten Spiele brauchen das eben nicht, und für Wegfindung und AI ist es nicht so geeignet, weil da wenig im Vektorformat zu rechnen ist.

Und AVX lohnt sich auch nur wenn wirklich viel damit gerechnet wird. Denn die meisten CPUs takten beim Ausführen von AVX-Code runter, sprich die "normalen" Teile des Codes laufen langsamer als ohne AVX.
 
Also AVX2 zu nutzen ist nicht sonderlich viel aufwand und ein auf SSE zurückfallen sollte bei eigentlich jeder CPU funktionieren. Skelet-animation oder interaktive Physik, Objekttransformationen, Kameras - das sind alles einfache Matrix-Operationen und können mit AVX2 beschleunigt werden.
Weniger CPULast macht auch die FPS gleichmäßiger.
Nein.

Ja, man kann Matrixmultiplikationen sehr gut mit AVX beschleunigen. Aber damit alleine kommt man nicht weit. Physik braucht ebenso eine Menge Logikoperationen und auch nicht lineare Rechnungen wie Wurzelziehen kommt häufiger vor. Immer bedenken: Die meisten CPUs takten beim Ausführen von AVX-Code runter, sprich alles was nicht AVX nutzt läuft im Vergleich zu einer SSE-Version langsamer.

Und einfach zu implementieren ist es auch nur bedingt. Es ist kein Hexenwerk, aber wenn der Compiler keine Autovektorisierung unterstützt muss man doch seine komplette Mathebibliothek neu schreiben, zusätzlich zur normalen SSE-Version.

Das alles kostet Zeit und damit Geld. Das Budget ist in den meisten Fällen bei der Optimierung des GPU-Codes besser aufgehoben.
 
und auch nicht lineare Rechnungen wie Wurzelziehen kommt häufiger vor.
Also Wurzelziehen sollte bei Physik selten vorkommen :D


Und einfach zu implementieren ist es auch nur bedingt. Es ist kein Hexenwerk, aber wenn der Compiler keine Autovektorisierung unterstützt muss man doch seine komplette Mathebibliothek neu schreiben, zusätzlich zur normalen SSE-Version.
Die meisten Spiele utnerstüzen bereits SSE und von SSE auf AVX zu portieren ist recht leicht da das Grundprinzip und auch die Befehle gleich bleiben.
man muss halt statt _mm256_exp_ps() nun _mm256_exp_ps() schreiben. (ok, etwas übervereinfacht) und viele Schleifen kann der compiler selbst halbwegs vektorisieren wenn man ihn den lässt.

Das alles kostet Zeit und damit Geld. Das Budget ist in den meisten Fällen bei der Optimierung des GPU-Codes besser aufgehoben.
Naja, grundsachen wie zB Charakteranimation kann die ind er Engine Sitzen würden sich wahrscheinlich schon auszahlen.

ja, viele Spiele sind nicht CPU limitiert weil viele Spieler dann eben mal nen hohen i5 oder i7 haben. Aber auf den i3 hat man dann schon Probleme - die mit AVX minimiert würden.
Der Großteil des Rechenaufwandes in Spielen sind noch immer recht einfache opeartionen, viele davon matrix-operationen die eben wirklich gut paralellisiert werden können. Sei es frustrum-Culling oder Shadowcasting, AI-Pathfinding und noch einiges mehr.
vorallem pathfinding kann heir deutlich beschleunigt werden.


Ich kann nur hoffen das jetzt da AMD AVX auch gut unterstüzt (auch wenn AVX bei RyZen derzeit nur mit 128bit läuft) das es mehr eingesetzt wird.
 
In Spielen sehe ich da gar keinen SO hohen Bedarf - bei Anwendungen die hart im CPU-Limit sind und Tonnen an Flops fressen dagegen schon.
Die Encoderversion des HEVC der AVX(2) benutzt ist im Vergleich zu seinem Vorgänger auf SSE-Basis gleich mal 15-30% schneller (je nach Encodersettings). Das sind Welten in dem Bereich (und übrigens ein großer Vorteil von Skylake gegen Ryzen der nur AVX128 nutzt und hier entsprechend Boden verliert). Wenn hier die AVX512-Variante gut ausgenutzt werden könnte und das nochmal 20% oder so bringen würde hätte man alleine durch AVX 30-50% an Kodiergeschwindigkeit gewonnen! Ob da eine CPU dann 500 MHz runtertaktet oder nicht ist dann aber sowas von wurscht^^

Nebenbei erwähnt: Diese Encodings sind super Realworld-Stabilitätstests wo die "ich nehm die alte Prime-Version weil die praxisnäher ist"-Vertreter in die Röhre schauen - denn da wo die alte Prime Version ohne AVX usw. dann stabil läuft schmiert Handbrake oder vergleichbares dann ab. Die Zeiten, wo man AVX nicht auf Stabilität prüfen musste weils eh keiner benutzt sind so langsam dann doch vorbei.
Die alten Prime-Versionen werden aber dennoch kurioserweise wichtig(er) - denn es gibt ja jetzt einzelne Multis für "normal", "AVX", und "AVX512" - der Perfektionist muss ja alles einzeln durchtesten. :D
 
...
Und AVX lohnt sich auch nur wenn wirklich viel damit gerechnet wird. Denn die meisten CPUs takten beim Ausführen von AVX-Code runter, sprich die "normalen" Teile des Codes laufen langsamer als ohne AVX.

Dann wird es Zeit, dass die 2 Chiphersteller anfangen, Kerne/Module/Whatever, auf denen AVX ausgeführt wird, einzeln runtertakten zu können, und das OS oder was auch immer könnte dies logisch so regeln, dass immer nur die benötigte Anzahl an Kernen beliefert wird... und Zack, hat man Turbo 7.0.
 
Seit Skylake ist immerhin der Prozessor fürvdas hoch bzw. Runtertakten verantwortlich, der Anfang ist also gemacht. Allerdings fehlt die Software um die Threads sinnvoll aufzuteilen.
 
Zurück