Offizielle GFLOPS-Übersicht von Intel CPUs, speziell 980X

[Jevermeister]

HI,

ich schreibe gerade meine Bachelorarbeit und vergleiche u.a. die GFLOPS von Grafikkarten mit Prozessoren. Dazu brauche ich eine möglichst offizielle Quelle, gefunden habe ich bisher folgendes:

Processors — Intel® microprocessor export compliance metrics

Leider ist da nicht der 6-Core 980x dabei oder andere 32nm-Prozessoren. Kennt ihr da noch Quellen?
Ich brauche LINPACK (LinX geht auch) Performance von nicht übertakteten Prozessoren.

Danke!

 

[Phantomias88]

Advanced Clustering | High Performance Linpack on Xeon 5500 v. Opteron 2400 | Company Blog

Das sind aber Server CPUs, also nicht direkt vergleichbar mit den Desktop CPUs.

MfG

 

[Jevermeister]

Das ist zweitrangig - Aber leider kein 980x dabei oder ein 6-Core Nehalem

 

[Phantomias88]

Wie schreit sich denn der 980x als Server CPU? (Xeon ????)

 

[MartinFritsch]

Wie schreit sich denn der 980x als Server CPU? (Xeon ????)

Xeon UP W3680 als Single-Processor Variante oder Xeon DP 5680 als Dual-Processor Variante

 

[Cantor]

Interessant, wie gut beim Q6600 @ 3GHz noch mithalten kann. 48GFlops bietet sonst nur ider i7-870 sowie i7-940 aufwärts.

 

[mr.dude]

Das ist zweitrangig - Aber leider kein 980x dabei oder ein 6-Core Nehalem

Du meinst vermutlich 8-Kern Nehalem (Nehalem-EX)? Mir ist allerdings immer noch unklar, was du willst. Theoretische Performance wie auf der von dir verlinkten Seite? Oder reale Performance in Anwendungen wie zB Linpack? Ersteres kannst du dir selbst ausrechnen.

einfache Genauigkeit: 4 (128-bit SSE / 32-bit) x Taktrate x Anzahl der Kerne
doppelte Genauigkeit: 2 (128-bit SSE / 64-bit) x Taktrate x Anzahl der Kerne

Interessant, wie gut beim Q6600 @ 3GHz noch mithalten kann. 48GFlops bietet sonst nur ider i7-870 sowie i7-940 aufwärts.

Nun ja, das sind theoretische Werte. Sagt also noch nicht allzu viel. Und einen i7 kannst du ja auch noch notfalls um 25% übertakten.

 

[Jevermeister]

Ne, den 980x (Gulftown) als aktuell schnellste erhältliche CPU mit 6 Kernen. Diesen vergleiche ich mit den Spezifikationen aktuell erhältlicher Grafikkarten in punkto theoretischen GFLOPS. Bisher verwende ich ocaholic - Intel Core i7 980 X Performance Vergleich - CPUs - Artikel , was allerdings mit LINPACK usw nicht viel zu tun hat.

 

[denni]

Interessant, wie gut beim Q6600 @ 3GHz noch mithalten kann. 48GFlops bietet sonst nur ider i7-870 sowie i7-940 aufwärts.

Nur bei der realen Performance wendet sich das Blatt dann

 

[mr.dude]

Ne, den 980x (Gulftown) als aktuell schnellste erhältliche CPU mit 6 Kernen. Diesen vergleiche ich mit den Spezifikationen aktuell erhältlicher Grafikkarten in punkto theoretischen GFLOPS.

Wie gesagt, wenn es dir um theoretische Rechenleistung geht, dann kannst du dir die Werte selbst ausrechnen. Der i7 980X hat 83,2 GFLOPS (einfache Genauigkeit). Linpack Test habe ich allerdings noch keine gesehen.

 

[X909]

Können nicht mehrere SSE Befehle gleichzeitig verarbeitet werden? Dann wäre der theoretische Durchsatz noch höher.

Wenn ich mich nicht irre, können theoretisch 3 SSE Instruktionen gleichzeitig an die Ausführungseinheiten gegeben werden. Man hätte also ~ 250 GFLOPS.

 

[mr.dude]

