Cache-Anteil an Transistorenanzahl

[Gast]

Hi alle,

mich würde mal brennend interessieren, welchen Anteil die mittlerweile massiven Caches an der Gesamtzahl der Transistoren einer CPU haben. Wenn wir aktuell bei Dualcore bei runden 300mio Transistoren sind und ich mal hier gelesen habe, dass das Cachemonster Itanium mit 1,7mrd Transistoren nur 60mio für die eigentliche Prozessorlogik (oder wie auch immer der nicht-cache Teil heißt) brauchen soll...

Hat da jemand Zahlen für mich oder ungefähre Prozentsätze?

Danke :-)

[Stone2001]

Genaue Werte habe ich jetzt nicht im Kopf, aber 1 MB-Cache sind in etwa 50 Mio. Transistoren (da kommen noch ein paar durch die Steuerungslogik hinzu).
6 Transistoren pro gespeichertem bit (klassische 6T-SRAM Zelle) .
=> 6 * 8* 1024 * 1024 Transisoren pro MB

[Gast]

wenn mich dann meine schwachen Mathekenntnisse nicht im Stich lassen, hieße das z.B. für den Conroe, dass für die 4mb Cache runde 200mio Transistoren verbraten werden. Ergo sind rund 90 mio "echte" CPU.

Und g80 und r600 liegen ohne Cache bei 700mio?!

So banal die Frage klingen mag, aber kann das jemand kurz und schmerzlos erklären?

Besten Dank!

[mapel110]

wenn mich dann meine schwachen Mathekenntnisse nicht im Stich lassen, hieße das z.B. für den Conroe, dass für die 4mb Cache runde 200mio Transistoren verbraten werden. Ergo sind rund 90 mio "echte" CPU.

Und g80 und r600 liegen ohne Cache bei 700mio?!

So banal die Frage klingen mag, aber kann das jemand kurz und schmerzlos erklären?

Besten Dank!
Grafikkarten haben hier und da auch kleine caches um Textursamples halten zu können. Bei Grafikkarten wird zudem mehr in die Breite gegangen. Bei CPus geht das schlecht, da die Arbeit kaum zu parallelisieren ist. Das muss ja bei Dual Core dort immer der Programmieren des Tools machen. Bei Grafikkarten ist das einfacher. Der Bildschirm bzw die zu bearbeitenden Pixel lassen sich gut aufteilen.

Die CPU braucht große und viele Caches, damit sie die Daten, mit denen sie rechnet, schnell zur Verfügung hat. Auch Zwischenergebnisse fallen ja an. Bei Grafikkarten gibts die prinzippiell nicht. Was dort berechnet wird, kommt quasi sofort wieder raus. Deswegen nennt man Grafikkarten auch Streamprozessoren. WEil da Daten einfach nur durchlaufen.

Naja, das lässt sich alles noch ausführlicher und/oder besser umschreiben.

[Spasstiger]

Und g80 und r600 liegen ohne Cache bei 700mio?!

So banal die Frage klingen mag, aber kann das jemand kurz und schmerzlos erklären?

Besten Dank!
Eher bei 500-600 Mio. Aber du hast schon richtig erkannt, dass Grafikchips mehr Transistoren für die eigentliche Logik verwenden, sind ja auch von der theoretischen Leistung her deutlich leistungsfähiger als CPUs. Die schwache Branching-Performance macht diesen Vorteil für echte CPU-Berechnungen aber zunichte.

/EDIT: Bei den 681 Mio. Transistoren des G80 werden es wohl mehr als 600 Mio. Transistoren für die Rechenlogik sein. Beim R600 muss man erst mal abwarten, auf wieviele Transistoren er kommt.

[Gast]

Nochmal herzlichen Dank für die ausführlichen Antworten! Da hab ich gleich mal Ansatzpunkte für weitere Recherche...

3Dc ist wirklich in jeder Lebenslage die besten Anlaufstelle :-)

[BlackBirdSR]

wenn mich dann meine schwachen Mathekenntnisse nicht im Stich lassen, hieße das z.B. für den Conroe, dass für die 4mb Cache runde 200mio Transistoren verbraten werden. Ergo sind rund 90 mio "echte" CPU.

Und g80 und r600 liegen ohne Cache bei 700mio?!

So banal die Frage klingen mag, aber kann das jemand kurz und schmerzlos erklären?

Besten Dank!

Ca 150 250 Millionen Transistoren gehen für die 4MB-Cache drauf. Dann bleiben noch 43/2 Millionen für einen einzelnen Kern.
Abzüglich Redundanz etc ca 19 Millionen.
Das ist doch recht viel, wenn man die reine Kerngrößen des P6 mit halbem L1-Cache des Core2 bei 9.5 Millionen sieht, und einen K7 mit 152KB L1-Cache bei 22 Millionen.
An den K8 mit ca 35 Millionen kommt natürlich nichts heran ;)

[Wurschtler]

Da frage ich mich aber, ob sich dieser Cache lohnt.

Angenommen, Intel würde auf den Core2s überall nur 1 MB L2 Cache verbaun.
Das würde schlimmstenfalls 20% Performance kosten, aber die Transistoranzahl und damit die Produktionskosten wäre nur noch ein Drittel so hoch. Oder sehe ich da was falsch?

[mapel110]

Prinzippiell wohl richtig, aber man braucht auch bei immer kleiner werdenden Fertigungstechniken noch genügend Fläche um die Abwärme abführen zu können. Und die meiste Wärme entsteht eben im Rechenteil der CPU und daher lohnt sichs wohl, mehr Cache zu verdauen aus kühltechnischer Sicht.
/edit
aber ganz sicher bin ich mir bei dieser These nicht.

