News IBM nennt Details zum High-End-Prozessor Power8

[Krautmaster]

Nein, dinitiv nein! Nicht alles kann auf der GPU berechnet werden, nein. Eine möglichst starke CPU ist immer gut.

nicht alles? Das Wenigste kann (sinnvoll) von GPU berechnet werden ^^

 

[MountWalker]

...
Dank Cache-Prefetch-Instruktionen sind Algorithmen möglich, welche auf RISC-Design aufgrund schlechter Cache-Performance aufgrund randomisierter Zugriffe nicht möglich wäre. ...

Sind die Zugriffe bei x86 nicht mittlerweile auch randomisiert? Kann sein, dass ich das falsch verstanden habe, aber mir ist irgendwie so, dass das mal als Sicherheits-Feature eingeführt wurde.

...
dass der meiste Platz von Caches/GPU eingenommen wird. Bei SoC-Dies ist es noch wesentlich schlimmer da noch ein Haufen anderer Module dazukommen. ...

Naja, ich hab noch kein Prozessorbild gesehen, auf dem Caches mehr als die Hälfte eingenommen haben - auch bei Prozessoren ohne GPU on Die. Die GPU on Die ist wiederum für mich kein Grund, mehr Platz für Decoder zu erlauben, da die Decoder ja weder der GPU noch dem SIMD-Prozessor etwas bringen. Beim SoC spart man Strom, indem man mehr auf einem Die vereint, aber weil auch das alles nicht vom Decoder profitiert, sehe ich auch keinen Grund, hier mehr für den Decoder zu verbraten. In allgemeinen Artikeln zu Vergleichen von x86 mit anderen ISAs lese ich immer wieder gelegentlich (so viele Artikel gibts dazu ja nicht), dass bei Desktop- und Serverprozessoren der Decoder eine untergeordnete Rolle spiele, weil pro Decoder mehr Rehenleistung geschaffen worden wäre, wenn ich mir aber ansehe, dass die zwei Designs, die wirklich versucht hatten, weniger Decoder zu verwenden - Intel Pentium IV und AMD Bulldozer - mehr oder weniger Flops waren und das auch gerade aufgrund ihrer schlechten "Performance per Watt", dann zweifle ich schon an, dass der Decoder da eine untergeordnete Rolle spielt.

P.S.
Wobei man eingestehen muss, dass Power auch keine Glanzleuchte in Sachen Performance per Watt ist, weil IBM seit drei Prozessorgenerationen als oberstes Designziel den Ansatz verflogt, auf Biegen und Brechen so viel Leistung wie möglich auf einen Prozessorsockel zu bringen, weil Softwarelizenzkosten nach der Anzahl der Prozessorsockel berechnet werden.

 

[LundM]

Stimmt aber nicht ganz

Software lizensen werden endweder nach Sockeln oder Core Lizens berechnet.

des wegen pusht man ja auch die single core leistung so hart. zb thread´s per core
Das wir soch aber ändern weil die firmen immer weniger lizens geld bekommen^^

ps: würde aber eher behaupten das wen dnn das tot sparen des decoders schuld ist.

bzw hat der bulli noch andre probleme die in so scheisse gemacht haben.
die idee war gut doch amd hat es schlecht umgesetzt und dann im privat bereich noch mit dem 1% win 7 update hingerichtet.

 

[Headcool]

Sind die Zugriffe bei x86 nicht mittlerweile auch randomisiert? Kann sein, dass ich das falsch verstanden habe, aber mir ist irgendwie so, dass das mal als Sicherheits-Feature eingeführt wurde.

Ja da hast du was falsch verstanden, ich rede von etwas anderem.
Wenn du einen Algorithmus hast der den Speicher sequentiell durchiteriert hast du kaum Cache-Misses, da der Hardware-Prefetcher den Speicher auf den du zugreifen willst schon vorher in den Cache holt.
Wenn du allerdings einen Algorithmus hast der randomisiert auf den Speicher zugreift, hast du bei sogut wie jedem Zugriff einen Cache-Miss und deine Performance fällt in den Keller.
Bei x86 gibt es Cache-Prefetch-Instruktionen, welche der CPU sagen "Bitte lad mir mal den Speicherbereich in den Cache".
Somit kannst du während ein Datum abgearbeitet wird, das nächste schon in den Cache laden und hat dann keinen Cache-Miss mehr.

Naja, ich hab noch kein Prozessorbild gesehen, auf dem Caches mehr als die Hälfte eingenommen haben - auch bei Prozessoren ohne GPU on Die. Die GPU on Die ist wiederum für mich kein Grund, mehr Platz für Decoder zu erlauben, da die Decoder ja weder der GPU noch dem SIMD-Prozessor etwas bringen. Beim SoC spart man Strom, indem man mehr auf einem Die vereint, aber weil auch das alles nicht vom Decoder profitiert, sehe ich auch keinen Grund, hier mehr für den Decoder zu verbraten. In allgemeinen Artikeln zu Vergleichen von x86 mit anderen ISAs lese ich immer wieder gelegentlich (so viele Artikel gibts dazu ja nicht), dass bei Desktop- und Serverprozessoren der Decoder eine untergeordnete Rolle spiele, weil pro Decoder mehr Rehenleistung geschaffen worden wäre, wenn ich mir aber ansehe, dass die zwei Designs, die wirklich versucht hatten, weniger Decoder zu verwenden - Intel Pentium IV und AMD Bulldozer - mehr oder weniger Flops waren und das auch gerade aufgrund ihrer schlechten "Performance per Watt", dann zweifle ich schon an, dass der Decoder da eine untergeordnete Rolle spielt.