Nein. Bezogen auf einen einzelnen Takt können die EUs zwar 3 SSE Instruktionen verarbeiten. Das funktioniert aber nicht durchgehend. Hier begrenzt das Frontend bzw die Leseraten des Caches. Daher durchschnittlich eine SSE Instruktion pro Takt. Was eben für den i7 980X 83,2 GFLOPS bedeutet.

 

[X909]

Cache mal ausgeklammert (ist für die theoretischen Peak-FLOPS ja nicht relevant, da man vom günstigsten Fall ausgeht), wären dann 3 Instruktionen pro Takt möglich oder woran scheiterts?

Praktisch sind die Werte eh nicht zu erreichen, das ist klar...

 

[mr.dude]

Nein. Da verstehst du anscheinend nicht, wie sich theoretischer Durchsatz berechnet. Und zwar nach dem, was die Hardware theoretisch hergibt. Und das ist eine SSE Instruktion pro Takt. Schau dir die offizielle Quelle von Jevermeister an. Die bestätigt das, was ich sagte.

 

[X909]

Hast Du nen Link zu der Quelle?

Die HW müsste schon 3 Inst schaffen, wenn die Daten im registerfile liegen. Ausm P4 konnte man mit einer entsprechenden Anwendung etwa 2,5 Instruktionen pro Takt quetschen und der war ja nicht so breit.

 

[mr.dude]

Der Link steht oben. Und auch der P4 konnte nicht mehr als eine SSE Instruktion pro Takt verarbeiten. Vermutlich sogar eher weniger. Müsste ich jetzt erst nochmal nachschauen. Hier verdeutlicht es Intel auch nochmal. "Single Cycle SSE", also eine SSE Instruktion pro Takt. Während der Vorgänger (Yonah) für eine SSE Instruktion 2 Takte benötigte.

 

[X909]

Durch den P4 hat man tatsächlich 2,5 IPC bekommen, mit einem Tool namens P4 Max Perf. Es wurden einfache SSE-Befehle benutzt. Theoretisch konnte der P4 mit 4 SP Operanden pro Takt arbeiten (1 MUL und 1 ADD, jeweils auf 2 Operanden).

Single Cycle heißt nur, dass die Ausführungslatenz einer Instruktion nur 1 Takt beträgt. Über die Parallelität sagt das nichts aus.

Hab jetzt mal ein wenig recherchiert. Wen man von X87 ausgeht, ist 1 FLOP pro Kern und Takt korrekt. Bei SSE sind es 2 DP Operanden pro Befehl x 3 OPs pro Cycle x 6 Kerne x 3,33 Ghz.

Mit den neuen 256Bit-Erweiterungen die mit Bulldozer und Sandybridge kommen sollten, wird der theoretische Durchsatz nochmal verdoppelt.

Das ist zwar zugegebenermaßen sehr idealtypisch betrachtet aber wenn man mit den ebenso unerreichbaren GFLOPS einer AMD-Grafikkarte vergleicht, kann man das schon so sehen.

 

[mr.dude]

Nochmal, die Core Architektur hat 6 Ports zu den EUs. Dabei ist Port 0 128-bit Mul, Port 1 128-bit Add und Port 5 128-bit Shuffle. FLOPS errechnen sich mittels Mul und Add Operationen. Die EUs selbst könnten also 2 FLOPS pro Takt erreichen. Aber wie gesagt, das ist irrelevant. Denn man betrachtet nicht nur das Backend, sondern die gesamte Pipeline. Und hier schafft man keine 2 FLOPS pro Takt durchgängig, auch nicht theoretisch. Schon deshalb nicht, weil wie gesagt lediglich 16 Byte (128-bit) pro Takt aus dem L1D gelesen werden können. Und permanent irgendwelche Register nur hin und her zu schieben, macht keinen Sinn. Das wäre völlig fernab von praxisnahen Workloads. Man rechnet deshalb mit 1 FLOP pro Takt. Nur das gibt die Pipeline theoretisch durchgängig her. Auch wenn es genau genommen vielleicht irgendwas zwischen 1 und 2 FLOPS ist.

 

[X909]

Man rechnet deshalb mit 1 FLOP pro Takt. Nur das gibt die Pipeline theoretisch durchgängig her. Auch wenn es genau genommen vielleicht irgendwas zwischen 1 und 2 FLOPS ist.

