News 6-Core Dunnington hat 1,9 Mrd. Transistoren

[Ricky_b]

Im Desktop Bereich ist Intel mit seinen 2 mal Dualcore trotzdem bedeutend schneller als 1 mal 4Kerner nativ von AMD.
Und die 6 Kerne können sich hier über den L3 Cache sicher austauschen. Auch ist dieser schön groß bemessen.
Hier lötet man auch keine dualcores zusammen! Monolith = alles auf einem Die! Aber auch wenn das nicht so wäre, hätten die 6cores eine nette Rechenleistung!

 

[m_tree]

@11
Billion ist im Englischen eine Milliarde.

Monolithisch heißt - im verlinkten Wiki Eintrag steht's auch - an einem Stück, also zusammenhängend. Ist auch völlig logisch, da Intel meines Wissens keine Triple Cores im Programm hat und 3 Dual Cores relativ unwahrscheinlich sind - das würde die Größe des PCBs und die technischen Möglichkeiten (Abwärme, Stromaufnahme ..) sicherlich sprengen.

Auf dem Die Shot ist auch ganz gut zu sehen, dass sich wie bisher nur zwei Cores einen L2 Cache teilen. Also 6 Cores und 3 L2 Caches ... insofern ist damit ein möglicher Vorteil eines "monolithischen" Dies wohl dahin ....

 

[ebird]

@Ricky_b
Soweit ich weiß lötet Intel Dual Core CPUs zusammen. Also 3x2. Nur ist die Technik zum lösen ein bisschen komplexer.
Mich würde es interessieren, ob man wenigsten die 3 Dual Cores unabhängig von einander Taktet kann. Kann man das bei den Intel Quad Cores machen?

 

[gruffi]

Unsinn. Das kann der Dunnington genauso, der L3 is shared.

Du solltest schon genau lesen, ich sprach vom shared Cache, nicht vom L3. Der Dunnington ist insofern ungewöhnlich, dass sowohl L2 als auch L3 shared ist. Auch das spricht für eine Bastellösung und ein nicht natives Design. Solange sie an ihrer Dualcore Flicklösung festhalten, wird es das auch nicht geben. Solange das funktioniert, ist dies aber auch kein Problem. Es kann nur teilweise Kompromisse erfordern. Ein Kern vom Dunnigton kann also maximal 19 MiB exklusiv für sich reservieren, und nicht die vollen 25 MiB shared Cache.
Erst Nehalem wird ein "sauberes" Design bieten. Lustigerweise exakt das von AMD, dedicated L1+L2, shared L3. Dazu ein Zitat von Fudo:

Yesterday's conference call with Intel reminded us of a conversation that we had with some Intel engineers in the Summer of 2007 when they said that the K10 is a great concept, but it is tough (impossible) to make at 65nm. They used these words: we (Intel) cannot make the K10 in 65nm and Intel is known to have the best transistors in the word.

 

[Tommy]

Fudo ist der letzte, der Ahnung von einem Prozessordesign hat. Das unterstreicht schon seine Aussage zu den 128 Befehlen die Nehalem angeblich unterstütze. Dabei ging es aber um das In-Flight-Instruction-Window - also dem Reorder Buffer - dessen Größe von 96 auf 128 Einträge erhöht wurde. Das hat mit seinem ISA gar nichts zu tun.

Außerdem: Caches bestehen üblicherweise aus mehreren Hierachien. Es ist völlig normal, dass Core 1 nichts in einem prozessornahen Cache von Core 2 zu suchen hat. Wenn ein Kern will, dann kann er den kompletten 16 MB großen L3 für sich beanspruchen. Addiert wird da auch nichts - die Caches arbeiten Inclusive, d.h. was im L2 drin ist, ist auch im L3 drin. Aufgrund dieser Arbeitsweise kann jeder Core übrigens indirekt auf jeden L2 oder L1-Cache der anderen Kerne zugreifen - denn im L3 ist jeweils der aktuelle Stand enthalten! Wozu gibts auch MOESI?

Wenn man keine Ahnung hat, einfach mal besser nichts sagen. Auch ein Shared L2-Cache kann seine Vorteile haben, da die Latenzen kleiner sind, je kleiner der Cache ist. Das was du für ein natives Design hältst, gibt es nicht. Moderne Prozessoren werden nach dem Baukastensystem gebaut. Insofern wird nach deiner Definition überall gefrickelt.

 

[gruffi]

Außerdem: Caches bestehen üblicherweise aus mehreren Hierachien.

Das ist zwar richtig, trotzdem ist es vollkommen unüblich, dass man zwei shared Levels benutzt. Aber das muss Intel nun mal machen, weil eben Bastellösung.

Addiert wird da auch nichts - die Caches arbeiten Inclusive, d.h. was im L2 drin ist, ist auch im L3 drin.

So wie es aussieht, eben nicht.

Wenn man keine Ahnung hat, einfach mal besser nichts sagen.

