News ISSCC Teil 1: Totgesagte leben länger; Intels Itanium jetzt auch in 32nm

Mann mag es vielleicht kaum für möglich halten, aber Intel hält sich wirklich an die eigenen Roadmaps:


.. und präsentiert nun nach nur einem Jahr nach dem Tukwila Itanium Chip bereits die nächste Ausbaustufe mit dem Codenamen Poulson.

Technische Details dazu wird es in Kürze auf der im Moment stattfindenden ISSCC geben, der Intels Vortrag über Poulson ist für Dienstag 01:15 MEZ geplant.

Bereits vorab lancierte Intel aber einige Präsentationsfolien an die Presse, wie Computerbase oder Golem.

Wichtigste Folie ist dabei erst ein Mal das Layout eines Einzelkern:


Auffallend für x86 Kenner sind die geteilten L2-Intruktions und L2-Daten Caches (im Diagramm "MidLevel" genannt), bei x86 CPUs ist man das nur von den L1 Caches gewohnt. Sowie das Fehlen jeglicher Decoder. Beides ist aber IA64 typisch. Da man keine x86 in µOps zerlegen muss benötigt man keine Decoder und da die mehrere Instruktionen zu einem VLIW Instruktionsbündel - ähnlich wie bei ATis GPUs zusammengefasst wird benötigt man entsprechend mehr Platz für den Instruktionscache was auch die Trennung auf L2 nahe liegt, da sich sonst Instruktionen und Daten um den Platz im Cache streiten und sich gegenseitig behindern würden.

Erwähnenswert ist ferner, das Intel das Design verbreitert. Konnte Tukwila nur zwei VLIW Bündels á 3 Instruktionen gleichzeitig bearbeitet, so kann Poulson nun die doppelte Arbeit verrichten, also 4 Bündels pro Takt abarbeiten. Vermutlich wird das Ganze mit 4fachen Hyperthreading kombiniert, aber für Details muss man noch die Präsentation abwarten.

Danach interessiert natürlich das kompletten Chipdesign. Intel hat das ebenfalls vorab präsentiert (links der 8kernige Poulson, rechts zum Vergleich der Vorgänger Tukwila mit 4 Kernen):



Auffallend ist hier, dass sich die Platzierung der Kerne geändert hat. Waren sie bei Tukwila noch innen, sind sie jetzt außen. Wahrscheinlich ist es thermisch günstiger die Wärme erzeugenden Kerne außen zu platzieren, und das Chipzentrum mit relativ kühlen Cache zu belegen. Wären die Kerne sonst dicht an dicht in der Mitte, würden sie sich gegenseitig aufheizen. AMDs Bulldozerchip, von dem in ein paar Stunden (Dienstag, 22.2 00:15 MEZ) ebenfalls Neuigkeiten auf der ISSCC erwartet wird, folgt dem gleichen Ansatz.

Die Cachegröße ist gestiegen und fasst jetzt 50+4 MB. Das erscheint im Vergleich erst einmal gigantisch, ist bei IA64 aber ebenso "normal" wie die zuvor genannten Punkte mit den Decodern und L2I/D Caches. Im Verhältnis zum Vorgänger Tukwila hat sich aber nicht viel im "pro Kern" Verhältnis getan. Konnte Tukwilas 4 Kerne über 4x6MB=24MB Cache verfügen, sind es jetzt mit 50MB Cache für 8 Kerne nur geringfügig mehr. Genaues weiss man noch nicht. Höchstwahrscheinlich bleibt die L3 Größe pro Kern auch gleich, das ergäbe 48MB. Die restlichen 6MB könnten sich dann auf die L1/L2 und/oder den Directory Cache verteilen.

Zum Vergleich: Tukwila hat 512Kb+256kB L2 pro Kern, schematisch:



Quelle: http://download.intel.com/pressroom/archive/reference/Tukwila_Whitepaper.pdf

Blieben Tukwilas L2 Cachegrößen auch für Poulson gültig käme man schön auf zusätzliche 4+2MB Cache und wäre somit mit 48+6MB bei den angegebenen 54MB Gesamtcache. Der Directory Cache würde in der Rechnung dann allerdings fehlen.

Apropos .. der Directory Cache ist nichts Neues. AMD Insidern ist selbiges Feature bereits als "HT-Assist" bekannt, auch der Ausdruck "Probe-Filter" ist geläufig.

Dort passiert nicht viel, es werden dort nur Cache-Cohärenz Daten über andere CPUs abgelegt, die die gleichen Daten im Cache haben wie die aktuelle CPU. Sollte sich nun etwas ändern, muss man die geänderten Daten auch dort aktualisieren. Ohne Directory Cache hat man keine Ahnung welche CPUs im Mehrprozessorsetup die entsprechenden Daten ausgeliehen hat. Lösung des Problems ist die brute-force Methode - Änderungen werden einfach an alle CPUs im System geschickt. Das wird logischerweise aber bei großen Setups und immer mehr Kernen pro Sockel problematisch - deshalb der Directory Cache, damit man nur an die CPUs Änderungen schickt, die betroffen sind.

Wie es sich für einen High-End Server Prozessor gehört hat Intel auch Wert auf die Ausfall- und Datensicherheit sowie Verfügbarkeit gelegt (im Englischen abgekürzt RAS):



Alles sieht somit ganz gut aus, wie es sich für einen "BigIron" Prozessor gehört spart Intel an keinen Stellen, kann also durchaus stolz auf sich und das Einhalten der Roadmaps sein.

Nur ist der IA64 Zug wohl schon abgefahren, Microsoft wird den neuen Prozessor z.B. nicht mehr direkt untersützen, wie man an diesem alten Blogeitrag lesen kann:
http://blogs.technet.com/b/windowss...dows-server-2008-r2-to-phase-out-itanium.aspx

Sicherlich wird Poulson wie neue x86 CPUs ebenfalls abwärtskompatibel zu altem IA64 Code sein, aber die Unterstützung wird ähnlich halbgar wie x87 Code auf SSE4 oder gar AVX fähigen CPUs sein.

Nachdem die aktuellen Itaniums nun auch Sockelkompatibel mit Intels high-end x86 Server CPUs ist, ist die Itanium Zukunft umso mehr fraglich, selbst wenn es nun endlich einen konkurrenzfähigen IA64 Chip in einem aktuellen Herstellungsprozeß gibt.

Wer braucht sowas eigentlich?

Interessant ist aber das die beiden Hersteller wieder zu alten Namensschema zurückgreifen sofern es bei AMD mit dem FX kommt.
Trotzdem nette NEWS!

Oi!Olli schrieb:

Wer braucht sowas eigentlich?

Zum Vergrößern anklicken....

Na Großfirmen, die sich so ein Teil als Server in den Keller stellen
Für Privatkunden ist das natürlich nichts

@Makso:
HMm was meinst Du mit dem Namensschema ? Die 4stellige Nummer ? Ich denke mal die wurde bei Itanium einfach noch nicht umgestellt