Praktisch mehr als theoretisch möglich?

Selbst wenn man die Daten immer aus dem L1 holen müsste wären 2 FLOPS pro Takt möglich, da man mit SSE 2 FP Datensätze mit einer Instruktion verarbeiten kann.

Wenn man das praxisnah betrachten möchte, dann sind die vom Hersteller genannten theoretischen GFLOPs einer Grafikkarte noch viel unrealistischer.

Btw. das Backend von Nehalem ist nicht mit dem des Core identisch. Nehalem hat Ports für 2 ADDs und 1 MUL. Für Load/Store zusätzliche...

 

[[HOT]]

Du kannst nur von theoretisch erreichbaren Werten ausgehen, um das theoretische Maximum zu errechnen. Gibt es einen Flaschenhals, musst du den auch theoretisch berücksichtigen. Ein Beispiel: Es sei ein Rohrsystem, dass man in 2 Teile teilt. Der vordere Teil schafft 300m³ Durchsatz pro Stunde, der hintere Teil schafft 600m³ pro Stunde. Dann ist der theoretische Maximaldurchsatz des gesamten Rohrsystems 300m³ pro Stunde. Zudem können die Hersteller ja frei definieren, wie sie das theoretische Maximum berechnen.

 

[X909]

Klar. Wo ist aber der Falschanhals? Die Pipeline ist 4fach ausgelegt. Dispatch Ports und relevante Ausführungseinheiten sind 3 vorhanden.

Wenn es irgendwo einen Flachenhals gibt, dann ist das die L1-Bandbreite aber selbst die würde nicht auf eine DP-Instruktion begrenzen und kommt nur dann zum tragen, wenn man die Daten immer ausm Cache holen muss.

 

[mr.dude]

Selbst wenn man die Daten immer aus dem L1 holen müsste wären 2 FLOPS pro Takt möglich, da man mit SSE 2 FP Datensätze mit einer Instruktion verarbeiten kann.

Erstens nein. Du kannst immer noch nur 16 Byte (128-bit) pro Takt aus dem L1D lesen. Für 2 Operationen bräuchtest du aber 2x 128-bit (32 Byte). Wie also soll das gehen? Und zweitens, was meinst du mit "2 FP Datensätze"? SSE ist eine 128-bit Pipeline, kann also mit 4 Single Precision (32-bit) oder 2 Double Precision (64-bit) Werten pro Instruktion arbeiten. Und dies ist auch in der theoretischen Rechenleistung inbegriffen. Dabei wird mit einer Operation pro Instruktion gerechnet. MIMD existiert erst seit SSE5 bzw AVX in der x86 ISA. Und deshalb wird die L1D Leserate bei Sandy Bridge auch verdoppelt.

Wenn man das praxisnah betrachten möchte, dann sind die vom Hersteller genannten theoretischen GFLOPs einer Grafikkarte noch viel unrealistischer.

Mitnichten. x86 CPUs schaffen bei HPC Workloads wie zB Linpack je nach Setup ~80% ihrer theoretischen Rechenleistung. Das schaffen GPUs wie zB RV770 oder RV870 auch.

Btw. das Backend von Nehalem ist nicht mit dem des Core identisch. Nehalem hat Ports für 2 ADDs und 1 MUL. Für Load/Store zusätzliche...

Soweit ich weiss, hat sich an den Ports gegenüber Core 2 nichts grundlegend geändert. Keine Ahnung, wo du deine Infos her hast, aber diese sind falsch. Ich wiederhole mich gerne nochmal. Ich hoffe, dann ist das bei dir endlich angekommen. An Port 0 liegt 128-bit Packed FP Mul, an Port 1 liegt 128-bit Packed FP Add. Weitere Ports für 128-bit Packed FP Mul oder Add gibt es nicht. Hier nochmal zwei Übersichten, die das verdeutlichen:





Wie gesagt, das Backend würde 2x 4 FLOPs Single Precision pro Takt schaffen. Das ist aber irrelevant, da das ganze vom Frontend limitiert wird. [HOT] hat ja schon eine verständliche Analogie gebracht. Deshalb rechnet man mit einem theoretischem Durchsatz von einer SSE Instruktion durchgängig. Genau das und nicht mehr gibt die Pipeline bei praxisrelevanten Workloads theoretisch her.

 