[Gast]

Prinzippiell wohl richtig, aber man braucht auch bei immer kleiner werdenden Fertigungstechniken noch genügend Fläche um die Abwärme abführen zu können. Und die meiste Wärme entsteht eben im Rechenteil der CPU und daher lohnt sichs wohl, mehr Cache zu verdauen aus kühltechnischer Sicht.
/edit
aber ganz sicher bin ich mir bei dieser These nicht.Die Wärme entsteht ja nicht gleichmäßig über den Die verteilt, sondern hauptsächlich dort, wo die Logik liegt. Der Cache produziert nicht übermäßig viel Wärme und hilft eigentlich auch nicht nennenswert beim Abtransport der Wärme. Dass ein großer Cache die Kühlung einfacher macht, halte ich für etwas weit hergeholt.

[Stone2001]

Da frage ich mich aber, ob sich dieser Cache lohnt.

Angenommen, Intel würde auf den Core2s überall nur 1 MB L2 Cache verbaun.
Das würde schlimmstenfalls 20% Performance kosten, aber die Transistoranzahl und damit die Produktionskosten wäre nur noch ein Drittel so hoch. Oder sehe ich da was falsch?
Die Produktionskosten sind nicht nur von der Chipfläche abhängig, sondern auch von der Verpackung, ... . Bei der Vorstellung des Kentsfield hat Intel mal preisgegeben, wie teuer ein Kentsfield in der Herstellung wirklich ist. Die Herstellung des Die ist zwar ein großer Punkt, aber nicht der einzige. ;)

Was natürlich heute auch noch eine Rolle spielt (ob es bei CPUs auch so ist, kann ich nicht sagen, da fehlen mir die Erfahrungen, aber für ASICs gilt dies) ist, dass wenn der Chip zu klein ist, man nicht alle Signale nach aussen führen kann (man ist Pad-Limited). Man muss den Chip also vergrößern um alle Signale nach aussen führen zu können.

[BlackBirdSR]

Die Produktionskosten sind nicht nur von der Chipfläche abhängig, sondern auch von der Verpackung, ... . Bei der Vorstellung des Kentsfield hat Intel mal preisgegeben, wie teuer ein Kentsfield in der Herstellung wirklich ist. Die Herstellung des Die ist zwar ein großer Punkt, aber nicht der einzige. ;)

Was natürlich heute auch noch eine Rolle spielt (ob es bei CPUs auch so ist, kann ich nicht sagen, da fehlen mir die Erfahrungen, aber für ASICs gilt dies) ist, dass wenn der Chip zu klein ist, man nicht alle Signale nach aussen führen kann (man ist Pad-Limited). Man muss den Chip also vergrößern um alle Signale nach aussen führen zu können.

Richtig.
Ein zu kleiner Chip hat z.B nicht die notwendige Fläche für Anschlusspads etc.
Gerade bei Chips mit viel I/O wird das wichtig.

Die Sache mit dem Abführen der Wärme ist dagegen nicht so ganz richtig. Wie der Gast schon sagte: Wärme entsteht lokal und lässt sich nicht homogen auf die DIE verteilen bevor man sie abführt.

[Leonidas]

Ca 150 250 Millionen Transistoren gehen für die 4MB-Cache drauf. Dann bleiben noch 43/2 Millionen für einen einzelnen Kern.
Abzüglich Redundanz etc ca 19 Millionen.
Das ist doch recht viel, wenn man die reine Kerngrößen des P6 mit halbem L1-Cache des Core2 bei 9.5 Millionen sieht, und einen K7 mit 152KB L1-Cache bei 22 Millionen.
An den K8 mit ca 35 Millionen kommt natürlich nichts heran ;)


Dies sind ungefähr korrekte Angaben. Ich will aber noch den Punkt in die Diskussion einbringen, daß man nicht denken soll, daß sich aus der Transistorenanzahl automatisch der Anteil an der Die-Fläche ergibt. Beim Pentium 4 war es wohl angeblich so, daß sich dort Cache und reiner Prozessor auf dem Die die Fläche ziemlich brüderlich teilten, obwohl bei der Transistorenanzahl der Cache den deutlich größten Anteil ausmachte. Cache läßt sich schlicht besser packen, deswegen benötigen die vielen Cache-Transistoren nur genauso viel Platz wie die wenigen "Logik"-Transistoren.

Nichts desto trotz ist für die Zukunft eigentlich von einer Drosselung der ständig wachsenden Caches auszugehen. Die werden dann nicht kleiner, aber sie wachsen nicht mehr so rasant wie zuletzt. Es wird nämlich langsam wirtschaftlicher, auf kleinere Caches zu setzen, weil die viel Die-Fläche verbraten und man mit bei einer Cache-Einsparung sofort erheblich mehr Prozessoren aus einem Wafer machen kann. AMD macht dies ja derzeit gerade mit den Athlon 64 X2 Modellen mit nur 2x512 kByte Level2 Cache zugunsten der Modelle mit 2x1 MB Level2 Cache. Die Die-Fläche ist aus dem Kopf um 30% oder so kleiner.

[Stone2001]