Und du hast dich trotzdem berufen gefühlt, einen Artikel über AVX zu schreiben.

Das was du für ein natives Design hältst, gibt es nicht. Moderne Prozessoren werden nach dem Baukastensystem gebaut. Insofern wird nach deiner Definition überall gefrickelt.

Natürlich ist es immer eine Definitionssache, was man nun als nativ bezeichnet. Aber wenn man den K10 Quadcore als nativ bezeichnen will, dann hat Intel maximal ein natives Dualcore Design. Zumindest bis Nehalem.

 

[Tommy]

Die Caches sind bei Intel immer Inclusive. So auch wahrscheinlich beim Dunnington. Mehr geben meine Materialen zum Announcement nicht her und alles andere wäre aufgrund vom Snoop-Traffic auch nicht sinnvoll. Wenn du andere Informationen hast, dann nehm ich gerne einen Link. Das Inclusive-Verhalten macht den ganzen Prozessor zu einem ziemlich nativen Design.

In Sachen AVX: Wir werden sehen, wie sehr Intel SSE5 unterstützt. Schau dir SSE5 mal genauer an, dann wirst du sehen, wie sehr das auf deinem SSE aufbaut. Nämlich bis auf sehr wenige (vier?) Befehle gar nicht. Mit SSE5 setzt AMD seine Forschung einer Sonderunit fürs erste Hammer-Design fort, das in dieses nie eingebaut wurde. Codename hab ich vergessen. Viel Spaß bei der genauen Analyse der SSE5 Spec.

 

[gruffi]

Die Caches sind bei Intel immer Inclusive. So auch wahrscheinlich beim Dunnington. Mehr geben meine Materialen zum Announcement nicht her und alles andere wäre aufgrund vom Snoop-Traffic auch nicht sinnvoll.

Jegliche Information zum Dunnington spricht von 3 x 3 MiB L2 + 16 MiB L3. Also zwei getrennten, nicht inklusiven Cache Levels. Und bis nichts näheres bekannt ist, ist davon auszugehen, dass der Prozessor über 25 MiB shared Cache verfügen wird, und nicht 16 MiB.

Wenn du andere Informationen hast, dann nehm ich gerne einen Link. Das Inclusive-Verhalten macht den ganzen Prozessor zu einem ziemlich nativen Design.

Wenn es denn inklusiv wäre. Dafür spricht aber kaum etwas. Nehalem wird übrigens exakt die gleiche Cache Hierarchie haben wie der K10. Dunnington wäre also der logische Zwischenschritt von Penryn zu Nehalem. Dass Intel hier extra nochmal eine komplett inklusive Cache Hierarchie anrührt, wäre daher unsinnig.

Schau dir SSE5 mal genauer an, dann wirst du sehen, wie sehr das auf deinem SSE aufbaut. Nämlich bis auf sehr wenige (vier?) Befehle gar nicht.

Welche vier Instruktionen sollen das denn sein? Und warum sollen die restlichen nichts mit SSE zu tun haben? Ich sehe ehrlich gesagt nichts dergleichen.

 

[Tommy]

Jegliche Informationen: Link bitte. Es ist quasi angeschlossen, das andere Kerne auf die L2-Caches der anderen direkt zugreifen können.

3. Cache Hierarchie: Sie ist notwendig um Snoop-Bus-Traffic zu reduzieren und den Kernen eine Möglichkeit zu geben, direkt miteinander zu kommunizieren. Prinzipiell muss man sagen, dass ein 3 MB großer L2-Cache übertrieben groß ist, wenn man noch einen L3-Cache hat. Deswegen wird der mit Nehalem auch kleiner und vlt auch schneller.

SSE5: Es erlaubt triadische Operationen. Das weicht komplett von allem ab, was SSE oder x86 auszeichnet. Daher hat SSE5 außer im Namen nicht viel mit SSE zu tun. Ein Teil von SSE5 war als Technical Floating Point (TFP, nachgeschlagen) bereits für den ersten Opteron vorgesehen.

 

[gruffi]

Jegliche Informationen: Link bitte.

http://www.gidf.de/

Ich kann und will nicht alles wiedergeben, aber sämtliche Informationen geben ungefähr folgendes wieder:

In addition to the L2 cache, all cores will also be able to utilise the huge 16MB L3 cache.

Und das lässt eigentlich nur eine Vermutung zu, ua dass du eben falsch liegst.

SSE5: Es erlaubt triadische Operationen. Das weicht komplett von allem ab, was SSE oder x86 auszeichnet. Daher hat SSE5 außer im Namen nicht viel mit SSE zu tun.

