NextGen Architekturen: Haswell (Q2-2013)

[Duplex]

Intel Haswell (Sockel 1150) Gerüchte + FAQ + Infos [Sammelthread]



Facts:

Mit Haswell steht im nächsten Jahr eine neue Intel-Prozessorengeneration für das Mainstream-Segment an.
Der Prozessor wird zwar wieder in 22 nm gefertigt, besitzt diesmal aber im Vergleich zu Ivy Bridge über eine neue Mikroarchitektur.
Im Fokus steht diesmal vor allem die Grafikeinheit, während sich beim reinen Prozessorteil hinsichtlich der Taktraten fast nichts tut.
Dort soll neben der erhöhten Anzahl an Ausführungseinheiten auch noch eine völlig neue Architektur zum Einsatz kommen.
Außerdem können die alten Mainboards (Sockel 1155, Intel Sandy und Ivy Bridge) nicht mehr eingesetzt werden, da auf einen neuen Sockel LG1150 gesetzt wird.

Voraussichtlicher Release: Q2/2013
Fertigung: 22 nm (3D-Transistoren)
TDP: 84 W
Grafikeinheit: Intel HD 4600
Sockel: LGA 1150
Chipsätze: Z87, H87 und B85 sowie Q87, Q85 und H81 ("Lynx Point"-Chipsätze)
Versionen: K = Freier Multiplikator, S = Stromspar, T = Noch mehr Stromspar/Niedrigere TDP (+Takt), ULV = Ultra Low Voltage (Stromspar + architektonische Änderung)


Änderungen und Verbesserungen:

Chipset:

- "Lynx Point"-Chipsätze: Z87, H87 und B85 sowie Q87, Q85 und H81
- Fertigung in 32nm statt 65nm, also stromsparender
- 4 native USB-3.-0-Anschlüsse
- Bis zu 6 native SATA-6GB/s-Ports
- Mehr Details im Sammelthread: http://www.hardwareluxx.de/community...85-902183.html






Core + System-Agent:

- 22nm aber neue Mikroarchitektur
- Multi-Chip-Packages (MCP) vereint Chipsatz und Prozessor auf einem Träger, sowie On Package Interface (OPI), das als eine angepasste Version des DMI den Chipsatz mit dem Prozessor verbindet
- Bei erreichen des TJmax throttelt Chipset nun auch, auch wenn CPU diesen erreicht
- Neue Stromsparmodi: Für Haswell: C0, C2E, C7 und für Haswell-UT: Zusätzlich C8, C9 und C10
- BCLK („Baseclock“) kann auch auf 24 abesenkt werden, ermöglicht niedrigere Taktraten im Idle und somit die Verbesserung der Effizienz bei Teillast und Idle
- Architektonische Änderungen: ULT Prozessoren besizten kein PCI-Express(-3.0)-Support, kein Overclocking usw.
- Vielleicht bei den Modellen für Enthusiasten BLCK Straps
- Speicherunterstützung mit bis zu DDR3-1600










iGPU (HD 4600):

- Unterstützung von DirectX 11.1, OpenCL 1.2 sowie OpenGL 4.0
- Vermutliche Unterstützung der 4K-Auflösung (4.096 Pixel in der Breite)
- Die iGPUs werden intern wie bisher auch als GT1 (6-10 EUs) und GT2 (26-30 EUs) benannt, hinzu kommt bei Haswell als neue Lösung erstmals GT3 (40 EUs)
- Die neue iGPU aller (!) Haswell Desktop Prozessoren wird vermutlich die HD 4600 sein – die bisher als GT2 gehandelte Einheit mit 20 EUs
- Statt bisher 16 Execution Units nun also 20 oder sogar 40, wobei die GT3-Lösung mit 40 EUs nach bisherigen Erkenntnissen nur im mobilen Segment genutzt werden soll
- Erweiterte Codec-Unterstützung für De- und Enkodierung von Videos, sowie eine eigenständige Video Quality Engine (VQE)
- Weitergeführte Leistungssteigerungen sowie Energiesparmaßnahmen
















Haswell Prozessoren für den Desktop:

[Opteron]

Gerüchte:

Franklin Zhou, a retired chip architect and now a fellow systems integrator for our Taipei farms mentioned an interesting theory on the upcoming Haswell microarchtecture. The giveaway was Intel's statement that the microarchitecture uses an "entirely new cache scheme" which would indicate that the decoders will be at the far front of the data pipe and that the L0 cache will be one huge cache (most likely in the megabytes), completely removing the need for any code cache. The L0 cache will store predecoded and fused instructions of fixed length. The TLB will be entirely different since the fixed length instructions does not have a 1:1 equivalent addressing to physical memory.

What does it all mean? Well for one, the x86 decoder latency is vastly reduced since medium and even large loops can run inside the L0 cache. It also means that if the L0 cache is designed well enough, that is, if the hit ratio is well above 99%, then the arch need only a few decoders (maybe just 4) to satisfy the needs of an equivalent of two or more cores without any performance hit, saving chip real estate (expect the decoders to have long pipes).

The L0 cache could be multi-banked and multi-ported (for each bank) so that several simultaneous accesses are possible. This means that there will be several schedulers feeding several short decoders and execution units. There could also be several small caches (2K perhaps) feeding off the L0, one for each "core", that way, the schedulers won't starve the L0 cache read bandwidth. There will be no clear distinction as to how many units will make a single "core", instead there will be banks of EUs that together will be able to simultaneously process up to eight threads by default. Notice I said "up to", that's because the scheme allows for "dynamic threading" where the system can process a smaller number of threads to increase the IPC per thread.

Funny thing is that this theoretical arch sounds so similar to CMT but taken a level higher. I would like to think of it as a "fat CMT"...

http://semiaccurate.com/forums/showt...?t=4218&page=5

[Meckel]

Zitat von Opteron

Gerüchte:

http://semiaccurate.com/forums/showt...?t=4218&page=5

Na dann freuen wir uns alle auf neue lange Diskussionen was ein echter Core ist, und wer mehr Cores hat :-()

[LoRDxRaVeN]

Hört sich zum Teil nach dem sagenumwogenen Reverse-Hyperthreading an - wenn die Sache dynamisch von Statten geht

[gruffi]

Naja, im Grunde ist die FPU in Bulldozer ja schon sowas wie "Reverse-Hyperthreading".

There will be no clear distinction as to how many units will make a single "core", instead there will be banks of EUs that together will be able to simultaneously process up to eight threads by default.

Das hört sich in der Tat sehr nach CMT an, nur halt nicht wie in Bulldozer mit 2 Threads, sondern mit 8 Threads. Auch wenn "banks of" nicht direkt danach klingt, interessant wäre mal ein Design, wo wirklich alle EUs eines "Kerns" einem Thread zur Verfügung gestellt werden können. Halt so wie die FPU in Bulldozer, nur zusätzlich auch die Integer Einheiten. Klingt auf jeden Fall spannend.

This means that there will be several schedulers feeding several short decoders and execution units.

Sollten die (short) Decoder nicht die Scheduler füttern und nicht umgekehrt?


Die L0 Geschichte klingt aber recht seltsam. Ziemlich viel Aufwand für einen Codecache, der eine weitere Stufe fürs Decoding bedeutet (Predecoding) und hohe Latenzen aufgrund der Grösse besitzt? Das würde sich ja maximal lohnen, wenn man ständig den gleichen Code verarbeitet (Multithreading: yep, Multitasking: nope) oder grosse Schleifen hat, die nicht in bisherige uOp-Caches passen. Und auch nur dann, wenn man die Fetch- und Decoder-Latenzen verringern kann. Klingt für mich irgendwie nach Murks. Ein uOp-Cache ist vergleichsweise simpel und fängt das wichtigste schon recht gut ab, Schleifen, die viel Performance fressen.

[Opteron]

Zitat von gruffi

Naja, im Grunde ist die FPU in Bulldozer ja schon sowas wie "Reverse-Hyperthreading".

?? Nö, das ist SMT pur, 2 Threads laufen auf einem Unit.
Solange man keinen 256b AVX Befehl explizit angibt, wandelt da keine Logik 2x128b automatisch in 256b um. Wäre sowieso ne blöde Idee, da langsamer.

[Ge0rgy]

Klingt dennoch lustig...
Hatte der P4 nicht was ähnliches?
Also eine art Trace-Cache der vordekodierte Befehle speicherte?

[gruffi]

Zitat von Opteron