Die hohen Cacheanteile haben aber auch den Vorteil, dass ein Fertigungsfehler dort relativ einfach kompensiert werden kann. Entweder führt man zusätzliche Cachezeilen ein, um eventuelle Fehler auszugleichen oder man deaktiviert eine Hälfte und verkauft ihn dann im Low-Cost-Sektor.
Ein Fehler im eigentlichen Prozessor auszugleichen ist vergleichsweise aufwendig und teuer.
Bei fortgeschrittenen Fertigungstechniken, also bei höherer Ausbeute, kann man dann zunehmend kleinere Cores fertigen, ohne das die Ausbeute drastisch sinkt.

Das die Cache nicht mehr beliebig wachsen werden hat mehrere Gründe, einer davon ist einfach, dass die Cachegeschwindigkeit direkt von seiner Größe abhängt, größere Cache sind halt nun mal langsamer. Und ein paar Zyklen mehr Wartezeit können sich bei bestimmten Anwendungen doch bemerkbar machen.

Caches lassen sich aufgrund ihrer regelmäßigen Struktur recht gut optimieren (die 6T-SRAM-Zelle, die ich gerade im Kopf habe ist meines Wissens nach auch nicht die besste Version). Hinzukommt, dass Cache nicht so warm werden, wie z.B. die ALUs oder die Dekodierlogik.

[turboschlumpf]

http://www.heise.de/bilder/84332/0/0
Merom- (oben) und Penryn-Dice, skaliert auf gleiche Breite
Quelle: http://www.heise.de/newsticker/meldung/84332

Merom: 65 nm; 4 MiB L2-Cache; 291 Mio. Transistoren; 143 mm²
Penryn: 45 nm; 6 MiB L2-Cache; 410 Mio. Transistoren


[edit] Ich tippe Penryn auf nur gut 100 mm².

[RavenTS]

Da frage ich mich aber, ob sich dieser Cache lohnt.

Angenommen, Intel würde auf den Core2s überall nur 1 MB L2 Cache verbaun.
Das würde schlimmstenfalls 20% Performance kosten, aber die Transistoranzahl und damit die Produktionskosten wäre nur noch ein Drittel so hoch. Oder sehe ich da was falsch?

Das mag sein, aber INTeL hat schlicht die nötige "Produktionspower" (viele FABs mit guter Technik) um sich das leisten zu können. Das Umstellen auf kleinere Cores würde zwar mehr Output an Cores ermöglichen, aber das heißt nicht, dass die dann auch alle gekauft werden würden.

Man müsste dann die Preise senken oder noch mehr auf Lager produzieren, die Nachfrage ist eben einfach nicht unbegrenzt...

[turboschlumpf]

Da frage ich mich aber, ob sich dieser Cache lohnt.

Angenommen, Intel würde auf den Core2s überall nur 1 MB L2 Cache verbaun.
Das würde schlimmstenfalls 20% Performance kosten, aber die Transistoranzahl und damit die Produktionskosten wäre nur noch ein Drittel so hoch. Oder sehe ich da was falsch?
Dafür müsste Intel im Gegenzug die Taktrate erhöhen. Welches der sinnvollere Weg ist, das kann aber einzig Intel beurteilen.

Nichts desto trotz ist für die Zukunft eigentlich von einer Drosselung der ständig wachsenden Caches auszugehen. Die werden dann nicht kleiner, aber sie wachsen nicht mehr so rasant wie zuletzt. Es wird nämlich langsam wirtschaftlicher, auf kleinere Caches zu setzen, weil die viel Die-Fläche verbraten und man mit bei einer Cache-Einsparung sofort erheblich mehr Prozessoren aus einem Wafer machen kann. AMD macht dies ja derzeit gerade mit den Athlon 64 X2 Modellen mit nur 2x512 kByte Level2 Cache zugunsten der Modelle mit 2x1 MB Level2 Cache. Die Die-Fläche ist aus dem Kopf um 30% oder so kleiner.
Das gilt vielleicht für AMD. Aber die hinken auch mit der Fertigungstechnik hinter Intel her und können Cache lange nicht so dicht packen wie Intel.

Das die Cache nicht mehr beliebig wachsen werden hat mehrere Gründe, einer davon ist einfach, dass die Cachegeschwindigkeit direkt von seiner Größe abhängt, größere Cache sind halt nun mal langsamer. Und ein paar Zyklen mehr Wartezeit können sich bei bestimmten Anwendungen doch bemerkbar machen.
Ist für die Signallaufzeit nicht nur der rämliche Abstand entscheidend? Denn der steigt ja von Merom zu Penryn nicht nennenswert an.

[=Floi=]

eben nicht
der weg mit dem cache ist nicht der günstigste aber sicherlich ein guter um die leistung weiter zu steigern und die mhz auf einem normalem niveau zu halten
intel deckt ja mit dem aktuellen core alle 3 bereiche ab und da wird ja ebenfalls der cache benötigt

desweiteren weiß hier niemand wie sich der conroe mit nur 256 oder 512kb verhalten würde
imho ist die tendenz schon hin zu größeren caches
Yorkfield besitzt 2X6MB!
und wenn das nochmal 10prozent pro mhz bringt soll es mir nur recht sein

[Stone2001]

