Integrierter speicher Controller & Cachesize
-
Gregor schrieb:
Und ein Zugriff auf den Cache ist natürlich _viel_ schneller als ein entsprechender Zugriff aufs RAM. Auch wenn man Hypertransport hat.
Ja, aber eben nicht so dramatisch.
Gregor schrieb:
Man benötigt in jedem Fall Speicherhierarchien. Und es hängt davon ab, was man genau mit dem Rechner machen möchte, ob nun ein großer Cache mehr bringt oder eher eine schnellere Anbindung des Hauptspeichers.
Eine schnelle Anbindung des Hauptspeichers ist in jedem Fall besser. Mehr Cache kann deren Vorteil maximal egalisieren, aber nie selbst von Vorteil sein. Das musste mittlerweile auch Intel einsehen. Deshalb verabschieden sie sich ja vom FSB und verwenden zukünftig QuickPath. Wobei es da noch einige andere wichtige Kriterien gab.
Gregor schrieb:
...wenn man sich die Benchmarks so ansieht, dann ist zumindest nicht unbedingt offensichtlich, dass Intel durch den fehlenden IMC einen echten Nachteil hat.
Oha, schau noch mal genau hin. Gerade was Latenz und Bandbreiten Benchmarks betrifft, ist AMD meilenweit voraus. Trotz 3 Jahre älterer Architektur. Der K10 wird da sicherlich nochmal ordentlich drauflegen. Es gibt auch Tests, wo Intel CPUs mit verschiedenen L2 Caches gebencht wurden, zB 2 MB gegen 4 MB. Da gibt es teilweise Unterschiede im zweistelligen Prozentbereich. Bei AMD ist das weniger dramatisch.
Gregor schrieb:
Mir persönlich kann der Cache zumindest nicht groß genug sein. 512MB Cache fände ich persönlich toll.
...aber da muss ich wohl noch ein paar Jahre warten.Nein, das ist absolut unsinnig. Cache verschwendet nur unnötig Die Fläche. Und erhöht zudem auch die Leistungsaufnahme. Stattdessen mehr Kerne, mehr ALUs, zusätzliche Logikeinheiten oder was auch immer für Verbesserungen des eigentlichen Kerns sind definitiv besser. Alles was man braucht, ist eine effizient funktionierende Cache Hierarchie und nicht Unmengen an Cache. AMD hat das durch den IMC und Hypertransport bereits ansatzweise realisiert, Intel nicht.
Die Entwicklung geht zudem in Richtung beliebig vieler Kerne. Dh, man wird in Zukunft sowieso nicht mit Unmengen an Cache um sich schmeissen, erst recht nicht die dedizierten. Was aber nicht heisst, dass shared Caches wie der L2 beim Core 2 oder L3 beim K10, nicht grösser werden.
-
rapso schrieb:
Gregor schrieb:
Hypertransport kann auch nicht das prinzipielle Problem lösen, dass die Entwicklung der Geschwindigkeit des RAMs nicht mit der Entwicklung der Rechenleistung von Prozessoren mithalten kann.
es ist aber eine loesung dafuer. denn bei intel tauschen die cpus (zumindestens >2kerne) die daten uebers ram aus, deswegen hat intel nen shared-L2-cache im coreduo. amd hat seperate caches (ausser jetzt im L3) und kann schon seit ewigkeiten 16cores gut skalierbar verbinden, weil sie das memoryproblem mit hypertransport (und somit direkter kern-verbindung) umgeht.
Zu den Geschwindigkeitsverhältnissen möchte ich mal folgenden Artikel ins Spiel bringen:
http://www.anandtech.com/IT/showdoc.aspx?i=3091&p=4
Da sind etliche AMD-Prozessoren (auch der neue) vertreten. ...und jetzt guckt euch mal die Latenzzeit bezüglich dem L2 Cache und dem RAM an.
Beim L2 Cache liegt die so bei ~5ns, beim RAM bei mehr als 50ns. Egal, ob man da einen integrierten Speichercontroller hat oder nicht. Das Problem mit der Latenzzeit kann der IMC also schonmal nicht lösen. Wenn man einen großen Datensatz hat und zufällige Zugriffe in diesem vornehmen muss, dann hat man also besser einen Cache, der groß genug ist, weil das RAM einen sonst massiv ausbremst. ...da kommen wir dann auch wieder zum Raytracing, wo das wohl so ist. Ich persönlich beschäftige mich manchmal etwas mit Direct Volume Rendering. Wenn man in dem Zusammenhang Raycasting betreibt, dann läuft das auch darauf hinaus, dass man den Datensatz nicht gerade in Speicherreihenfolge durchläuft. Ich kann mir in dem Zusammenhang durchaus Datensätze in der Größenordnung von 512MB vorstellen, deshalb kam mir diese Zahl beim Cache in den Sinn. Die Verbindung zum Hauptspeicher wird in diesem Fall durch die hohen Latenzzeiten sofort zum Flaschenhals und wenn man den Datensatz im Cache halten kann, dann macht das einen enormen Unterschied. Vor allem, wenn man viele Kerne hat: Das ist absolut gut zu parallelisieren, insofern wird die Speicheranbindung bei mehr Kernen zu einem immer stärkeren Flaschenhals.
Auch was die Bandbreite betrifft ist der L2 Cache dem RAM natürlich bei weitem überlegen. Auch das wird durch den IMC nicht prinzipiell verändert. Der IMC bringt bei der Bandreite vielleicht einen Faktor 2 oder so, aber der Cache ist demgegenüber dann immer noch um einen Faktor 2 bis 3 schneller.
...und ein Blick auf die Zugriffszeit auf die Caches der anderen Kerne lohnt sich in diesem Zusammenhang auch (ganz oben in dem verlinkten Artikel). Auch hier bringt Hypertransport keine prinzipielle Besserung. ...bei mehr Prozessoren würde man das aber wohl doch deutlich sehen.
Was ich sagen will ist zumindest folgendes: Es gibt Anwendungen, die durch einen großen Cache profitieren. Ein großer Cache hat andere Leistungsmerkmale als ein IMC. Das einzige Problem an dem großen Cache ist eigentlich, dass er für die jeweilige Anwendung immer noch zu klein sein kann. Wenn die Speicherzugriffe zufällig erfolgen und der Datensatz kleiner als der Cache ist (oder zumindest von der gleichen Größenordnung), dann hat man einen super schnellen Zugriff auf diese Daten. Wenn der Datensatz aber deutlich größer als der Cache ist, dann bringt der Cache praktisch gar nichts und man ist für den IMC dankbar, weil er momentan die beste Anbindung des Hauptspeichers bietet. Man kann nicht sagen, das eine ist besser und das andere schlechter: Beide Varianten haben ihre Vorteile. Der IMC ist natürlich stark im Vorteil, wenn sehr sehr große Datensätze in Speicherreihenfolge durchlaufen werden müssen. ...allerdings auch nur dann, wenn in diesem Zusammenhang die Speicheranbindung den Flaschenhals darstellt.
groovemaster schrieb:
Nein, das ist absolut unsinnig. Cache verschwendet nur unnötig Die Fläche. Und erhöht zudem auch die Leistungsaufnahme.
Du kannst mal davon ausgehen, dass ein Zugriff auf den Hauptspeicher mehr Energie verbraucht, als es ein Zugriff auf den Cache tut.
Insgesamt würde ich davon ausgehen, dass der Cache den Teil des Prozessors darstellt, der pro Fläche den kleinsten Verbrauch hat.Und von einer unnötigen Verschwendung von Die Fläche kann man auch nicht reden. Ganz auf den Cache kann man eh nicht verzichten. Auch die AMD-Prozessoren können das nicht. Ohne Cache wären die unglaublich lahm. Die Cache-Menge ist eine Frage der Optimierung. Und da spielt rein, welche Merkmale der Prozessor ansonsten hat, welche Nutzung des Prozessors man annimmt usw.. Natürlich führt ein IMC dazu, dass man im Vergleich zu einem Prozessor ohne IMC eher weniger Cache als sinnvoll erachten würde. Das heißt aber nicht, dass das der einzig richtige Weg ist.
Ich gehe auch davon aus, dass die Cache-Kapazität von Intel's Nehalem nicht gerade ansteigen wird. Man hat ja auch schon Bilder des Dies gesehen, nach denen man das etwa abschätzen kann. (Irgendwo stand, der hätte 12MB Cache, für mich sieht es allerdings eher nach 8MB Cache aus.) Der Prinzipielle Trend zu größeren Caches wird dadurch allerdings nicht beendet. Mehr Kerne benötigen auch mehr (shared) Cache. Vielleicht nicht unbedingt mehr Cache pro Kern, aber halt insgesamt mehr Cache. ...IMHO.
-
Gregor schrieb:
rapso schrieb:
Gregor schrieb:
Hypertransport kann auch nicht das prinzipielle Problem lösen, dass die Entwicklung der Geschwindigkeit des RAMs nicht mit der Entwicklung der Rechenleistung von Prozessoren mithalten kann.
es ist aber eine loesung dafuer. denn bei intel tauschen die cpus (zumindestens >2kerne) die daten uebers ram aus, deswegen hat intel nen shared-L2-cache im coreduo. amd hat seperate caches (ausser jetzt im L3) und kann schon seit ewigkeiten 16cores gut skalierbar verbinden, weil sie das memoryproblem mit hypertransport (und somit direkter kern-verbindung) umgeht.
Zu den Geschwindigkeitsverhältnissen möchte ich mal folgenden Artikel ins Spiel bringen:
http://www.anandtech.com/IT/showdoc.aspx?i=3091&p=4
Da sind etliche AMD-Prozessoren (auch der neue) vertreten. ...und jetzt guckt euch mal die Latenzzeit bezüglich dem L2 Cache und dem RAM an.
Beim L2 Cache liegt die so bei ~5ns, beim RAM bei mehr als 50ns. Egal, ob man da einen integrierten Speichercontroller hat oder nicht.
emm.. mit integriertem speichercontroller 59-76 ohne 112. pro zusaetzlichem core wird das noch wichtiger, da selbst lineares lesen durch konflickte zwischen den cores zu random lesen resultiert.
Das Problem mit der Latenzzeit kann der IMC also schonmal nicht lösen. Wenn man einen großen Datensatz hat und zufällige Zugriffe in diesem vornehmen muss, dann hat man also besser einen Cache, der groß genug ist, weil das RAM einen sonst massiv ausbremst...
ein datensatz der gross genug ist, da helfen dir grosse caches nichts, cachehits werden viel seltener. ab einer gewissen groesse ist ein schnellerer speichercontroller wichtiger.
...da kommen wir dann auch wieder zum Raytracing, wo das wohl so ist. Ich persönlich beschäftige mich manchmal etwas mit Direct Volume Rendering. Wenn man in dem Zusammenhang Raycasting betreibt, dann läuft das auch darauf hinaus, dass man den Datensatz nicht gerade in Speicherreihenfolge durchläuft. Ich kann mir in dem Zusammenhang durchaus Datensätze in der Größenordnung von 512MB vorstellen, deshalb kam mir diese Zahl beim Cache in den Sinn. Die Verbindung zum Hauptspeicher wird in diesem Fall durch die hohen Latenzzeiten sofort zum Flaschenhals und wenn man den Datensatz im Cache halten kann, dann macht das einen enormen Unterschied. Vor allem, wenn man viele Kerne hat: Das ist absolut gut zu parallelisieren, insofern wird die Speicheranbindung bei mehr Kernen zu einem immer stärkeren Flaschenhals.
rechnen wir mal durch, 512MB, der maximale l2-cache pro core 4MB, also bei deinen random reads eine deckung von 0.78%, (sagen wir mal optimischtisch 1%).
du hast also 0.01*5ns+0.99*112ns = 111ns durchschnittliche zugrieffszeit bei random zugriffen auf nem xeon. nun, selbst ohne cache hast du beim opteron weit unter 100ns an zugriffszeit.Auch was die Bandbreite betrifft ist der L2 Cache dem RAM natürlich bei weitem überlegen. Auch das wird durch den IMC nicht prinzipiell verändert. Der IMC bringt bei der Bandreite vielleicht einen Faktor 2 oder so, aber der Cache ist demgegenüber dann immer noch um einen Faktor 2 bis 3 schneller.
der IMC bringt diese faktoren auch wenn daten zwischen den caches ausgetauscht wird. die bandbreite zum ram wird davon nicht beeinflusst. du bist dann 2 bis 3mal schneller (weil eben cache2cache kopiert wird)
...und ein Blick auf die Zugriffszeit auf die Caches der anderen Kerne lohnt sich in diesem Zusammenhang auch (ganz oben in dem verlinkten Artikel). Auch hier bringt Hypertransport keine prinzipielle Besserung. ...bei mehr Prozessoren würde man das aber wohl doch deutlich sehen.
ehrlichgesagt trau ich der sache im artikel nicht. denn das zu messen ist sehr schwer. wenn du mit 'lock' arbeitest, wird zwischen allen caches gesynct und dann ist die performance eh im arsch. machst du das jedoch nicht, weisst du garnicht wann die daten uebertragen wurden (also cache2cache).
(an den sourcecode des tools kommt man wohl nicht so dran trotz link).
ich hatte aber gluecklicherweise letzte woche das selbe probiert (aus nem anderen grund). dabei hab ich einen thread auf einem core die selbe addresse lesen lassen, waehrend ein anderer auf dieser addresse dauernt inkrementiert hat. das lustige resultat ist, dass der lesende nur ca 18.6% der inkrementationen mitbekam (c2q) (ohne locks), mit locks waere es grundsaetzlich ueber den speichercontroller gegangen und waere recht langsam... ich wunder mich wie Michael S. das gemacht haben will
Was ich sagen will ist zumindest folgendes: Es gibt Anwendungen, die durch einen großen Cache profitieren. Ein großer Cache hat andere Leistungsmerkmale als ein IMC. Das einzige Problem an dem großen Cache ist eigentlich, dass er für die jeweilige Anwendung immer noch zu klein sein kann. Wenn die Speicherzugriffe zufällig erfolgen und der Datensatz kleiner als der Cache ist (oder zumindest von der gleichen Größenordnung), dann hat man einen super schnellen Zugriff auf diese Daten. Wenn der Datensatz aber deutlich größer als der Cache ist, dann bringt der Cache praktisch gar nichts und man ist für den IMC dankbar, weil er momentan die beste Anbindung des Hauptspeichers bietet. Man kann nicht sagen, das eine ist besser und das andere schlechter: Beide Varianten haben ihre Vorteile. Der IMC ist natürlich stark im Vorteil, wenn sehr sehr große Datensätze in Speicherreihenfolge durchlaufen werden müssen. ...allerdings auch nur dann, wenn in diesem Zusammenhang die Speicheranbindung den Flaschenhals darstellt.
wenn man nicht gerade die caches shared (ich glaube damit hat AMD seitens intel nicht gerechnet) ist ein IMC der einzige weg bei steigender corezahl kein performancedisaster zu haben (uebrigens haben die ersten P4HT das problem sehr stark, trotz einem cache, deswegen gibt es da so einige applikationen die mit HT langsammer laufen.)
Und von einer unnötigen Verschwendung von Die Fläche kann man auch nicht reden. Ganz auf den Cache kann man eh nicht verzichten. Auch die AMD-Prozessoren können das nicht. Ohne Cache wären die unglaublich lahm. Die Cache-Menge ist eine Frage der Optimierung. Und da spielt rein, welche Merkmale der Prozessor ansonsten hat, welche Nutzung des Prozessors man annimmt usw.. Natürlich führt ein IMC dazu, dass man im Vergleich zu einem Prozessor ohne IMC eher weniger Cache als sinnvoll erachten würde. Das heißt aber nicht, dass das der einzig richtige Weg ist.
man kann aber sehen, je mehr hirnschmalz in die speicheranbindung gesetzt wurde, desto kleiner auch die caches. intel haette trotz IMC noch ne menge cache haben koennen, es ist keine abwegung von IMC oder cache.
Ich gehe auch davon aus, dass die Cache-Kapazität von Intel's Nehalem nicht gerade ansteigen wird. Man hat ja auch schon Bilder des Dies gesehen, nach denen man das etwa abschätzen kann. (Irgendwo stand, der hätte 12MB Cache, für mich sieht es allerdings eher nach 8MB Cache aus.)
Nehalem hat nen IMC ;), der yorkfield im november wird schon 12MB haben.
Der Prinzipielle Trend zu größeren Caches wird dadurch allerdings nicht beendet. Mehr Kerne benötigen auch mehr (shared) Cache. Vielleicht nicht unbedingt mehr Cache pro Kern, aber halt insgesamt mehr Cache. ...IMHO.
pro kern werden's mehr cache werden, da sie ja um den speicher kaempfen. bei 4kernen kann man schon davon ausgehen dass nur 1/4 der speicherleistung pro kern zur verfuegung steht. es ist zwar weniger wegen shared cache bzw Hypertransport, aber dann wiederrum mehr wegen random zugriffen im ram (wenn die cores abwechselnd drankommen).
btw. wie waere es mit einem screen deines volumetracings im screenshot forum?
-
Frage: Hat der IMC nicht auhc den Vorteil, dass er sich nicht den FSB mit den ganzen anderen Sachen teilen muss, die noch so über den FSB laufen?
-
rapso schrieb:
btw. wie waere es mit einem screen deines volumetracings im screenshot forum?
Habe gerade nen Screenshot gepostet. Ist aber schon älter und den hatte ich hier auch schonmal gezeigt.
-
lol
Irgendwie witzig wie hier versucht wird die Vorteile eines grossen Caches wegzudiskutieren.
-
hustbaer schrieb:
lol
Irgendwie witzig wie hier versucht wird die Vorteile eines grossen Caches wegzudiskutieren.und dein nuetzlicher beitrag zur diskusion ist?
-
BTW: Wenn man sagt, dass ein großer Cache gegenüber dem IMC bezüglich der Rechenleistung eine Verschwendung von Die-Fläche darstellt, dann nimmt man ja implizit an, dass die AMD-Prozessoren pro Fläche eine deutlich höhere Rechenleistung als Intel-Prozessoren aufweisen. ...zumindest bei gleichen Strukturgrößen.
Da sind mal ein paar Die-Fotos und Größenangaben und so:
http://chip-architect.com/news/2007_02_19_Various_Images.html
Was man da an Die-Größe und Fertigungstechnik momentan wohl am ehesten vergleichen kann, ist der Merom-Prozessor mit dem Brisbane-Prozessor. Brisbane hat einen IMC, Merom einen großen Cache. Und die Größen sind mehr oder weniger ähnlich. ...mir ist in dem Zusammenhang nicht bekannt, dass der Brisbane-Prozessor dem Merom-Prozessor deutlich überlegen ist.
-
Gregor schrieb:
BTW: Wenn man sagt, dass ein großer Cache gegenüber dem IMC bezüglich der Rechenleistung eine Verschwendung von Die-Fläche darstellt, dann nimmt man ja implizit an, dass die AMD-Prozessoren pro Fläche eine deutlich höhere Rechenleistung als Intel-Prozessoren aufweisen. ...zumindest bei gleichen Strukturgrößen.
das ist deine interpretation. man sagt eher, dass intel weniger entwickelte logic hat und das mit massig cache kompensiert, weil sie es fertigen koennen und es wenig 'hirnschmalz' verbraucht.
http://www.trustedreviews.com/cpu-memory/review/2006/08/28/Intel-Core-2-Duo-Merom-Notebooks/p2 schrieb:
These are virtually the same as that as for Core Duo so what then are the differences between the mobile versions of the Core Duo and Core 2 Duo?
In a nutshell though the biggest difference over the Core Duo is the increase in Level 2 cache from 2MB to 4MB, which accounts for the transistor count increasing from 151 million to 291 million.
Da sind mal ein paar Die-Fotos und Größenangaben und so:
http://chip-architect.com/news/2007_02_19_Various_Images.html
Was man da an Die-Größe und Fertigungstechnik momentan wohl am ehesten vergleichen kann, ist der Merom-Prozessor mit dem Brisbane-Prozessor. Brisbane hat einen IMC, Merom einen großen Cache. Und die Größen sind mehr oder weniger ähnlich. ...mir ist in dem Zusammenhang nicht bekannt, dass der Brisbane-Prozessor dem Merom-Prozessor deutlich überlegen ist.
der vergleich haengt aber etwas, Merom ist fuer mobile. er hat 291MTransistoren waehrend der Brisbane 'nur' 221MTransistoren hat. waehrend AMD an allen ecken transistoren spart um im desktop noch schnell genug zu sein, baut intel unmengen von cache ein und verdoppelt fast den transistorcount beim mobile. dabei takten beide recht gleich (ich glaube 2.6ghz beim meron und 2.7 bei brisbane), wobei AMDs desktop cpus bestenfalls 65Watt ziehen, der merom zieht sicherlich nur die haelfte davon. du siehst, intel setzt rein auf die herstellungs-tech.
und performance? naja, du vergleichst eine K8 mit einer core architektur, der core vom k8 ist weit unterlegen. wenn du das mit der gleichen generation vergleichen willst, such dir nen P4 und nen K8 raus. ansonsten kannst du ja jetzt auch nen P5 mit nem k10 vergleichen.
-
@rapso: Natürlich haben Prozessoren mit einem großen Cache eine deutlich höhere Transistordichte als Prozessoren ohne einen solchen Cache. Der Cache stellt halt eine derart regelmäßige Struktur dar, dass man die Größen der einzelnen Bitzellen massiv optimiert. Aber letztendlich geht es ja nicht um die Anzahl der Transistoren, sondern um die Die-Fläche. Da unterscheiden sich Brisbane und Merom nicht sooo sehr: 10% oder so. Und beide haben 65nm Strukturen, insofern weiß ich nicht genau, was Du in diesem Zusammenhang mit mit dem Hinweis auf Intels bessere Prozesstechnologie meinst.
BTW: Ich glaube, die Desktopprozessoren unterscheiden sich bei Intel nicht besonders stark von den Mobilprozessoren. ...wenn man von der Taktung und ein paar weiteren Kleinigkeiten absieht. Die Daten, die da für den Merom stehen, werden in etwa auch für die Desktopvariante stimmen.
rapso schrieb:
man sagt eher, dass intel weniger entwickelte logic hat und das mit massig cache kompensiert
Du stellst das hier als allgemeinen Fakt dar, aber IMHO ist das doch eine sehr subjektive Sichtweise. Wer ist eigentlich "man"? Zur P4-Zeit hätte ich Dir hier zugestimmt, aber momentan sieht es IMHO anders aus. Das Design des Core2 ist wirklich gut. Was soll denn da bei AMD die bessere Logik sein? Der integrierte Speichercontroller? Und das war es dann? Du redest da über einen ganz kleinen Teil des Prozessors. Und IMHO stellt der auch keine wirkliche Herausforderung bezüglich dem Design dar. "Speichercontroller" sind ja nichts neues: Das einzig neue am integrierten Speichercontroller ist letztendlich, dass man sich dazu entscheidet, diesen Teil des Gesamtsystems in den Prozessor zu integrieren. Bei Intel ist er halt bisher in der Northbridge anzutreffen. ...die auch von Intel hergestellt wird, insofern hat Intel das Know-How für Speichercontroller durchaus. Wo man ihn jetzt platziert, das ist einfach nur eine Frage des Designs.
-
Gregor schrieb:
BTW: Wenn man sagt, dass ein großer Cache gegenüber dem IMC bezüglich der Rechenleistung eine Verschwendung von Die-Fläche darstellt, dann nimmt man ja implizit an, dass die AMD-Prozessoren pro Fläche eine deutlich höhere Rechenleistung als Intel-Prozessoren aufweisen. ...zumindest bei gleichen Strukturgrößen.
Irgendwie verstehe ich nicht so ganz, wie du zu diesem Schluss kommst.
Gregor schrieb:
Was man da an Die-Größe und Fertigungstechnik momentan wohl am ehesten vergleichen kann, ist der Merom-Prozessor mit dem Brisbane-Prozessor. Brisbane hat einen IMC, Merom einen großen Cache. Und die Größen sind mehr oder weniger ähnlich. ...mir ist in dem Zusammenhang nicht bekannt, dass der Brisbane-Prozessor dem Merom-Prozessor deutlich überlegen ist.
Ausschlaggebend für die Leistung ist letztendlich immer noch die eigentliche Architektur. Und der K8 ist immerhin 3 Jahre älter. Vor allem sollte man auch bedenken, dass die Vorteile eines IMC und Hypertransport vor allem bei Multisockelsystemen zum tragen kommen. Die helfen Intel auch grosse Caches nichts mehr.
Gregor schrieb:
@rapso: Natürlich haben Prozessoren mit einem großen Cache eine deutlich höhere Transistordichte als Prozessoren ohne einen solchen Cache. Der Cache stellt halt eine derart regelmäßige Struktur dar, dass man die Größen der einzelnen Bitzellen massiv optimiert. Aber letztendlich geht es ja nicht um die Anzahl der Transistoren, sondern um die Die-Fläche. Da unterscheiden sich Brisbane und Merom nicht sooo sehr: 10% oder so. Und beide haben 65nm Strukturen, insofern weiß ich nicht genau, was Du in diesem Zusammenhang mit mit dem Hinweis auf Intels bessere Prozesstechnologie meinst.
Fertigungsprozess ist nicht gleich Fertigungsprozess. Nur weil beide Unternehmen momentan CPUs in 65nm Strukturbreite auf dem Markt haben, heisst das noch lange nicht, dass diese auch die gleichen Merkmale aufweisen.
Gregor schrieb:
Du stellst das hier als allgemeinen Fakt dar, aber IMHO ist das doch eine sehr subjektive Sichtweise. Wer ist eigentlich "man"? Zur P4-Zeit hätte ich Dir hier zugestimmt, aber momentan sieht es IMHO anders aus. Das Design des Core2 ist wirklich gut. Was soll denn da bei AMD die bessere Logik sein? Der integrierte Speichercontroller?
Plus Hypertransport. Für dich ist der Unterschied vielleicht kaum relevant, und das mag für den Desktop- und Mobilbereich sogar fast stimmen, wenn wir aber Richtung Multisockelsystemen oder gar HPC gehen, ist das ein entscheidender Vorteil, da die Skalierung deutlich besser funktioniert.
Gregor schrieb:
Und das war es dann? Du redest da über einen ganz kleinen Teil des Prozessors. Und IMHO stellt der auch keine wirkliche Herausforderung bezüglich dem Design dar.
Wenn du dich da mal nicht täuschst.
Wenn es so einfach wäre, würde Intel wohl nicht erst 5 Jahre nach AMD mit einer vergleichbaren Lösung daherkommen. Ich denke, die Entwicklung ist nicht gerade trivial.
-
groovemaster schrieb:
Wenn du dich da mal nicht täuschst.
Wenn es so einfach wäre, würde Intel wohl nicht erst 5 Jahre nach AMD mit einer vergleichbaren Lösung daherkommen. Ich denke, die Entwicklung ist nicht gerade trivial.Vielleicht ist es ja auch einfach so, dass für Intel der IMC erst jetzt so langsam interessant wird. Du hast ja vorhin zu Recht auch schon darauf hingewiesen, dass die gleiche Strukturgröße nicht automatisch heißt, dass die Prozesstechnologie vergleichbar ist. Man hört ja auch immer wieder von weiteren Unterschieden. ...zum Beispiel hat AMD SOI und Intel nicht, dafür hat Intel demnächst diese "High-k Materialien", die AMD nicht hat. Ein interessanter Punkt, der mir gerade aufgefallen ist, ist allerdings auch, dass Intel bei gleichen Strukturgrößen eine wesentlich höhere Speicherdichte als AMD im Cache realisiert. ...zumindest was den Merom/Brisbane-Vergleich betrifft. Auf der Fläche, die der integrierte Speichercontroller benötigen würde, kann Intel also vermutlich deutlich mehr Cache unterbringen als AMD. ...naja ~50% mehr. Das kann bei der Designentscheidung, ob man nun einen IMC oder doch lieber mehr Cache einbaut, dann durchaus zu unterschiedlichen Ergebnissen führen.
Was den K10 betrifft: Wenn man sich mal anguckt, wie groß das Die von dem ist, dann muss er im Prinzip von seiner Rechenleistung her mindestens 2,5 mal so viel wie der Brisbane liefern. ...wenn man von einer deutlichen Verbesserung der Logik auf dem Chip ausgeht, müsste sogar noch mehr drin sein. Ich weiß nicht, ob die ersten Tests des Barcelonas auf ein solches Leistungspotential hindeuten. Naja, aber warten wir mal ab, was die Desktopvariante von diesem Prozessor bringt.
-
Ich hab' mal ne ganz doofe Frage zu IMC + "Hypertransport" (ok, mehrere): ist damit gemeint dass jede CPU ihren "eigenen" Speicher hat, und wenn CPU 1 was aus dem Speicher von CPU 2 will, CPU 1 das über "Hypertransport" an CPU 2 signalisiert, CPU 2 fetcht das dann und schickt es über "Hypertransport" an CPU 1 rüber...? Und dauert das dann nicht (deutlich) länger als wenn man nen FSB verwendet?
Anders wüsste ich zumindest nicht wie das funktionieren soll wenn der "MC" eben "I" ist, also der Memory Controller in der CPU sitzt.Und wenn diese meine Vermutung stimmt, sprechen wir dann hier nicht von einem NUMA System? Ist das nicht ziemlich langsam wenn das OS und die Programme nicht darauf abgestimmt sind?
Und... kann z.B. ein Windows Server 2003 das über die MMU oder sonstwie so hinbiegen dass es automatisch erkennt welcher Thread welchen Speicher verwendet, und diesen dann entsprechend "umschaufelt", damit er lokal zur CPU liegt? Bzw. wenigstens erkennen welchen Speicher der Thread vorzugsweise verwendet und ihn dementsprechend auf der "passenden" CPU schedulen?
Können BSD/Linux/Solaris das?Und nochwas anderes: wie funktioniert "Hypertransport" - ist das ein Bus System wo einfach alle CPUs draufhocken? Oder ist es so dass jede CPU z.B. 4 Links hat, über die sie mit 4 anderen CPUs kommunizieren kann, und wenn es mehr als 5 CPUs im System gibt muss der Request über eine oder mehrere "Zwischenstationen" weitergeleitet werden?
-
Gregor schrieb:
Das kann bei der Designentscheidung, ob man nun einen IMC oder doch lieber mehr Cache einbaut, dann durchaus zu unterschiedlichen Ergebnissen führen.
Letztendlich ist entscheidend, was hinten raus kommt. Und mit dem Opteron hat AMD seinerzeit bewiesen, dass ihre Technologie, vor allem im Serverbereich, Intel deutlich überlegen war. Da konnte der P4 nichts entgegensetzen. Erst mit einer besseren Architektur, dem Core 2, konnte Intel wieder aufholen. Und solche Punkte, eben eine effiziente Speicheranbindung, effiziente Kommunikation in Mehrsockelsystemen oder leistungsfähige Recheneinheiten des Kerns selbst, sind deutlich wichtiger als Unmengen an Cache.
Gregor schrieb:
Was den K10 betrifft: Wenn man sich mal anguckt, wie groß das Die von dem ist, dann muss er im Prinzip von seiner Rechenleistung her mindestens 2,5 mal so viel wie der Brisbane liefern.
Ich kenne die Die Grössen ehrlich gesagt nicht, aber alleine die Verdopplung der Kerne bringt theoretisch doppelte Leistung. Aber so einfach kann man das natürlich nicht rechnen. Hinzu kommt, dass der K10 zB einen shared Cache (L3) spendiert bekommen hat. Das vergrössert natürlich auch nochmal die Die Fläche.
Gregor schrieb:
...wenn man von einer deutlichen Verbesserung der Logik auf dem Chip ausgeht, müsste sogar noch mehr drin sein. Ich weiß nicht, ob die ersten Tests des Barcelonas auf ein solches Leistungspotential hindeuten. Naja, aber warten wir mal ab, was die Desktopvariante von diesem Prozessor bringt.
Wie gesagt, nicht jedes zusätzliche Element resultiert in linearem Leistungszuwachs. Und erst recht nicht in allen Szenarien. Du machst da natürlich eine ziemliche Milchmädchenrechnung. ZB wurden neue Stromsparmechanismen integriert, ua CoolCore. Einen Leistungszuwachs wirst du davon natürlich nicht bekommen. Oder die Virtualisierungstechnik wurde aufgebohrt. Davon wirst du auch nur dann profitieren, wenn eine Anwendung diese nutzt. Ich habe mir vom Barca bisher zwar nur speccpu angeschaut, was für Server Workloads wichtig ist, und da macht AMD's Neuer eine gute Figur. Im specfp putzt die 2 GHz Version selbst einen 3 GHz Xeon weg. Nicht so schlecht, wenn du mich fragst.
hustbaer schrieb:
Ich hab' mal ne ganz doofe Frage zu IMC + "Hypertransport" (ok, mehrere): ist damit gemeint dass jede CPU ihren "eigenen" Speicher hat, und wenn CPU 1 was aus dem Speicher von CPU 2 will, CPU 1 das über "Hypertransport" an CPU 2 signalisiert, CPU 2 fetcht das dann und schickt es über "Hypertransport" an CPU 1 rüber...? Und dauert das dann nicht (deutlich) länger als wenn man nen FSB verwendet?
Jede CPU hat ihren eigenen Controller, wenn du das meinst. Bei Mehrsockelsystemen können die verschiedenen CPUs also effektiver RAM beanspruchen. Niemand muss warten, bis ein externer Controller für die eigenen Anforderungen "frei" ist. Und nein, das dauert nicht länger als mit FSB. Ganz im Gegenteil, entscheidend ist Bandbreite und Latenz. Und die sind bei Hypertransport und einem IMC wesentlich besser.
hustbaer schrieb:
Und wenn diese meine Vermutung stimmt, sprechen wir dann hier nicht von einem NUMA System?
Deine Vermutung stimmt nicht und bei AMD sprechen wir von NUMA Systemen.
hustbaer schrieb:
Und... kann z.B. ein Windows Server 2003 das über die MMU oder sonstwie so hinbiegen dass es automatisch erkennt welcher Thread welchen Speicher verwendet, und diesen dann entsprechend "umschaufelt", damit er lokal zur CPU liegt? Bzw. wenigstens erkennen welchen Speicher der Thread vorzugsweise verwendet und ihn dementsprechend auf der "passenden" CPU schedulen?
Ich bin mir nicht sicher, was du hier genau meinst. Welcher Speicher (RAM) zu welchem Thread gehört, ist ja immer noch die Aufgabe des OS. Dem Speichercontroller ist das ziemlich egal. Der Speichercontroller greift davon unabhängig auf den gesamten Speicher zu und verteilt ihn auf den Kern, der ihn anfordert.
hustbaer schrieb:
Und nochwas anderes: wie funktioniert "Hypertransport" - ist das ein Bus System wo einfach alle CPUs draufhocken?
Grob gesagt, Hypertransport ist das, was für Intel der FSB ist. Wie es genau funktioniert, da lies dir am besten mal Wikipedia oder noch besser die Doku von AMD durch. Dort wird es sicherlich besser erklärt, als ich das könnte.
