Dual-Core K8Hammer; Wie?
- Ersteller Bokill
- Erstellt am
Dual-Core K8Hammer; Wie?
Dual core K8Hammer; How?
Da ich keinerlei Infos zum K9 habe, aber doch diffuse Marketingdesinformation von AMD verbreitet wurden, dass der K9 doch wohl recht zügig erscheinen könnte...
Ich frage frage mich wie so etwas aussehen könnte?
1. Zwei nackte Kerne, beide teilen L1- und L2- Cache?
2. Zwei Kerne jedoch mit individuellen L1 Cache aber gemeinsamen L2 Cache?
3. Zwei komplett identische K8s lediglich verbunden über die SRQ?
4. Mischform von 1. und 2. Gemeinsamer Instruktionencache aber getrennter Datencache (Oder auch umgekehrt)?
Bild zur SRQ
Lage des SRQ
Bild zur Hammer K8 Architektur
1. AMD Presseinfo Kern
dort ist die SRQ im Kern drin aber nicht der Hypertransport(HTr)/Speichercontroller... auch die Caches liegen ausserhalb
Im PDF Hammer_architecture_WP_2.pdf auf Seite 3 ist`s genauer abgebildet
Funktionsblöcke des K8 im Detail.
Funktionsblöcke K8
Irgend etwas sagt mir, dass Nr. 3 die wahrscheinlichste Lösung ist (aber auch die teuerste).
Liege ich da falsch?
Was spricht dafür (Nr.3)
Was dagegen?
Welche Vorteile haben die anderen Lösungen?
Welche Nachteile haben sie?
Wie intel SMP Systeme macht kann in der folgenden Heisemeldung nachgelesen werden. IBM hat da eine externe Lösung entwickelt um mehrere Prozesoren (entweder Xeons, aber auch jeweils Itanium) auf einem Mainboard unterzubringen. IBM: Achtfach-Server mit preiswerten DP-Xeons Das SMP Expansion Modul -> Summit <-ist die entscheidende Schnittstelle zur Erweiterung (IBM Entwicklung)
Update:
IBM hat den X3 Chipsatz-Architektur für Xeons herausgebracht. Siehe auch den Artikel x86 Servers Brace for a Hurricane von realworldtech.com
Intel hat aber auch Chipsätze entwickelt, die SMP in die Welt des Xeons und Itaniums bringen soll. Der intel 870 (jetzt Intel E8870 genannt) -> Details zu Xeon- und Itanium-Chipsätzen von IBM und Intel
E8870 Chipsatzaufbau (ehemals i870)
HP hat natürlich ebenso eine Itanium2 Chipsatzlösung herausgebracht, den HP zx1.
IBM Power 4 & Power 5
Und hier mal eine Darstellung des Power 4 von IBM. Der Power 5 unterscheidet sich nicht wesentlich vom Busaufbau und deren Funktionseinheiten des Power 4.
Von Heise aus der c`t mit dem Prozessorgeflüster 22/2000 Kontrastprogramm
Das Microprocessor Forum 2000
Dieser Thread ist meiner Meinung nach kein Nachfolgethread zum K9 Windhund . Vom K9 erwarte ich mir wirklich echte Neuerungen (SMT wäre dort eine von vielen Möglichkeiten).
Arbeitshilfen:
Seitenverzeichnis
ie Opteron Zukunft, kann AMD überleben?
P3D Artikel: Doping für CPUs - Möglichkeiten der Leistungssteigerung von D'Espice
P3D Benchübersicht bei 2 GHz und unterschiedlichen K7/K8 Kernen (Artikel: AMD Athlon 64 4000+ von Tenshi/Nero24)
Ausgangsseiten der Thread- Idee
1. Seite 5 vom Opteronthread
2. HT oder HT+ beim Athlon64 möglich? Auf 3DCenter
Dual core K8Hammer; How?
Da ich keinerlei Infos zum K9 habe, aber doch diffuse Marketingdesinformation von AMD verbreitet wurden, dass der K9 doch wohl recht zügig erscheinen könnte...
Ich frage frage mich wie so etwas aussehen könnte?
1. Zwei nackte Kerne, beide teilen L1- und L2- Cache?
2. Zwei Kerne jedoch mit individuellen L1 Cache aber gemeinsamen L2 Cache?
3. Zwei komplett identische K8s lediglich verbunden über die SRQ?
4. Mischform von 1. und 2. Gemeinsamer Instruktionencache aber getrennter Datencache (Oder auch umgekehrt)?
Bild zur SRQ
Lage des SRQ
Bild zur Hammer K8 Architektur
1. AMD Presseinfo Kern
dort ist die SRQ im Kern drin aber nicht der Hypertransport(HTr)/Speichercontroller... auch die Caches liegen ausserhalb
Im PDF Hammer_architecture_WP_2.pdf auf Seite 3 ist`s genauer abgebildet
Funktionsblöcke des K8 im Detail.
Funktionsblöcke K8
Irgend etwas sagt mir, dass Nr. 3 die wahrscheinlichste Lösung ist (aber auch die teuerste).
Liege ich da falsch?
Was spricht dafür (Nr.3)
Was dagegen?
Welche Vorteile haben die anderen Lösungen?
Welche Nachteile haben sie?
Wie intel SMP Systeme macht kann in der folgenden Heisemeldung nachgelesen werden. IBM hat da eine externe Lösung entwickelt um mehrere Prozesoren (entweder Xeons, aber auch jeweils Itanium) auf einem Mainboard unterzubringen. IBM: Achtfach-Server mit preiswerten DP-Xeons Das SMP Expansion Modul -> Summit <-ist die entscheidende Schnittstelle zur Erweiterung (IBM Entwicklung)
Update:
IBM hat den X3 Chipsatz-Architektur für Xeons herausgebracht. Siehe auch den Artikel x86 Servers Brace for a Hurricane von realworldtech.com
Intel hat aber auch Chipsätze entwickelt, die SMP in die Welt des Xeons und Itaniums bringen soll. Der intel 870 (jetzt Intel E8870 genannt) -> Details zu Xeon- und Itanium-Chipsätzen von IBM und Intel
E8870 Chipsatzaufbau (ehemals i870)
HP hat natürlich ebenso eine Itanium2 Chipsatzlösung herausgebracht, den HP zx1.
IBM Power 4 & Power 5
Und hier mal eine Darstellung des Power 4 von IBM. Der Power 5 unterscheidet sich nicht wesentlich vom Busaufbau und deren Funktionseinheiten des Power 4.
Von Heise aus der c`t mit dem Prozessorgeflüster 22/2000 Kontrastprogramm
Das Microprocessor Forum 2000
Dieser Thread ist meiner Meinung nach kein Nachfolgethread zum K9 Windhund . Vom K9 erwarte ich mir wirklich echte Neuerungen (SMT wäre dort eine von vielen Möglichkeiten).
Arbeitshilfen:
Seitenverzeichnis
ie Opteron Zukunft, kann AMD überleben? P3D Artikel: Doping für CPUs - Möglichkeiten der Leistungssteigerung von D'Espice
P3D Benchübersicht bei 2 GHz und unterschiedlichen K7/K8 Kernen (Artikel: AMD Athlon 64 4000+ von Tenshi/Nero24)
Ausgangsseiten der Thread- Idee
1. Seite 5 vom Opteronthread
2. HT oder HT+ beim Athlon64 möglich? Auf 3DCenter
Zuletzt bearbeitet:
Slider
Admiral Special
- Mitglied seit
- 02.08.2003
- Beiträge
- 1.878
- Renomée
- 0
Einziges bisheriges Fakt ist: Unterstützung von TCPA (like Prescott).
Was auch noch drin sein wird: DDRII Controller oder vielleicht schon ein QBM RAM Controller *gg* ? Das härteste was ich als Gerücht gehört hab war das integrierte Peltierelement, was für eine vorstellung
.
Persönliche Meinung: Ist mir eigendlich Wurst ob es eine Dual-Core CPU wird oder nicht...
Die anderen Details (Transistoren, Kühlung, Socket, größe, Verbrauch, Takt,...) kannst du aus deiner Fantasi holen
(...und bitte meckert mich nicht wegen TCPA an, da es jetzt anders heísst und es bei Intel die >Sicherheitstechnologie< "La Grande" heisst - das weiss ich, DANKE! )
Was auch noch drin sein wird: DDRII Controller oder vielleicht schon ein QBM RAM Controller *gg* ? Das härteste was ich als Gerücht gehört hab war das integrierte Peltierelement, was für eine vorstellung
.Persönliche Meinung: Ist mir eigendlich Wurst ob es eine Dual-Core CPU wird oder nicht...
Die anderen Details (Transistoren, Kühlung, Socket, größe, Verbrauch, Takt,...) kannst du aus deiner Fantasi holen
(...und bitte meckert mich nicht wegen TCPA an, da es jetzt anders heísst und es bei Intel die >Sicherheitstechnologie< "La Grande" heisst - das weiss ich, DANKE! )
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Vom jetzigen Standpunkt aus wäre auch IMO 3. die Lösung für AMD. Denn der zweite CPU Port ist am SRQ schon vorhanden. und der L2 direkt mit dem Kern verbunden. Bei einem gemeinsamen L2 Cache für beide Cores müsste man erst einen entsprechend dimensionierten Port an die X-Bar dranbasteln (256 Bit) und diese entsprechend leistungsfähiger dimensionieren. (Heute liegt die Leistung bei ca 30 GB/s, ein 256 Bit Cache hat bei 2 GHz schon eine Spitzentransferrate von 64 GB/s). 2 getrennte Cores würden auch dafür sorgen, dass die Latenzen gering bleiben und wäre am einfachsten zu integrieren. Das Platzproblem dürfte beim angestrebten 65 nm Prozess auch nicht zum Tragen kommen und größere Caches als 1 MB sind IMO beim K8 dank integrierten Speichercontroller nicht notwendig.
Danke mtb][sledgehammer, aber dies wird dann doch ziemlich teuer sein?
Der 0,09µm Schritt bringt den Core wieder in günstige Dimensionen wenn der Prozess im Griff ist. Der Schritt auf 0,065µm wird zwar sinnvoll sein, aber dies wird frühestens in 2 Jahren sein!
Ich erwarte bis dahin aber eine ähnliche Entwicklung des K8 von AMD, wie es der Athlon schon hatte. Bessere Cacheanbindung, SSE was weiss ich, eventuell doppelte SSE Einheiten... jedenfalls fallen so noch einige zusätzliche Transitoren an...
Ein Problem sehe ich jedoch... die Pinfrage! Kann man erwarten dass diese Dual Hämmer, immer noch identische Sockel haben werden? Eigentlich ja... aber so tritt das Problem wie beim K7 auf.
Beim Dual K7 hatten die MP Athlonen eigene Verbindungen zur Northbridge (Eínzelverbindung, kein Bussystem! )... die Speicherbandbreite wurde da zum Flaschenhals... könnte beim Dual- Hammer auch so auftreten, nur auf höherem Niveau.
Der 0,09µm Schritt bringt den Core wieder in günstige Dimensionen wenn der Prozess im Griff ist. Der Schritt auf 0,065µm wird zwar sinnvoll sein, aber dies wird frühestens in 2 Jahren sein!
Ich erwarte bis dahin aber eine ähnliche Entwicklung des K8 von AMD, wie es der Athlon schon hatte. Bessere Cacheanbindung, SSE was weiss ich, eventuell doppelte SSE Einheiten... jedenfalls fallen so noch einige zusätzliche Transitoren an...
Ein Problem sehe ich jedoch... die Pinfrage! Kann man erwarten dass diese Dual Hämmer, immer noch identische Sockel haben werden? Eigentlich ja... aber so tritt das Problem wie beim K7 auf.
Beim Dual K7 hatten die MP Athlonen eigene Verbindungen zur Northbridge (Eínzelverbindung, kein Bussystem! )... die Speicherbandbreite wurde da zum Flaschenhals... könnte beim Dual- Hammer auch so auftreten, nur auf höherem Niveau.
mtb][sledgehammer
Grand Admiral Special
Wie verschwendrisch es ist, zwei getrennte Caches zu verbasteln, hängt wohl vom Programm ab. Arbeiten beide CPUs an völlig getrennten Prozessen, dann sind diese mit Sicherheit schneller. Problematisch kann das mit den zwei Caches eigentlich nur werden, wenn, beide im Grunde das gleiche ist, und somit immer in beiden Caches das selbe stehen muss. Wenn ich aber an heutige Dual Systeme denke, wo das zwangsläufig der Fall ist, und die Caches über einen lahmen FSB (OK beim Opteron ist es ein schneller HT Link "g") verbunden sind, dann denke ich dass das Ergebnis hier nicht gravierend ist.
IMO plant Intel bei seinen CPU Monstern auch nur den L3 Cache zu teilen ("nochmal such"), das würde diese Theorie unterstützen. Natürlich könnte der DualCore K8 durch die Speicherbandbreite eingeschränkt sein, allerdings erlaubt dieses CPU Konzpt doch eine wesentlich leichtere Skalierung der Speicherbandreite. So hat heute der Dual Opteron mit 12.8 GB/s die sechsfache Bandbreite wie ein Dual Athlon MP. Mit zukünfigen Speichertechnologien sehe ich darin kein Problem.
IMO plant Intel bei seinen CPU Monstern auch nur den L3 Cache zu teilen ("nochmal such"), das würde diese Theorie unterstützen. Natürlich könnte der DualCore K8 durch die Speicherbandbreite eingeschränkt sein, allerdings erlaubt dieses CPU Konzpt doch eine wesentlich leichtere Skalierung der Speicherbandreite. So hat heute der Dual Opteron mit 12.8 GB/s die sechsfache Bandbreite wie ein Dual Athlon MP. Mit zukünfigen Speichertechnologien sehe ich darin kein Problem.
aber wie kommt AMD dazu zu sagen, dass sie 20% mehr für einen Dual- Core brauchen?
Ist dies falsch zusammengeplappert worden?
Hat AMD selbst so etwas gar nicht gesagt?
Deswegen dieser Thread, sicher scheint mir hier wirklich gar nichts... und dies wo doch in letzter Zeit einiges frisches Material in das Forum flutete...
Stichworte SMP, SMT, CMS, CMP...
Auch in dem Artikelbereich über dem Hammer sind einige Sachen schon beschrieben worden.
MFG Bokill
Ist dies falsch zusammengeplappert worden?
Hat AMD selbst so etwas gar nicht gesagt?
Deswegen dieser Thread, sicher scheint mir hier wirklich gar nichts... und dies wo doch in letzter Zeit einiges frisches Material in das Forum flutete...
Stichworte SMP, SMT, CMS, CMP...
Auch in dem Artikelbereich über dem Hammer sind einige Sachen schon beschrieben worden.
MFG Bokill
Original geschrieben von Online-Slider
Einziges bisheriges Fakt ist: Unterstützung von TCPA (like Prescott).
Was auch noch drin sein wird: DDRII Controller oder vielleicht schon ein QBM RAM Controller *gg* ? Das härteste was ich als Gerücht gehört hab war das integrierte Peltierelement, was für eine vorstellung
Persönliche Meinung: Ist mir eigendlich Wurst ob es eine Dual-Core CPU wird oder nicht...
Die anderen Details (Transistoren, Kühlung, Socket, größe, Verbrauch, Takt,...) kannst du aus deiner Fantasi holen
(...und bitte meckert mich nicht wegen TCPA an, da es jetzt anders heísst und es bei Intel die >Sicherheitstechnologie< "La Grande" heisst - das weiss ich, DANKE! )
tut mir leid, aber ein WAS ?
das "q" könnt ich in das Wort "Quad" (intel lässt grüßen) eingliedern, aber "bm"
also, bevor sich jemand hier (nochmal) beschwert: ist natürlich alles spekulation. wer nicht mitmachen will, der braucht ja nicht...ich will!
also:
ich dachte ja immer, an der crossbar wäre die trennung, nicht am sqr (was immer es ist). käme aber lt. grafik auf das selbe raus: komplette zwei cpus, jede mit eigenem l1 & l2 cache
. 1.nachteil riesige die fläche selbst bei 90nm; mögliche lösung, l2 caches halbieren. 2.nachteil: daten könnten/werden doppelt im cache stehen, was nach einer halbierung noch unangenehmer wäre.
ein gemeinsamer l2-cache wäre daher schon am schönsten denke ich. nur frage ich mich da, wie es der eine l2-cache schaffen soll, beide cpus gleichzeitig schnell(!!!)zu bedienen? hm, wenn man doch zwei getrennte l2-caches nimmt und genauso macht wie bei den opterons, nämlich, daß die eine cpu erst in ihrem lokalem cache nach den daten sucht, dann im cache der nächsten cpu und erst dann im ram?
warum eigentlich überhaupt einen kompletten core mit ranschustern und eben nicht nur eine zusätzliche fpu- und z.b. zwei zusätzliche alu-einheiten?
also:
ich dachte ja immer, an der crossbar wäre die trennung, nicht am sqr (was immer es ist). käme aber lt. grafik auf das selbe raus: komplette zwei cpus, jede mit eigenem l1 & l2 cache
. 1.nachteil riesige die fläche selbst bei 90nm; mögliche lösung, l2 caches halbieren. 2.nachteil: daten könnten/werden doppelt im cache stehen, was nach einer halbierung noch unangenehmer wäre. ein gemeinsamer l2-cache wäre daher schon am schönsten denke ich. nur frage ich mich da, wie es der eine l2-cache schaffen soll, beide cpus gleichzeitig schnell(!!!)zu bedienen? hm, wenn man doch zwei getrennte l2-caches nimmt und genauso macht wie bei den opterons, nämlich, daß die eine cpu erst in ihrem lokalem cache nach den daten sucht, dann im cache der nächsten cpu und erst dann im ram?
warum eigentlich überhaupt einen kompletten core mit ranschustern und eben nicht nur eine zusätzliche fpu- und z.b. zwei zusätzliche alu-einheiten?
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@Bokill
> 1. Zwei nackte Kerne, beide teile L1 und L2- Cache
Nope. Das wäre totaler Blödsinn. Bottelneck: L1 Durchsatz/Latenz.
> 2. Zwei Kerne jedoch mit individuellen L1 Cache aber gemeinsamen L2 Cache.
Nope. Gründe: siehe mtb][sledgehammer's posting
> 4. Mischform von 1. und 2. Gemeinsamer Instruktionencache aber getrennter Datencache (Oder auch umgekehrt)
Nope. Probleme wie 1) und 2); zu spezifisch, zusätzlicher Engineering-Aufwand f. neue Cache Logik (Snooping!).
> 3. Zwei komplett identische K8s lediglich verbunden über die SRQ.
Jep. Thats the way to go.
> Kann man erwarten dass diese Dual Hämmer, immer noch identische Sockel haben werden?
Davon gehe ich zu 100% aus! Es gibt keinen Grund warum das nicht so sein sollte.
> die Speicherbandbreite wurde da zum Flaschenhals... könnte beim Dual- Hammer auch so auftreten, nur auf höherem Niveau.
100% Ack mit mbt. Das Dual-Channel Interface hat genug Bandbreite um zwei Cores zu versorgen: Das sieht man z.B. am K8-Master FAR Dual: Das Board hat nure eine Dual-Channel Memory Anbindung, aber die 2 CPUs skalieren gegenüber einem Singleprozessor System sehr gut.
> aber wie kommt AMD dazu zu sagen, dass sie 20% mehr für einen Dual- Core brauchen?
Jetziger K8: 1MB L2 ~42% Fläche, L1/FPU/ExecUnits/LSU/Microcode (CPU Core) ~26% Fläche, MC, BusUnit, HT & DDR IF ~32%
Dual-Core K8: 2x512k L2, 2xCPU Core, 1xMC/BU/HT/DDR => Fläche Relativ: 42 + 52 + 32 = 126
Die 20% die AMD angibt wurden wohl ausgehend vom neunen Flächenbedarf berechnet:
(D.h. 126 entspricht 100% => alter Core benötigt nur 100/126 * 100 = 79% Flächenbedarf im vergleich zu neuem Core => "rund" 20% mehr Fläche notwendig). NB: An AMD's stelle würde ich korrekter weise 26% mehr Fläche angeben, aber das ist eine Frage der Sichtweise.
@Online-Slider
> Einziges bisheriges Fakt ist: Unterstützung von TCPA (like Prescott).
Dazu gibts noch Anzumerken, dass heute schon jedes MB mit einem TPM bestückt werden könnte. Im übrigen ist noch gar nicht raus was LaGrande wirklich alles implementiert. Momentan sieht es noch so aus als würde man ein zusätzliches TPM benötigen.
Zum Thema QBM (Quad Band Memory, verwendet QDR als Übertragugsverfahren): Da wette ich drauf, dass AMD das garantiert nicht integriert! IMO ist QBM eine Totgeburt. Intel läßt die Finger davon und selbst VIA hat QBM von der Featureliste des PT880 gestrichen -- nur einen Monat nach dem man dies Angekündigt hatte!.
@mtb][sledgehammer
> Wie verschwendrisch es ist, zwei getrennte Caches zu verbasteln, hängt wohl vom Programm ab. Arbeiten beide CPUs an völlig getrennten Prozessen, dann sind diese mit Sicherheit schneller. Problematisch kann das mit den zwei Caches eigentlich nur werden, wenn, beide im Grunde das gleiche ist, und somit immer in beiden Caches das selbe stehen muss.
Der Normalfall ist das unterschiedliche Threads (Prozesse) auf unterschiedliche Daten zugreifen. Für den anderen Fall benötigt man sowieso Thread-Synchronisation-Mechanismen, die die Performance weit aus mehr beeinflussen, als eine kleinere effektive Cachegröße.
Wie klein der Unterschied i.d.R. ist sieht man ganz gut am A64 3000+ (macht wohl ca. 10% aus).
@Treverer
> daten könnten/werden doppelt im cache stehen, was nach einer halbierung noch unangenehmer wäre.
Effektiv macht sich nur die halbierung des Cache bemerkbar -- ob die Daten in ein oder zwei L2 Caches stehen, spielt keine Rolle*.
* Es gibt natürlich die Abhängigkeit vom MOESI Protokoll, aber das ist nur relevant wenn man mit einem Single-CPU System vergleicht. Vergleicht man ein Dual-Core mit einem herkömlichen Dual-CPU System gibt es keinen zusätzliches Performance Penalty!
> wenn man doch zwei getrennte l2-caches nimmt und genauso macht wie bei den opterons, nämlich, daß die eine cpu erst in ihrem lokalem cache nach den daten sucht, dann im cache der nächsten cpu und erst dann im ram?
Das ist durch das MOESI Cach-Koherenzprotokoll auf alle Fälle gewährleistet. Vorteil einer on die Lösung: Das Cache Snooping ist viel schneller; es fällt die HT Latenz weg.
> warum eigentlich überhaupt einen kompletten core mit ranschustern und eben nicht nur eine zusätzliche fpu- und z.b. zwei zusätzliche alu-einheiten?
1) Mehr Funktionseinheiten -> Größere Scheduler-Komplexität
2) Erheblicher Engineering-Aufwand (U.a ein nicht kleines Verifikations-Nightmare)
3) Vorteile eines zweiten Core:
- Architecture/Engineering Reuse
- Parallele Verarbeitung von verschiedenen Prozessen (Unterschiedliche Virtual Memory Maps!)
- Einfacher für das OS/Programiermodell als logische und physikalische CPUs (SMT) zu unterscheiden.
> 1. Zwei nackte Kerne, beide teile L1 und L2- Cache
Nope. Das wäre totaler Blödsinn. Bottelneck: L1 Durchsatz/Latenz.
> 2. Zwei Kerne jedoch mit individuellen L1 Cache aber gemeinsamen L2 Cache.
Nope. Gründe: siehe mtb][sledgehammer's posting
> 4. Mischform von 1. und 2. Gemeinsamer Instruktionencache aber getrennter Datencache (Oder auch umgekehrt)
Nope. Probleme wie 1) und 2); zu spezifisch, zusätzlicher Engineering-Aufwand f. neue Cache Logik (Snooping!).
> 3. Zwei komplett identische K8s lediglich verbunden über die SRQ.
Jep. Thats the way to go.
> Kann man erwarten dass diese Dual Hämmer, immer noch identische Sockel haben werden?
Davon gehe ich zu 100% aus! Es gibt keinen Grund warum das nicht so sein sollte.
> die Speicherbandbreite wurde da zum Flaschenhals... könnte beim Dual- Hammer auch so auftreten, nur auf höherem Niveau.
100% Ack mit mbt. Das Dual-Channel Interface hat genug Bandbreite um zwei Cores zu versorgen: Das sieht man z.B. am K8-Master FAR Dual: Das Board hat nure eine Dual-Channel Memory Anbindung, aber die 2 CPUs skalieren gegenüber einem Singleprozessor System sehr gut.
> aber wie kommt AMD dazu zu sagen, dass sie 20% mehr für einen Dual- Core brauchen?
Jetziger K8: 1MB L2 ~42% Fläche, L1/FPU/ExecUnits/LSU/Microcode (CPU Core) ~26% Fläche, MC, BusUnit, HT & DDR IF ~32%
Dual-Core K8: 2x512k L2, 2xCPU Core, 1xMC/BU/HT/DDR => Fläche Relativ: 42 + 52 + 32 = 126
Die 20% die AMD angibt wurden wohl ausgehend vom neunen Flächenbedarf berechnet:
(D.h. 126 entspricht 100% => alter Core benötigt nur 100/126 * 100 = 79% Flächenbedarf im vergleich zu neuem Core => "rund" 20% mehr Fläche notwendig). NB: An AMD's stelle würde ich korrekter weise 26% mehr Fläche angeben, aber das ist eine Frage der Sichtweise.
@Online-Slider
> Einziges bisheriges Fakt ist: Unterstützung von TCPA (like Prescott).
Dazu gibts noch Anzumerken, dass heute schon jedes MB mit einem TPM bestückt werden könnte. Im übrigen ist noch gar nicht raus was LaGrande wirklich alles implementiert. Momentan sieht es noch so aus als würde man ein zusätzliches TPM benötigen.
Zum Thema QBM (Quad Band Memory, verwendet QDR als Übertragugsverfahren): Da wette ich drauf, dass AMD das garantiert nicht integriert! IMO ist QBM eine Totgeburt. Intel läßt die Finger davon und selbst VIA hat QBM von der Featureliste des PT880 gestrichen -- nur einen Monat nach dem man dies Angekündigt hatte!.
@mtb][sledgehammer
> Wie verschwendrisch es ist, zwei getrennte Caches zu verbasteln, hängt wohl vom Programm ab. Arbeiten beide CPUs an völlig getrennten Prozessen, dann sind diese mit Sicherheit schneller. Problematisch kann das mit den zwei Caches eigentlich nur werden, wenn, beide im Grunde das gleiche ist, und somit immer in beiden Caches das selbe stehen muss.
Der Normalfall ist das unterschiedliche Threads (Prozesse) auf unterschiedliche Daten zugreifen. Für den anderen Fall benötigt man sowieso Thread-Synchronisation-Mechanismen, die die Performance weit aus mehr beeinflussen, als eine kleinere effektive Cachegröße.
Wie klein der Unterschied i.d.R. ist sieht man ganz gut am A64 3000+ (macht wohl ca. 10% aus).
@Treverer
> daten könnten/werden doppelt im cache stehen, was nach einer halbierung noch unangenehmer wäre.
Effektiv macht sich nur die halbierung des Cache bemerkbar -- ob die Daten in ein oder zwei L2 Caches stehen, spielt keine Rolle*.
* Es gibt natürlich die Abhängigkeit vom MOESI Protokoll, aber das ist nur relevant wenn man mit einem Single-CPU System vergleicht. Vergleicht man ein Dual-Core mit einem herkömlichen Dual-CPU System gibt es keinen zusätzliches Performance Penalty!
> wenn man doch zwei getrennte l2-caches nimmt und genauso macht wie bei den opterons, nämlich, daß die eine cpu erst in ihrem lokalem cache nach den daten sucht, dann im cache der nächsten cpu und erst dann im ram?
Das ist durch das MOESI Cach-Koherenzprotokoll auf alle Fälle gewährleistet. Vorteil einer on die Lösung: Das Cache Snooping ist viel schneller; es fällt die HT Latenz weg.
> warum eigentlich überhaupt einen kompletten core mit ranschustern und eben nicht nur eine zusätzliche fpu- und z.b. zwei zusätzliche alu-einheiten?
1) Mehr Funktionseinheiten -> Größere Scheduler-Komplexität
2) Erheblicher Engineering-Aufwand (U.a ein nicht kleines Verifikations-Nightmare)
3) Vorteile eines zweiten Core:
- Architecture/Engineering Reuse
- Parallele Verarbeitung von verschiedenen Prozessen (Unterschiedliche Virtual Memory Maps!)
- Einfacher für das OS/Programiermodell als logische und physikalische CPUs (SMT) zu unterscheiden.
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
> wo genau siehste die nachteile von QBM ?
Bei QBM werden die Daten abwechselnd von 2 DDR Memory-Bänken gelesen/geschrieben. Um die zwei Memorybänke anzusteurern benötigt jedes QBM Modul zusätzlich einen QBM-Switch und einen QBM-Clock Generator.
Konsequenzen:
Bei QBM werden die Daten abwechselnd von 2 DDR Memory-Bänken gelesen/geschrieben. Um die zwei Memorybänke anzusteurern benötigt jedes QBM Modul zusätzlich einen QBM-Switch und einen QBM-Clock Generator.
Konsequenzen:
- Man braucht doppelt so viele Memory Chips wie ein entsprechendes DDR1/DDR2 Modul
- Dazu kommen noch zwei Chips (QBM-Switch/QBM-Clock)
- Die Latenz bleibt auf DDR Niveau (=kein Gewinn). Kurz gesagt: Wer will schon ein QBM533 Modul mit DDR 266 Latenzen, wenn man inzwischen sogar DDR 566 Module mit entsprechend niedrigen Latenzen bekommt?
- Die Memory-Hersteller wollen sich nicht die Technik aus der Hand nehmen lassen. Kentron und der Rest der QBM Alliance kommen aus dem Chipset/Speicher-Modul Sektor.
- QBM ist kein offizieller JEDEC Standard
- Wer nur nach Bandbreite sucht geht Richtung XDR
mtb][sledgehammer
Grand Admiral Special
An MOESI habe ich gar nicht gedacht, aber genau das dürfte der richtige Weg sein. Man hat efektiv einen großen L2 Cache, allerings wie beim Unterschied zwischen L1 und L2 in der exklusiven Hierarchie gibts kleine Latenzunterschiede. Dieser Unterschied dürfte aber wie schon erwänt relativ gering sein, da alles on Die ist.
Für QBM sehe ich auch keine Zukunft, viel eher für QDR RAM. Aber schon mit DDR II dürfte vorerst genügend Luft nach oben vorhanden sein. Ich gehe mal davon aus, dass man auch DDRII Chips mit intern 200 MHz betreiben kann, also effektiv DDR II 800 was dank Dual Channel 12,8 GB/s entspricht.
Für QBM sehe ich auch keine Zukunft, viel eher für QDR RAM. Aber schon mit DDR II dürfte vorerst genügend Luft nach oben vorhanden sein. Ich gehe mal davon aus, dass man auch DDRII Chips mit intern 200 MHz betreiben kann, also effektiv DDR II 800 was dank Dual Channel 12,8 GB/s entspricht.
liegen in der Luft...
Jedenfalls zeigen die derzeitigen "Athlon64 512", dass kaum Leistung verlorengeht.
In der Tat durfte die Latenz deutlich reduziert sein zwischen den beiden Kernen auf dem Die...
So könnte doch relativ früh schon ein Hammer mit Dual- Core auf dem Markt erscheinen... rein hypothetisch natürlich!
QBM war in dem Moment tot als VIA nicht mehr so dahinter steckte... die Notwendigkeit für mehr Speicherchips kannt ich noch nicht... macht die Wahrscheinlichkeit für QBM noch geringer.
Die Hersteller gehen ja immer weiter dazu über, möglichst wenige Speicherchips zu verbauen. Diese Einzelchips können aber immer mehr Daten Speichern.
Jedenfalls zeigen die derzeitigen "Athlon64 512", dass kaum Leistung verlorengeht.
In der Tat durfte die Latenz deutlich reduziert sein zwischen den beiden Kernen auf dem Die...
So könnte doch relativ früh schon ein Hammer mit Dual- Core auf dem Markt erscheinen... rein hypothetisch natürlich!
QBM war in dem Moment tot als VIA nicht mehr so dahinter steckte... die Notwendigkeit für mehr Speicherchips kannt ich noch nicht... macht die Wahrscheinlichkeit für QBM noch geringer.
Die Hersteller gehen ja immer weiter dazu über, möglichst wenige Speicherchips zu verbauen. Diese Einzelchips können aber immer mehr Daten Speichern.
Zuletzt bearbeitet:
Slider
Admiral Special
- Mitglied seit
- 02.08.2003
- Beiträge
- 1.878
- Renomée
- 0
Ähm, QBM ist doch eigendlich nur ein 128BIT Breites Interface für den RAM, da werden 2 Module auf einem zusammengefasst und mit je 64BIT angesprochen. Und das ganze im DDR verfahren, oder?
Habe leider nur am Rande die Technik von QDR RAM mitbekommen und möchte daher nicht hier meine Aussage 100%ig unterstreichen
Wer errinnert sich noch an 3GIO (3G10) Third Generation 1 / 0 . Das sollte mal der Schnittstellen Standard der Zukunft werden und PCI ablösen, naja das war wohl nix... 
Habe leider nur am Rande die Technik von QDR RAM mitbekommen und möchte daher nicht hier meine Aussage 100%ig unterstreichen
Wer errinnert sich noch an 3GIO (3G10)
Third Generation 1 / 0 . Das sollte mal der Schnittstellen Standard der Zukunft werden und PCI ablösen, naja das war wohl nix... http://firingsquad.com/features/amd_henri_richard_interview/page4.asp
FiringSquad: Intel’s Hyper-Threading technology has lots of promise, but very few applications support it directly. What is your take on this new feature?
Henri Richard: Well I believe that, you know again it’s a software issue here. I don’t recall [inaudible] 64-bit in Hyper-Threading, not that they’re exclusive to each other. But we’ve chosen the path of 64-bit and that’s the path we’re going to push. I also believe that, well I’m always concerned when marketing comes on top of you know some sort of feature and it confuses people.
I think that representing Hyper-Threading as buying two processors for the price of one is deceiving customers, and that’s not AMD’s strategy.
I believe that the future of desktop computing will go with the future of server, which is multi-core processors. There you will have multiple core processors and when you say you have dual processors you really will have two processors and you’ll get much better scalability of performance than Hyper-Threading.
Now this being said, you know like any technology we’re looking at it, and it’s not that complex of a technology to implement. If customers, if the marketplace finally endorse that technology over multi-core processors then we’ll deliver what the customer wants us to do. But at this point in time I’m a believer that 64-bit on one side and multi-core CPUs are approachable relevant to the future of our industry more so than Hyper-Threading.
FiringSquad: So you acknowledge that AMD has looked into multi-core CPUs?
Henri Richard: Well, we’ve announced it, but I’m not telling you that tomorrow morning on the desktop that [we’ll have it] but we have stated clearly that we are working on multi-core CPUs on Opteron and as you know Opteron, the natural destination of Opteron ends up in the FX range. So it’s easy to assess that AMD will announce the official you know, Opteron multi-core product. Sometime down the line later you’ll find a multi-core desktop product because it’s the same core.
das ganze interview hier:
http://firingsquad.com/features/amd_henri_richard_interview/default.asp
FiringSquad: Intel’s Hyper-Threading technology has lots of promise, but very few applications support it directly. What is your take on this new feature?
Henri Richard: Well I believe that, you know again it’s a software issue here. I don’t recall [inaudible] 64-bit in Hyper-Threading, not that they’re exclusive to each other. But we’ve chosen the path of 64-bit and that’s the path we’re going to push. I also believe that, well I’m always concerned when marketing comes on top of you know some sort of feature and it confuses people.
I think that representing Hyper-Threading as buying two processors for the price of one is deceiving customers, and that’s not AMD’s strategy.
I believe that the future of desktop computing will go with the future of server, which is multi-core processors. There you will have multiple core processors and when you say you have dual processors you really will have two processors and you’ll get much better scalability of performance than Hyper-Threading.
Now this being said, you know like any technology we’re looking at it, and it’s not that complex of a technology to implement. If customers, if the marketplace finally endorse that technology over multi-core processors then we’ll deliver what the customer wants us to do. But at this point in time I’m a believer that 64-bit on one side and multi-core CPUs are approachable relevant to the future of our industry more so than Hyper-Threading.
FiringSquad: So you acknowledge that AMD has looked into multi-core CPUs?
Henri Richard: Well, we’ve announced it, but I’m not telling you that tomorrow morning on the desktop that [we’ll have it] but we have stated clearly that we are working on multi-core CPUs on Opteron and as you know Opteron, the natural destination of Opteron ends up in the FX range. So it’s easy to assess that AMD will announce the official you know, Opteron multi-core product. Sometime down the line later you’ll find a multi-core desktop product because it’s the same core.
das ganze interview hier:
http://firingsquad.com/features/amd_henri_richard_interview/default.asp
PuckPoltergeist
Grand Admiral Special
Original geschrieben von Online-Slider
Wer errinnert sich noch an 3GIO (3G10)
Wieso
PCI-Express kommt doch.
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@mtb
> An MOESI habe ich gar nicht gedacht, aber genau das dürfte der richtige Weg sein. Man hat efektiv einen großen L2 Cache, allerings wie beim Unterschied zwischen L1 und L2 in der exklusiven Hierarchie gibts kleine Latenzunterschiede.
MOESI legt nicht das Cache-Design (inclusive, exclusive, unified, multiported, etc.) fest, sondern den Mechanismus wie die Kohärenz der Cachedaten gewährleistet wird.
MOESI Cachezeilen Zustands-Übersicht:
Siehe auch http://users.ece.gatech.edu/~mvelev/fall02/ece6100/html/MESI.pdf
@bokill
> .. die Notwendigkeit für mehr Speicherchips kannt ich noch nicht...
Naja in der Produktion relativiert sich das. Man könnte die QBM-Module aus x16 Chips aufbauen, dann braucht man genau so viele Chips wie ein DDR-Modul das aus x8 Chips aufgebaut ist.
> An MOESI habe ich gar nicht gedacht, aber genau das dürfte der richtige Weg sein. Man hat efektiv einen großen L2 Cache, allerings wie beim Unterschied zwischen L1 und L2 in der exklusiven Hierarchie gibts kleine Latenzunterschiede.
MOESI legt nicht das Cache-Design (inclusive, exclusive, unified, multiported, etc.) fest, sondern den Mechanismus wie die Kohärenz der Cachedaten gewährleistet wird.
MOESI Cachezeilen Zustands-Übersicht:
Code:
Yes <- Valid? -> No: [b]Invalid State[/b]
|
v
Yes <------------ Modified? ------------> No
| |
v v
[b]Owned[/b]: Yes <- Shared? -> No: [b]Modified[/b] [b]Shared[/b]: Yes <- Shared? -> No: [b]Exclusive[/b]
^
Nur in diesem Zustand werden Cache-Line-Daten zwischen den Caches ausgetauschtSiehe auch http://users.ece.gatech.edu/~mvelev/fall02/ece6100/html/MESI.pdf
@bokill
> .. die Notwendigkeit für mehr Speicherchips kannt ich noch nicht...
Naja in der Produktion relativiert sich das. Man könnte die QBM-Module aus x16 Chips aufbauen, dann braucht man genau so viele Chips wie ein DDR-Modul das aus x8 Chips aufgebaut ist.
Slider
Admiral Special
- Mitglied seit
- 02.08.2003
- Beiträge
- 1.878
- Renomée
- 0
Na klar kommt PCI-Express, das hat aber nichts mit 3G10 zu tun, genausowenig wie mit PCI-X. 3G10 basiert eben n i c h t auf dem PCI Bus (wie PCI-Express oder PCI-X)Original geschrieben von PuckPoltergeist
Wieso
PuckPoltergeist
Grand Admiral Special
Ähem, PCI-Express hat bis auf den Namen auch nichts mehr mit dem heutigen PCI-Bus zu tun. Ich werde nochmal nachsehen, aber ich bin nahezu 100% sicher, daß PCI-Express das 3GIO ist.
http://www.heise.de/newsticker/resu...ata/ciw-01.10.03-001/default.shtml&words=3GIO
http://www.heise.de/newsticker/resu...ata/ciw-01.10.03-001/default.shtml&words=3GIO
mtb][sledgehammer
Grand Admiral Special
3GIO ist exakt das selbe wie PCI Express. Und vollkommen etwas anderes als PCI: PCI arbeitet parallel als Bus, das heißt alle Geräte sitzen auf der selben Datenleitung. Dagegen ist PCI Express wie USB, SATA oder Hyper Transport eine serielle Technolgie. Dies hat den Vorteil, dass man extrem hohe Taktfrequenzen fahren kann, und dafür im Gegenzug die Bitbreite deutlich reduzieren kann. Dadurch wird das Routing auf dem Mainboard deutlich vereinfacht. Es existieren auch keine getrennten Daten- Adress und Steuerleitungen mehr. Alles wird schön in Paketen verpackt gesendet. Habe da noch ein kleines Bild aus eine älteren TecChannel Zeitschrift:
@ HenryWince
Danke für die Verbesserung, habe das wohl etwas salopp formuliert
@ HenryWince
Danke für die Verbesserung, habe das wohl etwas salopp formuliert
PuckPoltergeist
Grand Admiral Special
Das entscheidende bei PCI-Express ist nicht nur der Wechsel von parallel zu seriell, sondern daß es eine Punkt-zu-Punkt Verbindung ist (wie eben auch Infiniband oder HT). Das heutige PCI (und PCI-X) ist dagegen ein Bus.
Der Vergleich mit USB stimmt so nicht. USB ist auch ein richtiger Bus, bei dem sich die angeschlossenen Geräte die Bandbreite teilen.
Der Vergleich mit USB stimmt so nicht. USB ist auch ein richtiger Bus, bei dem sich die angeschlossenen Geräte die Bandbreite teilen.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Online-Slider:
Schreibst du das absichtlich so: 3G10?
Ich dachte erst, mein Konqueror zeigt mir die Zeichen falsch an.
Schreibst du das absichtlich so: 3G10?
Ich dachte erst, mein Konqueror zeigt mir die Zeichen falsch an.
PuckPoltergeist
Grand Admiral Special
Ok, ich hatte nur wirklich schon an meinem Browser gezweifelt.
Ähnliche Themen