Das gilt vielleicht für AMD. Aber die hinken auch mit der Fertigungstechnik hinter Intel her und können Cache lange nicht so dicht packen wie Intel.
Das AMD ihren Cache nicht so dicht packen kann, wie Intel halte ich für eine gewagte These! Ich würde eher sagen, dass bei gleicher Technologie die Dichte in etwa gleich ist, müsste aber jetzt ein paar Die-Bilder analysieren, um das zu untermauern.
Ist für die Signalleufzeit nicht nur der rämliche Abstand entscheidend? Denn der steigt ja von Merom zu Penryn nicht nennenswert an.
Der räumliche Abstand spielt eine Rolle, hinzu kommen aber noch Faktoren, wie die Kapazität der Leitung, ... . Die Geschwindigkeit eines Cache wird dann noch durch andere Faktoren begrenzt, z.B. den Leseverstärkern.
Dass alles muss bei der Skalierung entsprechend angepasst werden, sonst müssen bei einer Takterhöhung neue Wartezyklen eingefügt werden, da ja die Verzögerung auf der Leitung gleich bleibt (im Idealfall).

[Gast]

Das AMD ihren Cache nicht so dicht packen kann, wie Intel halte ich für eine gewagte These! Ich würde eher sagen, dass bei gleicher Technologie die Dichte in etwa gleich ist, müsste aber jetzt ein paar Die-Bilder analysieren, um das zu untermauern.


dann sieh dir doch mal die DIE-bilder von intel und AMD an. bei intel ist der flächenanteil vom cache nur knapp über 50%, bei AMD ist der flächenanteil vom cache deutlich größer als jener der logik, und das obwohl AMD im verhältnis zum cache deutlich mehr logiktransistoren hat im vergleich zu intel.

[turboschlumpf]

eben nicht
der weg mit dem cache ist nicht der günstigste aber sicherlich ein guter um die leistung weiter zu steigern und die mhz auf einem normalem niveau zu halten
Wäre der Weg mit dem Cache nicht der sinnvollste, so würde ihn Intel auch nicht wählen.

[w0mbat]

Wäre der Weg mit dem Cache nicht der sinnvollste, so würde ihn Intel auch nicht wählen.

Der war gut ;D

"Wären immer mehr MHz nicht der sinnvollste, würde ihn Intel auch nicht wählen."

[Wuge]

Der war gut ;D

"Wären immer mehr MHz nicht der sinnvollste, würde ihn Intel auch nicht wählen."

Macht Intel das?

[catamaran]

Macht Intel das?
Hat Intel diesen Weg mit der P4-Architektur nicht jahrelang beschritten und am Ende als gescheitert erkannt?

[Wuge]

Nicht als gescheitet. Als mittelfristig suboptimale Lösung....

Ob man beim Cache irgendwann zur gleichen Erkenntnis kommt steht in den Sternen. Nach aktuellem Stand ist dem nicht so.

[mapel110]

Na man wird wohl in Zukunft L3 und L4 Cache einführen. Desto mehr Cores, desto mehr Cache verbaut man ja. Und da machts Sinn, das etwas zu entkoppeln und sagen wir mal 4 Cores einen L3 Cache anzubieten, als allen 4 Cores den L2 größer zu machen.

[Gast]

Na man wird wohl in Zukunft L3 und L4 Cache einführen. Desto mehr Cores, desto mehr Cache verbaut man ja. Und da machts Sinn, das etwas zu entkoppeln und sagen wir mal 4 Cores einen L3 Cache anzubieten, als allen 4 Cores den L2 größer zu machen.


nicht zwangsläufig, das macht nur sinn wenn man dadurch den L2-cache deutlich schneller machen kann bzw. der L3-cache nicht zu langsam ist um bei einem L2-miss zuviel leistung zu kosten.

gerade bei intels inklusivem cachedesign sind viele cacheebenen eher kontraproduktiv.

[Gast]

Hat Intel diesen Weg mit der P4-Architektur nicht jahrelang beschritten und am Ende als gescheitert erkannt?

der Pentium 4 war mit dieser taktik jahrelang sehr gut. als man erkannte dass dieser weg nicht der beste ist hat man ihn auch wieder verlassen.

[RavenTS]

nicht zwangsläufig, das macht nur sinn wenn man dadurch den L2-cache deutlich schneller machen kann bzw. der L3-cache nicht zu langsam ist um bei einem L2-miss zuviel leistung zu kosten.

gerade bei intels inklusivem cachedesign sind viele cacheebenen eher kontraproduktiv.

Gerade in der "Umstellphase" bezüglich Multi-Core-Support kann aber solch ein gemeinsamer Cache besser sein, als L2-Cache, den wirklich nur jeder Kern einzeln ansprechen kann. Selbst wenn der etwas langsamer ist, hat man dann beispielsweise bei Singlethreaded-Anwendungen deutlich mehr Cache zur Verfügung, sprich Cache bleibt nicht ungenutzt...

[catamaran]

der Pentium 4 war mit dieser taktik jahrelang sehr gut. als man erkannte dass dieser weg nicht der beste ist hat man ihn auch wieder verlassen.

Netburst sollte doch noch viel höhere Taktraten ermöglichen (siehe alte Roadmaps).

Was den Cache angeht glaube ich vorerst auch nicht an eine Entkoppelung von L2 zu L3 Cache. Das macht die Logik für DC nicht einfacher.

[Nakai]

Der war gut ;D

"Wären immer mehr MHz nicht der sinnvollste, würde ihn Intel auch nicht wählen."

Takterhöhung ist die beste Skalierbarkeit.

Gerade in der "Umstellphase" bezüglich Multi-Core-Support kann aber solch ein gemeinsamer Cache besser sein, als L2-Cache, den wirklich nur jeder Kern einzeln ansprechen kann. Selbst wenn der etwas langsamer ist, hat man dann beispielsweise bei Singlethreaded-Anwendungen deutlich mehr Cache zur Verfügung, sprich Cache bleibt nicht ungenutzt...