?? Nö, das ist SMT pur, 2 Threads laufen auf einem Unit.

Nö, das sind Units (2x FMAC + 2x Packed Integer), die für 2 Threads dimensioniert wurden, bei Bedarf aber einem Thread zur Verfügung gestellt werden können. Halt das Prinzip von "Reverse-Hyperthreading" oder "Anti-Hyperthreading".

Zitat von Opteron

Solange man keinen 256b AVX Befehl explizit angibt, wandelt da keine Logik 2x128b automatisch in 256b um.

Wieso sollte man auch?

[Opteron]

Zitat von gruffi

Nö, das sind Units (2x FMAC + 2x Packed Integer), die für 2 Threads dimensioniert wurden, bei Bedarf aber einem Thread zur Verfügung gestellt werden können. Halt das Prinzip von "Reverse-Hyperthreading" oder "Anti-Hyperthreading".

Nö, das ist SMT pur. Wenn Auf nem Intel nur 1 Thread läuf hat er doch auch alles zur Verfügung. 3x INT, 3xFPU und und und. Simples, normales SMT.

ReveresHTh war damals ne Technik µOps an nen anderen Kern auszulagern. Was nun ein Kern ist, ist beim Bulldozer bekanntlich die große Frage. Wenns nun 2 eigene, getrennte FPUs gäbe, dann würde ich Deine Sichtweise teilen. Die gibts aber nicht, es gibt nur eine FPU mit einem einzigen Scheduler, von daher seh ich das als SMT an. Ob da nun 2 FMACs hinter dem Scheduler kommen, oder nur eine, oder 4, ist wurst, es ist eine FPU Unit. AMD siehts ja auch genauso, das rote ist SMT:

[gruffi]

Zitat von Opteron

Nö, das ist SMT pur. Wenn Auf nem Intel nur 1 Thread läuf hat er doch auch alles zur Verfügung. 3x INT, 3xFPU und und und. Simples, normales SMT.

Nö, wie ich schon sagte, das ist vom Prinzip her "Reverse-Hyperthreading", wenn die Dimensionierung für mehr als einen Thread ausgelegt ist, aber dennoch alle EUs einem Thread zur Verfügung gestellt werden können. Und genau so wurde ja das Cluster-Design in Bulldozer konzipiert, speziell eben die Flex FPU. Wie Intel seine Architekturen geplant hat, kann ich dir nicht sagen. Fakt ist aber, sie hatten mit der Core Architektur die aktuellen EUs ja schon vor Hyperthreading. Und da lief lediglich ein Thread pro Kern. Was du als Kern bezeichnet, ist letztendlich aber völlig belanglos. Das hängt einfach vom Design ab. Ebenso die Scheduler. Ob die getrennt sind wie bei den Stars Int Pipes oder ein Unified Scheduler wie bei einem Bulldozer Int Cluster, ist einfach nur ein Detail der Implementierung. SMT hat jedenfalls eine andere Aufgabe, nämlich mit zusätzlichen Threads die vorhandenen EUs besser auszulasten. Und davon findet man definitiv nichts in Bulldozer.

[Opteron]

Zitat von gruffi

SMT hat jedenfalls eine andere Aufgabe, nämlich mit zusätzlichen Threads die vorhandenen EUs besser auszulasten. Und davon findet man definitiv nichts in Bulldozer.

Für mich ist das eindeutig die FPU. Erst mit 2 Threads wird die richtig ausgelastet.
Aber nun gut, haben wir halt wieder andere Ansichten. Ich hab Dir ne AMD Folie gezeigt, auf der gross und deutlich SMT steht, Du aber schön ignorierst, was soll man da noch weiter sagen.
Bleib gerne bei Deiner Meinung, ich bleib bei der von AMD ;-)

[gruffi]

Zitat von Opteron

Für mich ist das eindeutig die FPU. Erst mit 2 Threads wird die richtig ausgelastet.

Dann widersprichst du aber den Ingenieuren. Und die werden es wohl besser wissen. Ich kann mich noch dunkel an deren Worte erinnern (Chuck Moore Analyst Day 2009?), als man sagte, dass die FPU für 2 Threads dimensioniert wäre und die Ressourcen für einen Thread eigentlich überdimensioniert wären. Das passt jedenfalls nicht zum Prinzip von SMT.