[X909]

Schau mal ganz unten rechts in Deiner ersten Grafik. Für mich sieht das wie eine ALU aus (das zweite ADD). Die Vectoreinheiten können sowohl FP als auch INT. Oder lieg ich da falsch? Das von Dir markierte in der ersten Grafik ist x87 und nicht SSE.

Das zweite von Dir verlinkte Schaubild passt da irgendwie garnicht so recht...

Bei Wikipedia steht eine Grafik, die auf 3 SSE Ops hindeutet. Sollte das nur für INT gelten?

 

[mr.dude]

Schau mal ganz unten rechts in Deiner ersten Grafik. Für mich sieht das wie eine ALU aus (das zweite ADD).

Du weisst, was "Integer" bedeutet? Wir reden immer noch von FLOPS.

Für mich sieht das wie eine ALU aus (das zweite ADD). Die Vectoreinheiten können sowohl FP als auch INT. Oder lieg ich da falsch?

Ja, du liegst falsch. Wenn da Integer steht, dann ist das kein FP.

Das von Dir markierte in der ersten Grafik ist x87 und nicht SSE.

In der Grafik ist das sowohl als auch.

Das zweite von Dir verlinkte Schaubild passt da irgendwie garnicht so recht...

Doch, das passt. Du scheinst es nur nicht zu verstehen.

Bei Wikipedia steht eine Grafik, die auf 3 SSE Ops hindeutet. Sollte das nur für INT gelten?

Wikipedia ist hier zu unspezifisch. Es gibt jedenfalls kein zweites Packed SSE Add für FP.


Wenn du mir nicht glaubst, dann glaube wenigstens den Aussagen von Intel selbst. Die haben ja schon einiges zu Sandy Bridge gesagt. Und da ändert sich an den Ports nichts grundlegend, nur dass die Pipeline auf 256-bit aufgebohrt wird.

Sandy Bridge has true 256-bit FP execution units (mul, add, shuffle). They are on exactly the same execution ports as the 128-bit versions. You can get a 256-bit multiply (on port 0) and a 256-bit add (on port 1) and a 256-bit shuffle (port 5) every cycle.

Das sage ich dir nun schon seit Beitrag #18.

 

[X909]

Wenn die SSE-Units nur INT-SSE Befehle ausführen, dann ist doch alles geklärt. Ich bin davon ausgegangen, dass die SSE-Einheiten sowohl INT als auch FP verarbeiten und die als FP gekennzeichneten Rechenwerke x87 sind.

@ "sage ich Dir doch seit ....": Du weißt doch wie das ist, ohne Beleg...

 

[mr.dude]

Wenn die SSE-Units nur INT-SSE Befehle ausführen, dann ist doch alles geklärt. Ich bin davon ausgegangen, dass die SSE-Einheiten sowohl INT als auch FP verarbeiten und die als FP gekennzeichneten Rechenwerke x87 sind.

@ "sage ich Dir doch seit ....": Du weißt doch wie das ist, ohne Beleg...

Ist ja ok. Nur spätestens nachdem ich dir das gesagt hatte, hättest du mal nachschauen und dir die entsprechenden Quellen suchen können. Einem muss nicht ständig jedes kleinste Detail vorgekaut werden. Selbstinitiative hat noch nie geschadet.

 

[PitGST]

 

[X909]

Ist ja ok. Nur spätestens nachdem ich dir das gesagt hatte, hättest du mal nachschauen und dir die entsprechenden Quellen suchen können. Einem muss nicht ständig jedes kleinste Detail vorgekaut werden. Selbstinitiative hat noch nie geschadet.

Ich hab ja auch recherchiert aber blöderweise eine zweideutige Quelle erwischt Ohne Details / Belege bin ich nicht so leicht zu überzeugen. Berufsskepsis vielleicht

@ Topic

Wieviel der theoretischen Rechenleistung können GPUs denn in praxisrelevanten Workloads (Encoding, Crypto-Sachen etc.) umsetzen?

Sind die dicken Rechenwerke der AMD-Grafikkarten eigentlich SIMD oder MIMD?

 

[mr.dude]

Evergreen hat FMAC Rechenwerke. Hier von MIMD zu sprechen, wäre also nicht falsch.