Der K8L ist doch das beste Beispiel dafür.
Etwas langsamer Unified-Cache und schnellerer spezifizierter Cache, wobei AMD-Prozzis eh nicht so cachegeil sind wie die von Intel.^^


mfg Nakai

[turboschlumpf]

Der war gut ;D

"Wären immer mehr MHz nicht der sinnvollste, würde ihn Intel auch nicht wählen."
Ich weiß nicht was an meiner Aussage so witzig sein soll.

=Floi= meinte, mehr Cache sei nicht der günstigste Weg, um die Leistung von CPUs weiter zu steigern. Das kann aber niemand von uns beurteilen: Weniger Cache erhöht zwar die Anzahl an CPUs die man aus einem Wafer schneiden kann, im Gegenzug verringert sich aber die Pro-MHz-Leistung, weshalb Intel die Taktrate der CPUs erhöhen müsste, was wiederum die Ausbeute an verwertbaren CPUs verringern würde.

Gäbe es einen besseren/günstigeren/sinnvolleren Weg als denjenigen, den Intel im Moment gewählt hat, dann würde Intel die Core-2-CPUs nicht so bauen wie Intel sie baut. Behaupte ich jetzt einfach mal so.

Aber auf jeden Fall kann das nur Intel beurteilen und kein Außenstehender.

Der K8L ist doch das beste Beispiel dafür.
Etwas langsamer Unified-Cache und schnellerer spezifizierter Cache
K8L hat halt 4x 512 KiB L2-Cache und 2 MiB shared L3-Cache.
Intels Yorkfield bekommt dagegen 2x 6 MiB shared L2-Cache.

Was ist jetzt besser?

Ich meine K8L hat trotz L3-Cache nicht annähernd so viel Cache wie Yorkfield.

wobei AMD-Prozzis eh nicht so cachegeil sind wie die von Intel.^^
Du hast das jetzt negativ für Intel formuliert.

Man könnte es aber auch negativ für AMD formulieren und sagen: AMD-CPUs profitieren lange nicht so sehr von mehr Cache wie Intel-CPUs.

Oder noch negativer: Selbst wenn AMD-CPUs genauso sehr von mehr Cache profitieren würden, würde AMD es wahrscheinlich nicht schaffen, CPUs mit deutlich mehr Cache sinnvoll (!) zu fertigen.

[haifisch1896]

Schau Dir doch mal die Netburst-Architektur an. Auch da hat der Cache im Gegensatz zu den XPs ne Menge gerissen, wenn man P4 und Celeron miteinander vergleicht.
Und ob ich nun einen Barton oder T-Bred hatte, war wurscht. Die Leistung war annähernd die selbe und extrem stark.

[Gast]

Der K8L ist doch das beste Beispiel dafür.
Etwas langsamer Unified-Cache und schnellerer spezifizierter Cache, wobei AMD-Prozzis eh nicht so cachegeil sind wie die von Intel.^^


wobei wir nicht wissen, wie gut der K8L wirklich ist. durch die (kompliziertere) exklusive cacheorganisation von AMD könnte es natürlich sinn machen, aber nur wenn AMDs L2-cache deutlich schneller als jener von intel ist. bis jetzt war die geschwindigkeit des caches nicht gerade AMDs stärke, auch einer der gründe das AMD-cpus kaum von größeren caches profitieren.

bei multicores verkompliziert sich das design mit dezidierten caches und vielen cacheebenen auch stark, um die cacheinhalte konsitent zu halten. das macht sich vor allem dann bemerkbar wenn eine anwendung mehrere cores nützt und nicht mehrere anwendungen parallel auf den verschiedenen cores laufen.

[turboschlumpf]

Schau Dir doch mal die Netburst-Architektur an. Auch da hat der Cache im Gegensatz zu den XPs ne Menge gerissen, wenn man P4 und Celeron miteinander vergleicht.
Und ob ich nun einen Barton oder T-Bred hatte, war wurscht. Die Leistung war annähernd die selbe und extrem stark.
Falls sich das auf mein Posting bezieht: Ich sehe keinen Zusammenhang zwischen meinem Posting und deiner Antwort; deine Antwort auf mein Posting ergibt keinen Sinn.

[BlackBirdSR]

Ca 150 250 Millionen Transistoren gehen für die 4MB-Cache drauf. Dann bleiben noch 43/2 Millionen für einen einzelnen Kern.
Abzüglich Redundanz etc ca 19 Millionen.


Intels offizielle Angabe für einen Conroe-Kern liegt sogar bei 19 Millionen Transistoren. Also viel Glück beim Schätzen gehabt ;)

Die Dokumente sind noch nicht öffentlich, aber ich werde sie posten sobald das der Fall sein sollte.

[Leonidas]

Wäre der Weg mit dem Cache nicht der sinnvollste, so würde ihn Intel auch nicht wählen.


Das muss nicht sein. Erstens entstammt die Theorie "mehr Cache, unbedingt!" noch aus P4-Tagen, wo man mit der Leistung zurückhing und dies über den Cache versuchte irgendwie wieder geradezubiegen. Und zweitens stand die Core2-Entwicklung ja gerade unter dem Schock des Athlon 64 - Intel mußte unbedingt deftig zurückschlagen und konnte natürlich vorher nicht perfekt ausrechnen, wieviel schneller man sein würde. Deswegen hat man wohl geklotzt statt gekleckert. Wenn man seinerzeit den jetzigen Performanceabstand gewusst hätte, hätte man möglicherweise auf nur 2 MB Cache für die Desktop-Modelle gesetzt.