SSE ist aber weder Semantik noch Syntax, es ist und bleibt eine superskalare Pipeline mit zugehörigem Instruction Set. Nur weil SSE5 neue Ansätze bietet, wie zB auch MIMD, ist es trotzdem noch SSE. Und die Implementierung einer solchen Pipeline wird von der SSE Spezifikation sowieso nicht vorgeschrieben. Übrigens, triadische Instruktionen gab es auch schon vorher, siehe IMUL. Wie war das mit dem "wenn man keine Ahnung hat"? Keine Ahnung, wo du solche Märchen aufgeschnappt hast, aber lass dir von jemandem sagen, der schon genug mit SSE programmiert hat, SSE5 ist genauso SSE wie SSE1-4. AVX ist wieder eine andere Geschichte und steht nicht im Gegensatz dazu. SSE5 kann maximal so angesehen werden, dass dadurch AVX kaum, eigentlich bis auf die Verbreiterung der Pipeline keine, Neuerungen bringen wird. Vermutlich ist es einfach nur ein Instruction Set Update, ausgelegt auf 256 Bit. Und auch wegen dem Unterschied 128 vs. 256 Bit werden SSE5 und AVX sich nicht überschneiden. Maximal in der Logik, aber da wird AVX sich auch mit SSE1-4 überschneiden.

 

[Tommy]

Wann das Zitat von Hans de Vries, David Kanter oder Andreas Stiller gekommen wäre, dann hätte ich etwas drauf gegeben. Aber Hexus? Faktisch hat Intel dazu nichts gesagt. Trag dir die Diskussion in deinen Kalender für H2 2008 ein und wir werden sehen, wer am Ende Recht hat. Auf dem IDF in Shanghai werde ich auch meine Lauscher aufklappen.

In Sachen IMUL: Mir war nicht bewusst, dass bei diesem Befehl eine Version mit drei Operanden gibt - gibt zu viele Befehle um alle zu kennen. Allerdings muss der dritte Wert ein Direktwert sein. Bei triadischen Architekturen wie RISC sind drei Register-Adressierungen erlaubt. Müsste mich aber selbst einlesen, wie viel Flexibilität SSE5 bietet.

Three-operand form — This form requires a destination operand (the first
operand) and two source operands (the second and the third operands). Here,
the first source operand (which can be a general-purpose register or a memory
location) is multiplied by the second source operand (an immediate value). The
product is then stored in the destination operand (a general-purpose register).

Edit: In der Vergangenheit waren übrigens alle L3-Caches von Intel inclusive. Nur so nebenbei...

 

[douggy]

Ich geh nich mehr zur Berufsschule. Hier lern ich ja viel mehr

 

[gruffi]

Wann das Zitat von Hans de Vries, David Kanter oder Andreas Stiller gekommen wäre, dann hätte ich etwas drauf gegeben. Aber Hexus?

Hexus war doch nur ein Beispiel, welches von Google ausgespuckt wurde. Kontaktiere die Seite deines Vertrauens und da wirst du die gleichen Informationen finden.

In Sachen IMUL: Mir war nicht bewusst, dass bei diesem Befehl eine Version mit drei Operanden gibt - gibt zu viele Befehle um alle zu kennen. Allerdings muss der dritte Wert ein Direktwert sein.

Das ist korrekt. Letztendlich ist das aber keine konzeptionelle, sondern eher strategische Entscheidung. Für die Implementierung bedeutet das maximal eine zusätzliche Indirektion. Aber wie schon gesagt, SSE ist eine Spezifikation, keine Implementierung. Übrigens, RISC heisst nicht automatisch triadisch. Und x86 CPUs sind mittlerweile sowieso eher ein Mix aus CISC und RISC.

Edit: In der Vergangenheit waren übrigens alle L3-Caches von Intel inclusive. Nur so nebenbei...

Mag sein. Aber wie man sieht, muss das ja nicht so bleiben. Nehalems L2/L3 wird zB auch exklusiv sein. Hat Itanium nicht auch exklusiven L2/L3 Cache?

 

[Tommy]

Es gibt zur Cache Hierachie des Dunnington keine genauen Informationen. Da brauch ich auch nirgends nachlesen. Zumal sich leider die wenigsten über Inclusive und Exclusive Cache bewusst sind und daher unglückliche Formulierungen in ihrem Meldungen wählen.

Deine Aussage bzgl. CISC sollte lauten: CISC-Prozessoren nutzten nach dem Frontend zur Ausführung der Befehle einen RISC-Kern. RISC ist allgemein triadisch.

Nehalem hat nen Inclusive L3-Cache - soviel dazu. Itanium L3 ist ebenfalls Inclusive. Gibst du nun endlich Ruhe?

Ende

 

[gruffi]

Deine Aussage bzgl. CISC sollte lauten: ...

Nein, sollte sie nicht. Denn das steht nicht im Widerspruch zu meiner Aussage.
Aber soll mir nur recht sein, beenden wir das Geplänkel.

Btw, wir sprachen vom L2 beim Dunnington, und der wird bei Nehalem exklusiv sein. L3 mag inklusiv sein, spielt für die ursprüngliche Frage aber auch keine Rolle.

 

[Arkos]

Es gibt zwei verschiedene Zahlensysteme. Im englischen sind Billionen = Milliarden

Also 1.9 billion = 1.9 Milliarden.