Hier das Bild einer Haswell-CPU:

Man kann sehr gut sehen wie groß GPU & L3-Cache im vgl. zu den CPU-Kernen sind. Und wenn man jetzt bedenkt, dass ein signifikanter Teil der einzelnen Kerne der L2-Cache ist, dann kann man sich vorstellen wie klein so ein Dekoder ist.

Wenn man da unbedingt etwas Flächen-mäßig optimieren will, dann versucht man die größeren Teile zu optimieren

Ich behaupte auch nicht, dass der Dekoder Performance-mäßig eine untergeordnete Rolle spielt, im Gegenteil, er ist essentiell für die x86-Architektur. Aber flächenmäßig spielt er definitv eine untergeordnete Rolle.

P.S.
Wobei man eingestehen muss, dass Power auch keine Glanzleuchte in Sachen Performance per Watt ist, weil IBM seit drei Prozessorgenerationen als oberstes Designziel den Ansatz verflogt, auf Biegen und Brechen so viel Leistung wie möglich auf einen Prozessorsockel zu bringen, weil Softwarelizenzkosten nach der Anzahl der Prozessorsockel berechnet werden.

Performance/Sockel ist zwar eine schöne Sache, aber Performance/Kern ist wichtiger. Zweiteres bewirkt ersteres hat aber noch andere Vorteile. Zb. eine wesentlich leichtere und sinnvollere Implementation von häufig verwendeten Funktionen in Libraries.

 

[MountWalker]

Ich habs jetzt nicht nachgemessen, aber beim Bulldozer siehts für mich nach gut 50% Chache aus.
http://semiaccurate.com/assets/uploads/2011/08/Bulldozer_Die_size.png
Stimmt schon, bei großen Prozessoren mit L3-Cache scheint Cache generell das meiste zu sein, aber hier mal ein Die-Shot, der zeigt, wie unklein die Decode-Einheit des Piledriver ist und Piledriver hat immernoch einen sehr zurechtgesparten Decode-Bereich, bei Steamroller wirds wieder deutlich größer:
http://crazyworldofchips.blogspot.de/2013/05/amd-steamroller-die-shot-leaked.html
Ich finde aber leider kein Vergleichsbild mit eingezeichnetem Decode-Bereich in einem Power-Prozessor. Kann durchaus sein, dass ich den Unterschied hier zu groß bewerte.

 

[Headcool]

Ich habs jetzt nicht nachgemessen, aber beim Bulldozer siehts für mich nach gut 50% Chache aus.
http://semiaccurate.com/assets/uploads/2011/08/Bulldozer_Die_size.png
Stimmt schon, bei großen Prozessoren mit L3-Cache scheint Cache generell das meiste zu sein, aber hier mal ein Die-Shot, der zeigt, wie unklein die Decode-Einheit des Piledriver ist und Piledriver hat immernoch einen sehr zurechtgesparten Decode-Bereich, bei Steamroller wirds wieder deutlich größer:
http://crazyworldofchips.blogspot.de/2013/05/amd-steamroller-die-shot-leaked.html
Ich finde aber leider kein Vergleichsbild mit eingezeichnetem Decode-Bereich in einem Power-Prozessor. Kann durchaus sein, dass ich den Unterschied hier zu groß bewerte.

Ich habe mal den Decoder bei dem Piledriver-Die grob ausgemessen --> ~6,5%.
Das ist allerdings nur ein CPU-Modul gewesen. Sieht man sich den Gesamt-Die an:

wird man nicht umhinkommen festzustellen, dass die 4 CPU-Module nur ca 20% der Gesamtfläche ausmachen. Und 6,5% von 20% sind 1,3%. Selbst wenn man den verdoppeln würde, wäre er noch klein. Vor allem wenn man bedenkt, wie wichtig dieses Teil ist.

 

[Herdware]

In einem Anandtech-Artikel stand mal die Aussage eines leitenden AMD-Entwicklers, dass zu Athlon64-Zeiten der für x86-Kompatibilität zuständige Teil (Decoder +X?) nur 5% der Die-Fläche ausgemacht hat. Deshalb entschied sich AMD damals (anders als Intel) dafür, die neuen 64Bit-CPUs weiterhin x86-kompatibel zu machen.
Da die Komplexität des Decoders sich kaum ändert, aber die Anzahl der Recheneinheiten modernern CPUs immer größer geworden ist und vor allem immer mehr zusätzliche Funktionen mit auf den CPU-Die gewandert sind (von GPU und L3-Cache bis zum PCIe-Controller), ist dieser Flächenanteil inzwischen garantiert noch deutlich geringer.

Wenn man über CPUs der Größenordung kleiner ARMs oder Atoms redet, spielt x86-Kompatibilität vielleicht noch eine gewisse Rolle z.B. bezüglich der Effizienz. Aber auch moderne ARM-SoCs erreichen inzwischen Größenordnungen, wo ein kleiner x86-Decoder einfach keine Rolle mehr spielen würde.