Aber im übrigen sag ich ja nix gegen 4 MB Cache. Ich sag nur was gegen weitere Steigerungen: 6 MB, 8 MB, 12 MB? Das fängt an, richtig viel Die-Fläche zu kosten, was sich dann für die 5+5+5% Performance nicht mehr lohnt.

[BlackBirdSR]

Aber im übrigen sag ich ja nix gegen 4 MB Cache. Ich sag nur was gegen weitere Steigerungen: 6 MB, 8 MB, 12 MB? Das fängt an, richtig viel Die-Fläche zu kosten, was sich dann für die 5+5+5% Performance nicht mehr lohnt.

Mit neueren Prozessen wird die zusätzliche DIE-Fläche frei. Der Sweatspot für die Produktion liegt angeblich irgendwo zwischen 80 und 140mm^2.
Irgendwie muss man die DIE ja füllen. Und nichts ist in dieser Hinsicht billiger als Cache.
Für 5+5+5% Performance muss man einen geradezu extremen Aufwand treiben wenn man das durch Logik bewerkstelligen will.

Also warum nicht Cache stattdessen nutzen? Relativ billig, geringe Verlustleistung, hohe Redundanz.

Was spricht dagegen?

[Stone2001]

Das muss nicht sein. Erstens entstammt die Theorie "mehr Cache, unbedingt!" noch aus P4-Tagen, wo man mit der Leistung zurückhing und dies über den Cache versuchte irgendwie wieder geradezubiegen.
Ich glaube die Theorie "mehr Cache, unbedingt" ist wesentlich älter. Seitdem die Prozessorgeschwindigkeit schneller als die RAM-Geschwinidigkeit ist, versucht man diese Lücke mittels schneller Zwischenspeicher zu verkleinern.
Nur sind wir erst seit dem PIV an einem Punkt angekommen, in dem eine weitere Leistungsteigerung der Prozessorperformance auf normalem Wege zu kompliziert, zu aufwendig oder schlicht zu teuer ist. Eine Vergrößerung des Caches dagegen ist einfach und wird (wahrscheinlich) vom Computer erledigt. Und wenn die Chip-Fläche sowieso vorhanden ist, kann man sie ruhig mit Cache verbrauchen.

Und zweitens stand die Core2-Entwicklung ja gerade unter dem Schock des Athlon 64 - Intel mußte unbedingt deftig zurückschlagen und konnte natürlich vorher nicht perfekt ausrechnen, wieviel schneller man sein würde. Deswegen hat man wohl geklotzt statt gekleckert. Wenn man seinerzeit den jetzigen Performanceabstand gewusst hätte, hätte man möglicherweise auf nur 2 MB Cache für die Desktop-Modelle gesetzt.
hmm, hast du "Beweise" für diese Aussage? (Wenn es sein muß, unterschreibe ich auch einen NDA dafür)
Ich habe leider keine, aber ich gehe stark davon aus, dass die Simulationswerkzeuge von Intel ausreichend mächtig sind, um Intel eine relativ genaue Preformanceaussge über ihren neuen Prozessor zu ermöglichen.

Aber im übrigen sag ich ja nix gegen 4 MB Cache. Ich sag nur was gegen weitere Steigerungen: 6 MB, 8 MB, 12 MB? Das fängt an, richtig viel Die-Fläche zu kosten, was sich dann für die 5+5+5% Performance nicht mehr lohnt.
Aber was mit der Die-Fläche machen, wenn man sie nicht für Logik verwenden kann?

[Gast]

Mal ganz losgelöst von aktuellen CPU-Implementationen:
Eine (PC-)CPU verarbeitet Programme, die zu Anfang im Hauptspeicher liegen. So, nun schalten wir mal sämtliche Cachespeicher und Prefetch-Logiken ab und überlegen uns, wie schnell die CPU bei der Verarbeitung des Programms wäre. Im nächsten Schritt transportieren wir das Programm idealerweise komplett in einen Cache auf dem CPU-Die. Werden wir einen Unterschied sehen?

Nichts bremst eine CPU so sehr ab, wie wenn Daten aus dem Hauptspeicher geholt werden müssen. Idealerweise sollte diese Bremse (fast) vollständig verschwinden und die Applikation paßt in einen on-Die Cache. Caches tragen erheblich zur Auslastung der Pipelines bei, selbst wenn sie so ausgefeilt ist, wie die des Core2.

Es gibt hier auch Gesetz des abnehmenden Ertrages bei größer werdenden Cache. Schließlich wachsen die Applikationen im Laufe der Zeit mit.

Und womit sollte man sonst die Die-Fläche eines neuen Prozesses füllen? Mehr Cores und mehr Cache sind die aktuellen Renner, weil relativ einfach und günstig zu implementieren. Die frei Fläche mit Logik zu füllen, die die Verarbeitungsgeschwindigkeit der Pipes weiter steigert, ist weitaus komplizierter und nur langfristig (über neue Microarchitekturen) realisierbar.

Außerdem kann aus fertigungstechnischen Gründen eine bestimmte Die-Größe nicht sinnvoll unterschritten werden, sonst wird's wieder teuerer. Schließlich muß die CPU mit der (PC-)Peripherie noch kommunizieren können.

[Haarmann]

BlackBirdSR

Absolut richtig.

Zudem: Die Fertigungsfortschritte überflügeln wohl die Architekturfortschritte bei Weitem. Da kochen alle nur mit dem gleichen Wasser.
Von 90nm Strukturen zu 45nm Strukturen vervierfacht sich quasi die Fläche innert recht kurzer Zeit.

