Yonah Dual Core
- Ersteller Desti
- Erstellt am
http://news.com.com/Intel+spills+be...ok+chip/2100-1006_3-5729925.html?tag=nefd.top
For one thing, it will contain two cores, instead of the single core on current notebook chips. The two separate cores will also share a 2MB cache. Current dual-core desktop chips from Advanced Micro Devices and Intel come with similar sized caches, but each core accesses only 1MB of cache memory dedicated to it. Sharing the cache will significantly boost performance. (The chips communicate with the cache through a single bus embedded in the chip.)
"When I speak of dual cores, I am not talking about a 10 percent to 20 percent improvement in performance. I am speaking about something crazy," Eden said.
Yonah will also contain more transistors--151.6 million--than the current Pentium M, which has about 140 million transistors. Still, because it will be produced on the more advanced 65-nanometer process, Yonah will be smaller and therefore cost less to produce. "The margins will be great because it is a tiny product," Eden stated.
For one thing, it will contain two cores, instead of the single core on current notebook chips. The two separate cores will also share a 2MB cache. Current dual-core desktop chips from Advanced Micro Devices and Intel come with similar sized caches, but each core accesses only 1MB of cache memory dedicated to it. Sharing the cache will significantly boost performance. (The chips communicate with the cache through a single bus embedded in the chip.)
"When I speak of dual cores, I am not talking about a 10 percent to 20 percent improvement in performance. I am speaking about something crazy," Eden said.
Yonah will also contain more transistors--151.6 million--than the current Pentium M, which has about 140 million transistors. Still, because it will be produced on the more advanced 65-nanometer process, Yonah will be smaller and therefore cost less to produce. "The margins will be great because it is a tiny product," Eden stated.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Die Caches werden mehr und mehr zum Schlachtfeld.
Während ein kleiner Cache schnelle Zugriffszeiten in Punkto Latenz verspricht - mag er für gewisse Programme doch zu klein sein (siehe Northwood/Gallatin 512KB L2 Cache, kleine Latenzen, schnellster offiziell verkaufter Vertreter: P4 EE mit 3,73MHZ)
Möchte man nun einen z. B. einen 2MB großen Cache mit genau denselben Latenzen muss der Takt runter, da die Laufzeiten sonst zu Lang werden (beim oc'en eines Dothans wird das zumeist die Barriere sein, schnellster offiziell verkaufter Vertreter:2,13MHZ)
Nun habe ich mal gelesen(Quelle weiß ich nicht mehr), das ein Dual-Ported L2-Cache auch ca. die doppelte Anzahl an Transistoren braucht. Damit werden aber auch die Laufzeiten größer.
Das wichtigste Designziel wird also sein einen shared L2 Cache mit möglichst geringen Latenzen bei möglichst hohem Takt zu erreichen. Deshalb wurde der Cache in Sachen KB's auch nicht grösser.
"I believe we were designing it before anyone knew how to spell dual core"
Ich bohr mir ein Loch ins Knie. Hammer und Banias wurden fast Zeitgleich entwickelt.
Während die c't den Centrino wegen den abschaltbaren Cache-Zellen feierte hatten die AMD-Entwickler gerade die SRQ fertiggestellt.
"One thing Yonah won't have, at least initially, is the ability to run 64-bit applications. We made a conscious decision not to include it because of the impact on battery life, Eden said."
Laut Inquirer verzögert sich der Yonah nochmals etwas.
Longhorn-32-bit wird wenig marktrelevanz haben - ich tippe auch auf einen sehr schlechten Treibersupport - die Zeit reicht nicht mehr um 64bit zu integrieren.
Grüße,
Tom
Während ein kleiner Cache schnelle Zugriffszeiten in Punkto Latenz verspricht - mag er für gewisse Programme doch zu klein sein (siehe Northwood/Gallatin 512KB L2 Cache, kleine Latenzen, schnellster offiziell verkaufter Vertreter: P4 EE mit 3,73MHZ)
Möchte man nun einen z. B. einen 2MB großen Cache mit genau denselben Latenzen muss der Takt runter, da die Laufzeiten sonst zu Lang werden (beim oc'en eines Dothans wird das zumeist die Barriere sein, schnellster offiziell verkaufter Vertreter:2,13MHZ)
Nun habe ich mal gelesen(Quelle weiß ich nicht mehr), das ein Dual-Ported L2-Cache auch ca. die doppelte Anzahl an Transistoren braucht. Damit werden aber auch die Laufzeiten größer.
Das wichtigste Designziel wird also sein einen shared L2 Cache mit möglichst geringen Latenzen bei möglichst hohem Takt zu erreichen. Deshalb wurde der Cache in Sachen KB's auch nicht grösser.
"I believe we were designing it before anyone knew how to spell dual core"
Ich bohr mir ein Loch ins Knie. Hammer und Banias wurden fast Zeitgleich entwickelt.Während die c't den Centrino wegen den abschaltbaren Cache-Zellen feierte hatten die AMD-Entwickler gerade die SRQ fertiggestellt.
"One thing Yonah won't have, at least initially, is the ability to run 64-bit applications. We made a conscious decision not to include it because of the impact on battery life, Eden said."
Laut Inquirer verzögert sich der Yonah nochmals etwas.
Longhorn-32-bit wird wenig marktrelevanz haben - ich tippe auch auf einen sehr schlechten Treibersupport - die Zeit reicht nicht mehr um 64bit zu integrieren.
Grüße,
Tom
rkinet
Grand Admiral Special
Nun, Intel binded den L2 schon in P-III Zeiten mit 256 Bit an den L1/ CPU-Core an.mocad_tom schrieb:
Natürlich erhöht sich durch zwei zugreifende Cores die Latenzzeit. Allerdings nutzt ein Core heute nicht komplett die verfügbare 256 Bit Bandbreite aus, sodaß eigentlich genügend Luft für zwei Cores bleibt.
Zunächst überraschend, daß Intel im Vergleich zum Dothan wieder relativ wenig Cachefläche auf dem DIE vorsieht. Irgendwie erscheint der Yonah eher ein Verwandter des Banias, als des Dothan, welcher durch pure L2-Größe den ursprünglich schlappen FSB400 kompensieren sollte. Bei FSB667 dürften aber rießige L2 kaum mehr nötig sein.
Zu 64 Bit und Yonah:
Damals war x86-64 ja nur ein AMD64 und Intel-Netburst Geheimprojekt.
Die Entwickler hätten nur einen Itanium-M als Alternative bauen können, wenig erfolgversprechend.
Tippe mal, daß der Yonah ursprünglich auch als 'Beginner'-Design für 65nm gedacht war, damit Intel die Fertigung mit einem einfachen Design einfahren kann. Intel dürfte sowohl einen Core bei Bedarf deaktivieren, als auch den L2 noch reduzieren können. Auch bei miesen Yields könnte man also immer noch 1Mo. 2M-L2 Single-Cores verkaufen und am mobilen Massenmarkt plazieren.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Der Bus kann noch so breit sein. Wenn beide Cores gleichzeitig Daten vom L2-Cache wollen müssen auch beide gleichzeitig beliefert werden.
Schon mal den Die angeschaut:
http://www.computerbase.de/news/hardware/prozessoren/intel/2005/juni/yonah_smart_cache_sockel_478/
Das Rechteck in der Mitte ist für diese Aufgabe zuständig.
http://www.golem.de/0506/38413-2.html
"Im Gespräch mit Golem.de grinste Mooly Eden dann auch nur breit, als er gefragt wurde, wie viele Transistoren die Cache-Verwaltung benötigt: "Eine Menge!" war die diplomatische Antwort. Grob geschätzt dürften Cache- und Bus-Controller rund 15 Millionen Transistoren ausmachen - in etwa so viele, wie Intels Pentium II 1997 insgesamt benötigte. Eden verriet aber, dass der gesamte Yonah samt Cache aus 151,6 Millionen Transistoren besteht."
10% der Transistoren für den Cache/Bus-Controller
Ganz skeptisch gefragt - wie lange sind die Signallaufzeiten - daraus resultierend -> wie hoch die Taktreserven. Ein Segmentieren des Cachecontrollers in mehrere Stages erhöht wieder die Latenzen.
Es wird seine Gründe haben wieso man den Cache nicht vergrössert hat - wieso er plötzlich wieder so kompakt aussieht, und nicht so lang gezogen wie beim Dothan - die Latenzen durften im vergleich zum Dothan nicht steigen, sonst wäre die pro-Takt-Leistung(pro Kern) wieder nach unten.
Grüße,
Tom
Schon mal den Die angeschaut:
http://www.computerbase.de/news/hardware/prozessoren/intel/2005/juni/yonah_smart_cache_sockel_478/
Das Rechteck in der Mitte ist für diese Aufgabe zuständig.
http://www.golem.de/0506/38413-2.html
"Im Gespräch mit Golem.de grinste Mooly Eden dann auch nur breit, als er gefragt wurde, wie viele Transistoren die Cache-Verwaltung benötigt: "Eine Menge!" war die diplomatische Antwort. Grob geschätzt dürften Cache- und Bus-Controller rund 15 Millionen Transistoren ausmachen - in etwa so viele, wie Intels Pentium II 1997 insgesamt benötigte. Eden verriet aber, dass der gesamte Yonah samt Cache aus 151,6 Millionen Transistoren besteht."
10% der Transistoren für den Cache/Bus-Controller
Ganz skeptisch gefragt - wie lange sind die Signallaufzeiten - daraus resultierend -> wie hoch die Taktreserven. Ein Segmentieren des Cachecontrollers in mehrere Stages erhöht wieder die Latenzen.
Es wird seine Gründe haben wieso man den Cache nicht vergrössert hat - wieso er plötzlich wieder so kompakt aussieht, und nicht so lang gezogen wie beim Dothan - die Latenzen durften im vergleich zum Dothan nicht steigen, sonst wäre die pro-Takt-Leistung(pro Kern) wieder nach unten.
Grüße,
Tom
Dresdenboy
Redaktion
☆☆☆☆☆☆
Beim Cache-Design spielt auch eine Rolle, wieviel Wege er hat. Mehr Wege (höhere Assoziativität) bedeuten auch höhere Latenzen, wegen umfangreicherer Wege-Auswahl-Arbeit.
Aber etwas anderes:
Das der Arbiter so viel Transistoren wie ein ganzer Dothan-Kern haben soll, glaube ich nicht. Schon allein durch die Fläche u. ähnliche Struktur wie der Core läßt sich das nicht halten. Da hat Golem wohl etwas zu großzügig geschätzt
Andere Bemerkungen (von mir auf WO):
Ich denke, daß der L2 des Yonah nicht coreweise aufgeteilt wird wie bei HT, noch cacheline-weise (feinste Granularitätsstufe). Schließlich arbeiten ja beide Cores im gleichen Addressraum, und nur diesen gilt es zu cachen, unabh. davon, welche Cores was damit anstellen. Es wird wohl einfach ein großer L2 sein, welcher Anfragen von einem Arbiter bekommt und beantwortet. Den Rest macht dieser, auch die einzig auftretende Cache-Kohärenz-Geschichte im L1.
Nun füge ich nur noch ein Zitat Paul DeMones bezügl. der Yonah-Transistoren an:
Also könnte eine reduzierte L2-Cache-Assoziativität ein wesentlicher Grund für einen Großteil der entfernten Transistoren sein.
Eine reduzierte SRAM-Zellen-Transistor-Anzahl finde ich unwahrscheinlich. Auch hätten die Relationen nicht ganz gepasst: Die fast 19 Mio. Bit allein in den SRAM-Zellen ohne Tags und Logik benötigen ~ 113 Mio. T bei 6T/Zelle. 1T/Zelle weniger hieße etwa -19 Mio. T. Es wurden aber 11 Mio mehr. Das wären also 32 Mio, die woanders hinzugekommen wären und ein Kern hat etwa nur 15 Mio. Transistoren.
Aber etwas anderes:
Das der Arbiter so viel Transistoren wie ein ganzer Dothan-Kern haben soll, glaube ich nicht. Schon allein durch die Fläche u. ähnliche Struktur wie der Core läßt sich das nicht halten. Da hat Golem wohl etwas zu großzügig geschätzt
Andere Bemerkungen (von mir auf WO):
Ich denke, daß der L2 des Yonah nicht coreweise aufgeteilt wird wie bei HT, noch cacheline-weise (feinste Granularitätsstufe). Schließlich arbeiten ja beide Cores im gleichen Addressraum, und nur diesen gilt es zu cachen, unabh. davon, welche Cores was damit anstellen. Es wird wohl einfach ein großer L2 sein, welcher Anfragen von einem Arbiter bekommt und beantwortet. Den Rest macht dieser, auch die einzig auftretende Cache-Kohärenz-Geschichte im L1.
Nun füge ich nur noch ein Zitat Paul DeMones bezügl. der Yonah-Transistoren an:
(http://realworldtech.com/forums/ind...PostNum=3452&Thread=2&entryID=51339&roomID=11)
Also könnte eine reduzierte L2-Cache-Assoziativität ein wesentlicher Grund für einen Großteil der entfernten Transistoren sein.
Eine reduzierte SRAM-Zellen-Transistor-Anzahl finde ich unwahrscheinlich. Auch hätten die Relationen nicht ganz gepasst: Die fast 19 Mio. Bit allein in den SRAM-Zellen ohne Tags und Logik benötigen ~ 113 Mio. T bei 6T/Zelle. 1T/Zelle weniger hieße etwa -19 Mio. T. Es wurden aber 11 Mio mehr. Das wären also 32 Mio, die woanders hinzugekommen wären und ein Kern hat etwa nur 15 Mio. Transistoren.
rkinet
Grand Admiral Special
Meiner Schätzung nach dürfte der CPU-Core sich ca. 90% aller Instruktionen aus dem L1 holen können, bei Daten je nach Aufgabe ganz unterschiedlich.mocad_tom schrieb:
Die höhere Anzahl an Transitoren beim Arbiter könnte Intel per (partieller) Abschaltung bei Teillast gut kompensieren.
Dies dürfte bedeuten, daß ca. 70%-80% der CPU-Zeit der L2 von einem Core nicht benötigt wird. Beim gleichzeitigen Zugriff gibt es natürlich 'Behinderungen', aber der L2 kann durch das 256 Bit Design (wahrscheinlich schon vor Jahren bei Intel unter dem Aspekt HT und Dual-Core so designed) dann deutlicher schneller als vom Core benötigt neue Instruktionen liefern.
Auch beim 'gleichzeitigen' L2-Zugriff dürfte nach einer etwas verlängerten Latenzzeit genügend Transferkapazität zu den Cores (als 2* 256 Bit Leitungswege) vorliegen.
Bem: Beim K8 sieht man beim Vergleich 128k-256k-512k-1M L2, daß der Performanceanstieg nur mäßig ausfällt.
Die größeren L1 (2* 64k Instruktionen/ Daten) verstärken beim K8 diesen Effekt einer eher geringen Nutzung des L2 durch die üblichen Programme.
Würde AMD allerdings einen gemeinsamen L2 vorsehen, würden die 128 Bit (bzw. 2* 128 Bit) schon deutlicher einengen. AMD hat aber andere Möglichkeiten und eine 2* 1M Design in 65nm dürfte dem Yonah ebenbürdig sein durch die Vorteile des integrierten Speicherkontrollers und die eh geringen Effekte der L2-Vergrößerung beim (K7/)K8 mit seinen großen L1.
Ich halte daher den Yonah für gelungen, aber eben kein direktes Vorbild für AMD.
Einzig erkennbarer Nachteil beim Yonah ist die fehlende x64 Fähigkeit, die dem Merom vorbehalten bleibt.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Ich hab jetzt mal ein bisschen nachgemessen.
Aus dem Banias habe ich herausgemessen, das der L2-Cache etwa 40% der Die-Fläche einnimmt, also etwa 30,8Mio Transistoren - der Rest(Kern+L1-Cache) ca. 46,2Mio.
Aus dem Dothan habe ich herausgemessen, das der Kern etwa 57% der Die-Fläche einnimmt, also etwa 79Mio Transistoren - der Rest ca. 61Mio.
Wenn ich mit diesen Abschätzungen total falsch liege kann auch der Rest überlesen werden.
Die Differenz Dothan-Cache zu Banias-Cache scheint erklärbar.
Dothan-Cache = 2*Banias-Cache + zusätzlicher Verkabelung für gleiche Assoziativität
Aber die Differenz zwischen Dothan-Core 61Mio Tr. und Banias-Core 46,2 Mio Tr. scheint mir unerklärlich. Vielleicht verwendet man im Dothan auch andere Transistoren(ähnlich dem Turion) nur mit dem Unterschied, das durch redundante Transistroren der Verbrauch gesenkt wird.
Nun zum Yonah.
Das zentrale Rechteck(Cache-Controller) benötigt etwa 5,5% der Die-Fläche was in etwa 8,2Mio Transistoren sein müssten.
Ein Core+L1 benötigt etwa 24,2% der Die-Fläche also etwa 39MioTransistoren.
Der L2-Cache benötigt etwa 33% der Die-Fläche also etwa 52MioTransistoren.
Grüße,
Tom
Aus dem Banias habe ich herausgemessen, das der L2-Cache etwa 40% der Die-Fläche einnimmt, also etwa 30,8Mio Transistoren - der Rest(Kern+L1-Cache) ca. 46,2Mio.
Aus dem Dothan habe ich herausgemessen, das der Kern etwa 57% der Die-Fläche einnimmt, also etwa 79Mio Transistoren - der Rest ca. 61Mio.
Wenn ich mit diesen Abschätzungen total falsch liege kann auch der Rest überlesen werden.
Die Differenz Dothan-Cache zu Banias-Cache scheint erklärbar.
Dothan-Cache = 2*Banias-Cache + zusätzlicher Verkabelung für gleiche Assoziativität
Aber die Differenz zwischen Dothan-Core 61Mio Tr. und Banias-Core 46,2 Mio Tr. scheint mir unerklärlich. Vielleicht verwendet man im Dothan auch andere Transistoren(ähnlich dem Turion) nur mit dem Unterschied, das durch redundante Transistroren der Verbrauch gesenkt wird.
Nun zum Yonah.
Das zentrale Rechteck(Cache-Controller) benötigt etwa 5,5% der Die-Fläche was in etwa 8,2Mio Transistoren sein müssten.
Ein Core+L1 benötigt etwa 24,2% der Die-Fläche also etwa 39MioTransistoren.
Der L2-Cache benötigt etwa 33% der Die-Fläche also etwa 52MioTransistoren.
Grüße,
Tom
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Aus den Abmessungen bekommst du nur sehr grobe Abschätzungen bezüglich der Transistoranteil, im Normalfall sind z.B. Cacheflaächen dichter. Dort kannst du aber mit recht hoher Genauigkeit die Transistoranzahl berechnen (bislang kenne ich keine deutlichen Abweichungen): Man nehme pro Bit (also pro SRAM Zelle, bei DRAM gehts anders) 6 Transistoren, damit kommst du auf ca. 50 Mio Tr pro MB Cache. (DRAM normalerweise 1 Transistor und eine Kapazität pro Bit).
Dresdenboy
Redaktion
☆☆☆☆☆☆
Stimmt. Cache ist oft etwa 3-4mal dichter als der Logik-Teil (Kern). Bei der Errechnung der Transistorzahl für den Cache darf man die ECC-Bits u. auch Tags nicht vergessen. So kommt man auf etwa 55-60 Mio T/MB. Der Dothan Kern entspricht bis auf kleinere Neuerungen (z.B. im Bereich Prefetching) dem Banias-Kern u. sieht ihm deshalb auch noch sehr ähnlich. Geschätzte Transistorzahl (wie ich oben zitiert habe): 15 Mio.
Zusätzliche Transistoren können noch in zusätzlichen Repeatern u.ä. Anpassungen versteckt sein.
Zusätzliche Transistoren können noch in zusätzlichen Repeatern u.ä. Anpassungen versteckt sein.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Ich wollte es nicht wahrhaben, das die Packungsdichte zwischen Cache und Core so stark variiert - deshalb hab ich den Beitrag von PaulDeMone falsch gedeutet.
Angenommen, die Cores(15MioTr, 24% DieSize) sind in etwa gleich dicht gepackt wie der Cache-Controller(5,5%DieSize), so kommt man auf ca: 3,4Mio Transistoren.
Nach dem dritten Anlauf - aber die Zahl hört sich vielversprechend an.
In jedem Fall würden mich die Latenzen des L2-Caches interessieren.
Und eine Messung wie sie bereits bei Anandtech stattgefunden hat:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2419&p=3
Grüße,
Tom
Angenommen, die Cores(15MioTr, 24% DieSize) sind in etwa gleich dicht gepackt wie der Cache-Controller(5,5%DieSize), so kommt man auf ca: 3,4Mio Transistoren.
Nach dem dritten Anlauf - aber die Zahl hört sich vielversprechend an.
In jedem Fall würden mich die Latenzen des L2-Caches interessieren.
Und eine Messung wie sie bereits bei Anandtech stattgefunden hat:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2419&p=3
Grüße,
Tom
Dresdenboy
Redaktion
☆☆☆☆☆☆
Der Artikel ist interessant und nutzt einen kleinen netten Test von Michael S aus dem Aceshardware-Forum. Bei dem shared cache sollte die resultierende Zeit wirklich klein ausfallen.mocad_tom schrieb:
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Ich hab dich da schon mitdiskutieren sehen. 
Die Ergebnisse waren dann doch etwas desillusionierend.
Der Athlon X2 muss ca. 200 Takte warten, bis das Ergebnis vom einen Thread zum nächsten Übertragen wird.
Beim Gallatin sieht man was für geniale Cache-Anbindungen dieser Prozessor doch hat.
Der Yonah wird sich wohl zwischen dem P4-HT-System und dem X2 einordnen.
Grüße,
Tom
Die Ergebnisse waren dann doch etwas desillusionierend.
Der Athlon X2 muss ca. 200 Takte warten, bis das Ergebnis vom einen Thread zum nächsten Übertragen wird.
Beim Gallatin sieht man was für geniale Cache-Anbindungen dieser Prozessor doch hat.
Der Yonah wird sich wohl zwischen dem P4-HT-System und dem X2 einordnen.
Grüße,
Tom
Aber jetzt mal abgesehen davon, daß dieser unified cache sicher der Performance nicht abträglich sein wird - liegt die Hauptbremse nicht weiterhin im FSB? Klar, Yonah bekommt statt 533 dann 800, der Nachfolger dann 1066, aber reicht das (bzw. wird das nciht zu problematisch)? Daß ein integrierter Speichercontroller viel reißen kann, hat man bei AMD gesehen, Intel könnte sowas doch auch locker einbauen und damit die Performancespitze sofort wieder übernehmen. Müßte Intel sich nicht eher überlegen, daran zu feilen?
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Beim Yonah fällt zumindest schon mal die Last für die Cache Kohärenz am FSB weg.
Zum MemController - schau dir mal den Thread und besonders den letzten Beitrag an:
http://www.planet3dnow.de/vbulletin/showthread.php?t=148049&page=4
Grüße,
Tom
Zum MemController - schau dir mal den Thread und besonders den letzten Beitrag an:
http://www.planet3dnow.de/vbulletin/showthread.php?t=148049&page=4
Grüße,
Tom
Dresdenboy
Redaktion
☆☆☆☆☆☆
@mocad_tom:
Beim Yonah könnte diese Thread-Ping-Pong-Zeit sogar noch kürzer ausfallen, da schon die Vorgänger recht gute L2-Latenzen haben, was sich in ns gemessen günstig auswirken kann.
@OBrian:
Intel muß laut CPU-Positionierung derzeit noch nicht an irgendwelchen Performance-Tunings feilen, sonst hätten sie auch den 64bit-Modus integriert (was aber auch länger gedauert hätte). Für Yonah gelten die gleichen Gesetze wie für Turion, nicht wie für den AFX
Beim Yonah könnte diese Thread-Ping-Pong-Zeit sogar noch kürzer ausfallen, da schon die Vorgänger recht gute L2-Latenzen haben, was sich in ns gemessen günstig auswirken kann.
@OBrian:
Intel muß laut CPU-Positionierung derzeit noch nicht an irgendwelchen Performance-Tunings feilen, sonst hätten sie auch den 64bit-Modus integriert (was aber auch länger gedauert hätte). Für Yonah gelten die gleichen Gesetze wie für Turion, nicht wie für den AFX
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
20 ns wären bei 2Ghz 40 Takte.
Es wird wohl drauf ankommen, ob die Daten im L1-Cache-CPU0 liegen - diese in den L2 Cache zurück müssen und dann weiter in den L1-Cache-CPU1.
Ganz blöd gefragt, wieso braucht HyperThreading keinen Smart-Cache.
Grüße,
Tom
Es wird wohl drauf ankommen, ob die Daten im L1-Cache-CPU0 liegen - diese in den L2 Cache zurück müssen und dann weiter in den L1-Cache-CPU1.
Ganz blöd gefragt, wieso braucht HyperThreading keinen Smart-Cache.
Grüße,
Tom
Dresdenboy
Redaktion
☆☆☆☆☆☆
Intel benutzt ein inklusives Cache-Design. Was im L1 steht, steht auch im L2. Da muß also nichts extra kopiert werden.mocad_tom schrieb:
Der "smarte" Anteil am Smart-Cache ist wohl weniger im Cache, als im Controller zu suchen. Es geht da eher darum, wie die Zugriffe usw. geregelt werden. Schließlich greifen ja 2 Threads zu, die einen vollständigen Satz an Ressourcen (Recheneinheiten, Register, L1 Caches usw.) ihr Eigen nennen, und nicht, wie bei HT, sich gegenseitig schon diese Ressourcen nehmen, wozu dann auch der L2 zählt.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
@ddb
>Andere Bemerkungen (von mir auf WO):
>Ich denke, daß der L2 des Yonah nicht coreweise aufgeteilt wird wie bei HT, noch
>cacheline-weise (feinste Granularitätsstufe). Schließlich arbeiten ja beide Cores im
>gleichen Addressraum, und nur diesen gilt es zu cachen, unabh. davon, welche Cores
>was damit anstellen. Es wird wohl einfach ein großer L2 sein, welcher Anfragen von
>einem Arbiter bekommt und beantwortet. Den Rest macht dieser, auch die einzig
>auftretende Cache-Kohärenz-Geschichte im L1.
Es müssten aber trotzdem zwei Tabellen für die LRU-Verwaltung geführt.
Angenommen man hat einen speicherintensiven Thread, und einen Thread, der mit sehr wenigen Cache-Zugriffen auskommt, auf diese aber angewiesen ist.
Zum Beispiel ist es bei der XBox2-CPU so gelöst, das man Cache-Bereiche in einen Local-Storage ummünzen kann:
http://www.planet3dnow.de/vbulletin/showthread.php?p=2257285#post2257285
http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars/5
Grüße,
Tom
>Andere Bemerkungen (von mir auf WO):
>Ich denke, daß der L2 des Yonah nicht coreweise aufgeteilt wird wie bei HT, noch
>cacheline-weise (feinste Granularitätsstufe). Schließlich arbeiten ja beide Cores im
>gleichen Addressraum, und nur diesen gilt es zu cachen, unabh. davon, welche Cores
>was damit anstellen. Es wird wohl einfach ein großer L2 sein, welcher Anfragen von
>einem Arbiter bekommt und beantwortet. Den Rest macht dieser, auch die einzig
>auftretende Cache-Kohärenz-Geschichte im L1.
Es müssten aber trotzdem zwei Tabellen für die LRU-Verwaltung geführt.
Angenommen man hat einen speicherintensiven Thread, und einen Thread, der mit sehr wenigen Cache-Zugriffen auskommt, auf diese aber angewiesen ist.
Zum Beispiel ist es bei der XBox2-CPU so gelöst, das man Cache-Bereiche in einen Local-Storage ummünzen kann:
http://www.planet3dnow.de/vbulletin/showthread.php?p=2257285#post2257285
http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars/5
Grüße,
Tom
Dresdenboy
Redaktion
☆☆☆☆☆☆
Da fehlen noch entspr. Informationen von Intel. Aber man kann im Arbiter schon einige SRAM-Arrays erkennen. Diese könnten durchaus eine entspr. Funktion aufweisen. Auch ein zusätzliches Bit im Tag-RAM für den die Cacheline zuletzt genutzt habenden Cores könnte in solchen Fällen unterstützen. Was es letztendlich ist, werden wir wohl erst auf einem weiteren IDF oder dem Fall Processor Forum erfahren. Danach wirds bald zu spätmocad_tom schrieb:
rkinet
Grand Admiral Special
rkinet
Grand Admiral Special
http://www.the-inquirer.net/?article=24746
auch: http://www.heise.de/newsticker/meldung/61864
CEO, Paul Otellini.
The firm will start producing 65 nanometre processors during the second half of this year, he said. .
Intels Einstieg in echte Dual-Core per Yonah scheinen als im Zeitplan zu liegen.
Im Prinzip ist der Yonah technisch kein großer Gegner, aber eben preislich.
Hier sind X2 3800+ und weitere Preisrücknahmen beim X2 eine wichtige Aufgabe.
auch: http://www.heise.de/newsticker/meldung/61864
CEO, Paul Otellini.
The firm will start producing 65 nanometre processors during the second half of this year, he said. .
Intels Einstieg in echte Dual-Core per Yonah scheinen als im Zeitplan zu liegen.
Im Prinzip ist der Yonah technisch kein großer Gegner, aber eben preislich.
Hier sind X2 3800+ und weitere Preisrücknahmen beim X2 eine wichtige Aufgabe.
Zuletzt bearbeitet:
LinuS
Vice Admiral Special
Ich glaub ein Dualcore Turion wär erstmal wichtiger 
rkinet
Grand Admiral Special
Da ist unter SOI-90nm aber nicht viel Takt zu erwarten.LinuS schrieb:
Der X2 benötigt deutlich mehr Strom bei gleichem Takt, sodaß ein 35 Watt Turion 64 vielleicht gerade mal 2* 1,4 - 1,6 GHz packen könnte (SC ca. 2,0 bis 2,2 GHz bei 35 Watt).
Das erscheint mir zuwenig, um damit einen großen Mobilmarkt zu erobern.
Hier wird AMD eher auf 65nm Produkte setzen.
LinuS
Vice Admiral Special
Jedoch ist der X2 keine Konkurrenz für den Yonah, da der Yonah (erstmal) für den Mobilmarkt gedacht ist. Der X2 beliefert da eine ganz andere Zielgruppe, von der daher fand ich den Verweis auf den X2 etwas unpassend.
rkinet
Grand Admiral Special
a) Es gibt schon Studien für den Yonah-Desktop: http://www.hkepc.com/bbs/viewthread.php?tid=428824LinuS schrieb:
Hier müßte sich AMD Gedanken um eine 35-45 Watt Selektion des X2 machen, sonst kann Intel hier einen lukrativen Markt für sich (und Apple ?!) öffnen.
b) Ein Yonah auf Vollast wird kräftig an der Notebook-Batterie saugen. Der zweite Core wird die Domäne im Netzbetrieb sein und der Yonah kann ja den zweiten Core deaktivieren und den ganzen L2 dem ersten Core zur Verfügung stellen.
c) Mit FSB667 statt 400 oder 533 wir er ehe die bisher genügsame Dothan Region (FSB400 ist am genügsamsten) verlassen und sich meht in Richtung 35 Watt TDP entwickeln.
d) Der X2 ist für beide Anwendungsgebiete geeignet. Zunächst sicherlich aber eher als DTP-Selektion der 60 Watt TDP Klasse. Im Prinzip auch als langsame (2* 1,4 bis 1,6 GHz) Selektion in der 35 Watt-Klasse machbar, wobei hier aber Turion, Dothan und Yonah besser (=geringerer Watt-Bedarf) bei Teillast sein dürften.
Fazit: Die Zeilgruppen unterscheiden sich, aber es gibt in Randbereichen Überschneidungen und es treffen eben zwei 'echte' Dual-Core erstmals aufeinander.
Ähnliche Themen