Zitat von Opteron

Aber nun gut, haben wir halt wieder andere Ansichten. Ich hab Dir ne AMD Folie gezeigt, auf der gross und deutlich SMT steht, Du aber schön ignorierst, was soll man da noch weiter sagen.

Was soll ich denn mit so einer dahingeworfenen Folie anfangen? Ich sehe jedenfalls keinen Bezug. Und was erwartest du denn? Dass AMD auf die Folie "Reverse-Hyperthreading" schreibt? Wenn es nach dir ginge, hätten alle bisherigen AMD Prozessoren SMT oder wie? Schliesslich haben die auch alle einen L2. So wie ich das sehe, geht's da lediglich darum, wie die Threadverarbeitung in den einzelnen Stufen ausschaut und wie das mit gängigen Multithreading Konzepten vergleichbar ist. Und natürlich werden von mehreren Threads gemeinsam genutzte Ressourcen auch bei einer SMT Implementierung verwendet. Das heisst doch aber nicht, dass Bulldozer das SMT Konzept verfolgt. Du betrachtest das Thema einfach vom falschen Standpunkt aus. Ein Thread oder mehrere Threads, die Zugriff auf die gleichen Ressourcen haben, schliesst sich doch nicht aus. Wir betrachteten aber lediglich einen Thread. Und so wie die Flex FPU dann arbeitet, entspricht das eben dem Prinzip von "Reverse-Hyperthreading", weil die Ressourcen für mehr als einen Thread ausgelegt sind.

[Dresdenboy]

Zitat von gruffi

Dann widersprichst du aber den Ingenieuren. Und die werden es wohl besser wissen. Ich kann mich noch dunkel an deren Worte erinnern (Chuck Moore Analyst Day 2009?), als man sagte, dass die FPU für 2 Threads dimensioniert wäre und die Ressourcen für einen Thread eigentlich überdimensioniert wären. Das passt jedenfalls nicht zum Prinzip von SMT.

Was ist denn das Prinzip? Es geht doch eher um geeignete Kompromisse.

Mal unabhängig davon ist die FPU mit mehreren Zyklen Latenz bei allen Befehlen eine gute Kandidatin dafür, per SMT die Befehle eines zweiten Threads hineinzumischen.

[gruffi]

Zitat von Dresdenboy

Mal unabhängig davon ist die FPU mit mehreren Zyklen Latenz bei allen Befehlen eine gute Kandidatin dafür, per SMT die Befehle eines zweiten Threads hineinzumischen.

Ich denke, du wirfst hier zwei Sachen durcheinander. SMT mag bei Cache helfen, Latenzen zu verstecken, nicht aber bei Befehlslatenzen. Befehlslatenzen definieren sich ja hauptsächlich dadurch, wie lange eine Instruktion braucht, bis sie von den EUs verarbeitet wurde. Genau dann bringt dir SMT rein gar nichts, egal wie gross die Latenz ist. SMT bringt erst dann etwas, wenn EUs frei sind. Oder anders formuliert, je niedriger die Befehlslatenzen, umso besser für SMT, weil die EUs dann schneller wieder frei sind und von anderen Threads genutzt werden können. Hohe Befehlslatenzen sind eher kontraproduktiv für SMT.

[Duplex]

Etwas neues von Haswell

http://www.chiphell.com/thread-308643-1-1.html

[Duplex]

Laut Wiki hat Haswell "1MB L2 cache per core and up to a 32MB L3 cache for the Extreme Edition and Xeon."

400% mehr L2 Cache & 60% mehr L3 Cache als Sandy Bridge-E

Der L2 Cache wird im vergleich zum "Core2" Cache Design aber richtig aufgepumpt, bisher hat Intel seit Core2 bis Sandy Bridge immer die gleiche L2 Größe gehabt, das war immer sehr schnell.
Der einzige Nachteil könnte die Latenzen betreffen, aber Faktor4 Steigerung ist schon heftig da muss sich Intel etwas gutes ausgedacht haben

http://en.wikipedia.org/wiki/Haswell...rchitecture%29

[Opteron]