[mapel110]

Intel fehlt noch der Memory Controller in der CPU.

Auch wenns offtopic ist, kurze Zwischenfrage: wie läuft das bei mehreren Cores mit also mehreren Memorycontrollern? Beißen die sich nicht gegenseitig? Gibts dazu irgendwo nen Techartikel, wie das läuft?

[Bokill]

... wie läuft das bei mehreren Cores mit also mehreren Memorycontrollern? Beißen die sich nicht gegenseitig? Gibts dazu irgendwo nen Techartikel, wie das läuft? Bei dem Cell gibts einen Ringbus (Rambus Technologie), der die CPU Kerne verbindet, daran hängt auch der Speicherkontroller (auch Rambus Technologie).

Bei dem Niagara (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=322), Niagara 2 (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=431) ist eine Fabric zwischen den CPU-Kernen (bzw. den Caches) und den Speichercontrollern.

Ähnlich haben es auch RMI, P.A.Semi gelöst.

Bei IBM mit den Multi Chip Modul sind ein ganzer Zoo von Interconnects implementiert. Das wird im Vergleich vom Power5 (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=443)+ zum Power6 (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=437) noch weiter verfeinert.

Bei AMD wird die SRQ (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=53) zu einer Multicorefabric irgendwann anwachsen, die Xbar (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=20) dahinter ist die Schnittstelle für SRQ, HyperTransport, L3 Cache (vermutlich), Speicherkontroller.

Intel wird wohl auch irgendwo eine Lösung dafür finden ... wenns Alle können, dannn muss auch Intel eine Lösung für massive Multicores haben.

MFG Bobo(2007)

[Gast]

Soweit ich weiß hat auch ein Dualcore-K8 nur einen Speichercontroller bzw. zwei für Dualchannel.

[mapel110]

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2925
hab ich doch recht gehabt mit dem shared Cache für mehrere Cores. :)

[Stone2001]

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2925
hab ich doch recht gehabt mit dem shared Cache für mehrere Cores. :)
Shared Caches für Multicore-Architekturen sind doch nichts neues! Selbst im Desktop-Markt gibt es mit dem Conroe schon Shared-Cache-Architekturen. Auch AMD wird mit dem Barcelona-Core den Shared-Cache einführen (zwar auf L3-Ebene und nicht, wie Intel auf L2-Ebene, aber AMD konnte sich durch das MOESI-Protokoll es leisten bisher auf Shared Caches zu verzichten).

Bei deinem Link ist aber vorallem die Art, wie Intel ihren 80-Kern-Prozessor (ich kann mir nicht helfen, aber das Design errinnert mich gewaltig an MIT RAW) mit Daten versorgen will interessant.

[turboschlumpf]

Bei Tera-scale ist das Interessante ja nicht der Shared-, sonder der Stacked-Cache.

[Gast]

http://ark.intel.com/Product.aspx?id=35163

291 Millionen Transistoren - stimmt die Angabe?

Ich denke die Zahl stimmt für 4MB L2 Cache.
Core 2 mit 2MB L2 Cache hat AFAIK um die 167 Millionen Transistoren.

[Gast]

Intels offizielle Angabe für einen Conroe-Kern liegt sogar bei 19 Millionen Transistoren.
Wo findet man diese Angabe?

[Spasstiger]

Ich denke die Zahl stimmt für 4MB L2 Cache.
Core 2 mit 2MB L2 Cache hat AFAIK um die 167 Millionen Transistoren.
Es könnte ein Conroe-2M sein, dann stimmen die 291 Mio. Transistoren. Mein Core 2 Duo E4300 mit 2 MiB L2-Cache ist auch ein Conroe-2M.

/EDIT: Conroe-2M = Conroe mit teildeaktiviertem Cache

[Gast]

Conroe-2M?

Den Wert findet man hier bei mehreren Modellen: http://ark.intel.com/ProductCollection.aspx?familyId=26548

Habe mal mehrere durchgeklickt.

[Gast]

151,6 Millionen Transistoren für einen Pentium Dual-Core (Mobil).
http://de.wikipedia.org/wiki/Intel_Pentium_Dual-Core_(Mobil)

Merom-1024: 167 Millionen Transistoren
Ist da einfach ein Teil des L2 Caches deaktiviert oder wieso hat der soviel Transistoren im Vergleich zu Allendale (167m Transistoren) bzw. dem Core 2 mit 2MB Cache?

[AnarchX]

Die ersten Pentium Dual-Core für Notebooks waren Yonah, also Core "1" CPUs.

[Gast]

Kann es sein, dass Intel bei Angaben zu den Transistoren sich ähnlich verhält wie mit den TDP-Angaben?
Eine Angabe, die einfach für alle genommen wird (unabhängig vom genauem Typ, Stepping oder deaktivierten Caches)?

[AnarchX]

Es wäre denkbar, dass Intel bei den Mobilen CPUs generell die Dies mit vollem Cache (also kein Allendale/Merom-2M oder Wolfdale/Penryn-3M verwendet) um eine bessere Wärmeübetragung bei den Heatspreader-losen CPUs zu haben.

Oder es wird in der ark einfach ungenau geführt.

[Gast]

Oder es wird in der ark einfach ungenau geführt.
Das vermute ich.

Ich frage wegen dieser Äußerung:
"Your assertion that Merom is 167 M transistors is simply in error. The counter-example I gave of the T5670 is a Merom processor. After checking Intel's documentation, I find that all the T5xxx series are listed as having 291 M transistors and 2 MB L2 cache."
http://markstechchat.blogspot.com/2010/03/ipad-sage-week-6-apples-mobile-device.html?showComment=1268413687380#c1046658444546853694

[Leonidas]

Oftmals werden diese Prozessoren mit kleineren Caches gar nicht wirklich hergestellt, sondern komplett aus der Produktion der Prozessoren mit den größeren Caches entnommen. Beispielsweise der Conroe-2M - eine reine Kunstbezeichnung, denn technisch stellt Intel so etwas nicht her. In der Produktion gibt es nur den Conroe, und der wird dann für Conroe-2M und Conroe-4M gleichermaßen genutzt.

Und damit haben solche Prozessoren natürlich überall die gleiche Transistorenanzahl. Wobei es sicherlich besser wäre seitens Intel, wenn man bei so was wie dem Conroe-2M nur die Anzahl der aktiven Transistoren angeben würde, die inaktiven Transistoren sind schließlich herzlich uninteressant.

[Coda]

Die Anzahl der Transistoren an sich ist uninteressant.

[Gast]

Macht aber doch das DIE größer.

[Gast]

Macht aber doch das DIE größer.


Die DIE-Größe ist uninteressant (zumindest für den Kunden)

[Savay]

interessant sind doch eh nur die produktionskosten/wafer die letztlich die ∅-produktionskosten pro einheit ergeben, plus der fixen kosten für entwicklung etc. pp umgelegt auf die zu erwartende stückzahl.

bekanntermaßen ist es im grunde ja billiger, je größer der anteil der gesamtfläche auf einem wafer ist, der vom cache bestimmt wird.
caches sind nunmal weniger teuer als logiktransistoren, da produktionsfehler in letzteren wesentlich schlechter über redundanz abfangbar sind und eher zu einem totalausfall der kompletten "einheit" führt als umgekehrt.

insofern sind CPUs mit teildeaktivierten caches an sich doch eine prima sache denn es macht die gesamte fertigung billiger da die effektive ausbeute steigt...warum sich also gedanken über die "aktiven" transistoren machen?! von dem punkt aus ist es dann doch eh nicht weit auch gleich noch die durschnittliche auslastung bzw auslastbarkeit der transistoren mit in die rechnung der "aktiven transistoren" rein zu bringen ;)

als kunde zählt doch eh nur ∅-Leistung/(Anschaffungs+Betriebskosten) :)

[roidal]

Ca 150 250 Millionen Transistoren gehen für die 4MB-Cache drauf. Dann bleiben noch 43/2 Millionen für einen einzelnen Kern.
Abzüglich Redundanz etc ca 19 Millionen.
Das ist doch recht viel, wenn man die reine Kerngrößen des P6 mit halbem L1-Cache des Core2 bei 9.5 Millionen sieht, und einen K7 mit 152KB L1-Cache bei 22 Millionen.
An den K8 mit ca 35 Millionen kommt natürlich nichts heran ;)

Was für Redundanz? Es gibt zwar immer wieder Leute welche das erwähnen aber bis jetzt hab ich noch keine "Beweise" dafür gesehen, mal davon abgesehen das es wahrscheinlich 0 sinn machen würde.

[BlackBirdSR]

Was für Redundanz? Es gibt zwar immer wieder Leute welche das erwähnen aber bis jetzt hab ich noch keine "Beweise" dafür gesehen, mal davon abgesehen das es wahrscheinlich 0 sinn machen würde.

Fand Intel schon damals nicht
http://download.intel.com/technology/itj/q41997/pdf/manufacturing.pdf

[Coda]

Also Cache-Redundanz ist ganz sicher vorhanden.

[roidal]

Fand Intel schon damals nicht
http://download.intel.com/technology/itj/q41997/pdf/manufacturing.pdf

Interessant, aber da gehts jetzt hauptsächlich um die caches? (hatte noch keine zeit das genau durchzulesen).

[Coda]

Redundanz bei CPU-Logik halte ich auch eher für unwahrscheinlich. So ein Punktdefekt ist ja schon ziemlich groß. Damit sich das lohnt müsste man also ziemlich große Blöcke kopieren und sowas sieht man auf den Die-Shots eigentlich nicht.

ATI macht das ja in ihren Streamprozessoren.

[Flyinglosi]

unser Professor in integrierten Schaltungen arbeitet teilweise mit Intel zusammen und meinte vorige Woche in der Vorlesung das es beim I7 keinerlei Redundanz mehr gebe.

mfg Stephan

[Coda]

Auch nicht beim Cache? Kann ich mir ehrlich gesagt nicht vorstellen.

[BlackBirdSR]

Ich mir auch nicht. Der Gewinn ist bei sehr geringen Kosten einfach zu groß.

@Roidal: Von Logik-Redundanz war auch nie die Rede

[roidal]

Redundanz bei CPU-Logik halte ich auch eher für unwahrscheinlich. So ein Punktdefekt ist ja schon ziemlich groß. Damit sich das lohnt müsste man also ziemlich große Blöcke kopieren und sowas sieht man auf den Die-Shots eigentlich nicht.

ATI macht das ja in ihren Streamprozessoren.

Naja, in diesem Fall eher redundanz in dem Sinne von deaktivieren der defekten "Kerne"?

[roidal]

Ich mir auch nicht. Der Gewinn ist bei sehr geringen Kosten einfach zu groß.

@Roidal: Von Logik-Redundanz war auch nie die Rede

sry, ich dachte du redest von allgemeiner Redundanz, also praktisch alles doppelt.