Schau mal in der Änder-Historie des Bulldozer-Wikieintrags nach, wieviel Cache der Chip schon Mal hatte. Wiki als Quelle bei solchen hochspekulativen Sachen, wie unfertige Chips im Planungsstadium ist Blödsinn hoch 3.
Da ist das Gerüchte mit dem Transactional Memory 10x glaubhafter.

[Lepus]

Und? Läuft!

[Duplex]

Zitat von Opteron

Wiki als Quelle bei solchen hochspekulativen Sachen, wie unfertige Chips im Planungsstadium ist Blödsinn hoch 3.
Da ist das Gerüchte mit dem Transactional Memory 10x glaubhafter.

Die L2 Größe mit 1MB pro Core glaube ich auch nicht wirklich, bisher hat man immer auf schnellen 256KB L2 gesetzt, warum sollte man den durch einen neuen ersetzen?

[FredD]

Zitat von Duplex

Die L2 Größe mit 1MB pro Core glaube ich auch nicht wirklich, bisher hat man immer auf schnellen 256KB L2 gesetzt, warum sollte man den durch einen neuen ersetzen?

"New Cache Design" heißt so viel wie "Überraschung"

EDIT:
Ich tippe übrigens auf so etwas wie "Bulldozer done right", jedoch etwas bodenständiger, siehe Nehalem.

[Dresdenboy]

Transactional Memory wird auf beiden Seiten schon fleißig patentiert.

Das neue Cache-Design (für Gather-Operationen) wird vielleicht auf viele parallele, aber nicht so breite Bankzugriffe optimiert. Damit aber auch ausreichend Daten dafür da sind, sollten die schnelleren Caches größer sein, damit beim Gathering nicht ein paar Zugriffe quer ins langsame DRAM feuern.
.
EDIT :
.

Zitat von FredD

Ich tippe übrigens auf so etwas wie "Bulldozer done right", jedoch etwas bodenständiger, siehe Nehalem.

So etwas wie Cluster kann ich mir auch vorstellen. Intel's Gonzalez arbeitet auch an flexiblen Ressourcenzuordnungen (z.B. 2 Cluster für einen Thread).

Aber ein "Bulldozer done right" erfordert ersteinmal einen "Bulldozer done wrong" Der jetzige BD1 ist aber nicht "falsch", sondern hat eher nur zu wenig von dem, was AMD schon angedacht hat. Hier kann man die Probleme im Management, in knappen Ressourcen, in Sackgassen usw. suchen.

[FredD]

Zitat von Dresdenboy

Aber ein "Bulldozer done right" erfordert ersteinmal einen "Bulldozer done wrong" Der jetzige BD1 ist aber nicht "falsch", sondern hat eher nur zu wenig von dem, was AMD schon angedacht hat.

"Bulldozer done better" wäre wohl die logisch bessere Formulierung.

Laut den Folien bleibt Haswell jedoch weiterhin bei 'Intel Hyperthreading', was aber nicht heißt, dass CMT nicht doch irgendwann den Weg auf Intel-Silizium findet.

[Dresdenboy]

Zitat von FredD

Laut den Folien bleibt Haswell jedoch weiterhin bei 'Intel Hyperthreading', was aber nicht heißt, dass CMT nicht doch irgendwann den Weg auf Intel-Silizium findet.

Das gute an so einem Marketingnamen ist, dass Intel schmerzfrei ein anderes Konzept dahinterlegen kann. Und wenn man sich eine dynamische Clusterzuteilung (nicht befehlsweise, aber z. B. für einen kleinen Befehlsstrang) vorstellt, kann man grob auch SMT darin erkennen, nur gälte "simultaneous" dann für die Befehlsstränge.

[Duplex]

Neues GPU Design & 25% mehr EUs als Ivy Bridge

http://vr-zone.com/articles/haswell-...#ixzz1iUkKTN8O

Das wichtigste bleibt leider noch unbekannt (IPC Verbesserungen gegenüber Sandy Bridge)

[memory_stick]

soweit es denn verbesserungen werden...
Soweit es nach den Gerüchten aussieht, soll Intel doch auf eine Art CMT-Design umsteigen, oder bin ich falsch informiert?
Dies beduetet für mich, dass man (analog zu AMD mit BD) auch bei Intel nicht zwingend von einer "IPC" (welche IPC?) Verbesserung ausgehen kann... Eine Stagnation zu SB ist genauso zu erwarten.

mfg memory_stick