Opteron/Athlon64 und integrierter Speichercontroller
- Ersteller SirGalahad5
- Erstellt am
SirGalahad5
Vice Admiral Special
Nachdem der Opteron jetzt auf dem Markt ist, hab ich mir mal Gedanken über den Sinn/Unsinn des integrierten Speichercontrollers gemacht.
Ich denke da muss rigoros zwischen Opteron und Athlon64 unterschieden werden.
Beim Opteron macht der Speichercontroller insofern Sinn, als daß jede CPU in einem Multiprozessor System von einem eigenen Speichercontroller enorm profitiert. Keine Umwege über Engpässe in der Northbridge. Das ganze noch kombiniert mit der direkten Verbindung der CPUs über die Hyper Transport Kanäle. Je mehr CPUs in einem Opteron SMP System, desto mehr spricht für den Integrierten Speichercontroller. Bei den jetzt getesteten 2 CPU Systemen wird das meiner Meinung nach noch nicht so offensichtlich.
Beim Opteron macht der integrierte Speichercontroller also durchaus Sinn.
Wie ist das aber beim Athlon64?
Ich halte es für durchaus möglich, das sich hier auf Dauer der externe Speichercontroller wieder ethablieren könnte. Der Grund hierfür ist der Faktor Bandbreite. Der einzige Vorteil, den der integrierte Speichercontroller bei einem Ein - CPU Desktop System hat ist meiner Meinung nach Latenz. Da ist der integrierte Controller dem externen Controller deutlich überlegen. Allerdings sind im Laufe der Jahre, vor allem mit der Integration der Caches in die Prozessor-Dies die Prefetch Algorythmen so effizient geworden, das Latenz eine immer geringere Rolle spielt. Krassestes Beispiel ist hier wohl der P4 und Rambus. Was also bleibt ist die Bandbreite. Und da ist der Athlon64 auf einkanaliges (vermutlich) DDR400 Interface beschränkt. Wenn ich daran denke, das früher oder später mit dem Prozessor auch 64 Bit Code verarbeitet werden soll, dann sehe ich hier ein echtes Problem mit der Bandbreite. Da wäre ein zweikanaliges Interface deutlich vorzuziehen.
Was meint ihr dazu?
Edit: Rähchtschraibfähler
Ich denke da muss rigoros zwischen Opteron und Athlon64 unterschieden werden.
Beim Opteron macht der Speichercontroller insofern Sinn, als daß jede CPU in einem Multiprozessor System von einem eigenen Speichercontroller enorm profitiert. Keine Umwege über Engpässe in der Northbridge. Das ganze noch kombiniert mit der direkten Verbindung der CPUs über die Hyper Transport Kanäle. Je mehr CPUs in einem Opteron SMP System, desto mehr spricht für den Integrierten Speichercontroller. Bei den jetzt getesteten 2 CPU Systemen wird das meiner Meinung nach noch nicht so offensichtlich.
Beim Opteron macht der integrierte Speichercontroller also durchaus Sinn.
Wie ist das aber beim Athlon64?
Ich halte es für durchaus möglich, das sich hier auf Dauer der externe Speichercontroller wieder ethablieren könnte. Der Grund hierfür ist der Faktor Bandbreite. Der einzige Vorteil, den der integrierte Speichercontroller bei einem Ein - CPU Desktop System hat ist meiner Meinung nach Latenz. Da ist der integrierte Controller dem externen Controller deutlich überlegen. Allerdings sind im Laufe der Jahre, vor allem mit der Integration der Caches in die Prozessor-Dies die Prefetch Algorythmen so effizient geworden, das Latenz eine immer geringere Rolle spielt. Krassestes Beispiel ist hier wohl der P4 und Rambus. Was also bleibt ist die Bandbreite. Und da ist der Athlon64 auf einkanaliges (vermutlich) DDR400 Interface beschränkt. Wenn ich daran denke, das früher oder später mit dem Prozessor auch 64 Bit Code verarbeitet werden soll, dann sehe ich hier ein echtes Problem mit der Bandbreite. Da wäre ein zweikanaliges Interface deutlich vorzuziehen.
Was meint ihr dazu?
Edit: Rähchtschraibfähler
Zuletzt bearbeitet:
SirGalahad5
Vice Admiral Special
Original geschrieben von SKYNET
du vergisst aber auch das der "FSB" mit vollem coretakt renntalso ist nurnoch der speicher der engpass !
Logo, schon klar. Aber vom Controller ist nun mal abhängig, wie hoch der Speicherdurchsatz maximal ist: Wenn der Controller nur einen Speicherkanal zur Verfügung stellt, ist nun mal bei 1XDDR400 Schluss. Das der Controller selbst nicht das Problem ist, sondern die Speicherbandbreite, sollte klar sein.
Zuletzt bearbeitet:
Einerseits hast du recht,daß die Speicheranbindung recht mager ist, aber wenn viele Hobbykonsumer bereit sind sich ein Opteron und Board zu holen, wer weiß, möglicherweise kommt dann ein Konsumermodell mit 1HT-Kanal aber doppeltem Speicherinterface!
PS Im Vergleich zur klassischen Architektur hat der Athlon64 eine "Busbandweite" von Speicherbandbreite + Hypertransportbandbreite, das hast du klar erkannt, keiner kann zur Zeit aber sagen wieviel Reserven noch im Speicherkontroller sind. Mit DDRII werden die Latenzen wieder steigen, kann sein daß DDRI uns länger erhalten bleibt wie von der Industrie geplant
PS Im Vergleich zur klassischen Architektur hat der Athlon64 eine "Busbandweite" von Speicherbandbreite + Hypertransportbandbreite, das hast du klar erkannt, keiner kann zur Zeit aber sagen wieviel Reserven noch im Speicherkontroller sind. Mit DDRII werden die Latenzen wieder steigen, kann sein daß DDRI uns länger erhalten bleibt wie von der Industrie geplant
Der Athlon 64 hat zumindest ne höhere Bandbreite als n FSB400 barton auf nem nforce2 und gleichzeitig noch die deutlich geringere Latenz. und falls Dual-channel irgendwann mal nötig wird : Wer sagt denn, dass es nicht möglich ist das in den A64 zu integrieren? der A64 hat zwar über 100 weniger Pins als der Opteron, aber immer noch fast 300! mehr als der socketA. Das würde doch wahrscheinlich für dual-DDR langen. Wenn nicht, kann AMD immer noch den Opteron-Sockel auch für den Power-user bringen. (was auch passieren wird, denn was unterscheidet ein Workstation-board schon von nem normalen Board...nichts ausser ECC)
Und für den Normalo-Kunden reicht Single-channel locker aus.
Und für den Normalo-Kunden reicht Single-channel locker aus.
PC400 an sich hat auf beiden Systemen, Athlon XP und Athlon 64, genau die gleiche Bandbreite. Der begrenzende Faktor beim Athlon XP mit FSB200 ist der FSB, beim Athlon 64 die PC400 des Speichers. Und die Latenzen des Speichers sind auch von den Speichermodulen vorgegeben, und nicht vom Controller. Der einzige Vorteil beim Athlon 64 ist, dass keine Northbridge zw. CPU und RAM hängt, die zusätzlichen Overhead verursacht.
Was den Pin-Count angeht, es wäre relativ unsinnig, einen neuen Sockel zu entwerfen und dabei genügend Pins gar nicht zu belegen, nur um später einen zusätzlichen RAM-Kanal zu haben (und ich hab keine Lust, die Pin-Belegung jetzt nachzuschauen). Und auch der Opteron ändert daran nix, weil es nicht nur darauf ankommt die nötige Anzahl an Pins zu haben. Die Pins haben eine definierte Belegung, da kann ich nicht mal kurz ein paar Pins einfach mit einem Speicherkanal neu belegen.
Für einen "Normalo-Kunden" reicht auch ein KT266 mit einem Duron um seine Mails zu checken und ab und zu einen Leserbrief an seine Lokalzeitung zu drucken. Das war aber gar nicht die Frage. Viel interessanter ist die Frage, ob das (wirklich coole) Feature eines On-Die Memorycontrollers nicht vor seinem Erscheinen im Nicht-SMP-Bereich schon wieder überholt ist. Ich erinnere da einfach mal an den P4 mit RAMBUS; dessen brachiale Speicheranbindung ging ab wie Nachbars Struppi, obwohl RAMBUS, wenn es um Latenzen geht, ja nun wirklich nicht das Gelbe vom Ei darstellt. Und wie man bei i875 sieht, kann man durchaus im Desktop-Bereich eine (quasi) PC800 Anbindung realisieren.
Damit hat dann de-facto ein heutiger P4-C schon die doppelte Speicherbandbreite zur Verfügung wie ein (noch nicht erhältlicher) Athlon 64. Und bei dem kommt noch dazu, dass die Codegröße beim Wechsel von 32 auf 64 bit -- wie schon bei 16 -> 32 bit -- ansteigen wird, er deshalb also eher noch mehr Bandbreite vertragen könnte.
Was den Pin-Count angeht, es wäre relativ unsinnig, einen neuen Sockel zu entwerfen und dabei genügend Pins gar nicht zu belegen, nur um später einen zusätzlichen RAM-Kanal zu haben (und ich hab keine Lust, die Pin-Belegung jetzt nachzuschauen
). Und auch der Opteron ändert daran nix, weil es nicht nur darauf ankommt die nötige Anzahl an Pins zu haben. Die Pins haben eine definierte Belegung, da kann ich nicht mal kurz ein paar Pins einfach mit einem Speicherkanal neu belegen.Für einen "Normalo-Kunden" reicht auch ein KT266 mit einem Duron um seine Mails zu checken und ab und zu einen Leserbrief an seine Lokalzeitung zu drucken. Das war aber gar nicht die Frage. Viel interessanter ist die Frage, ob das (wirklich coole) Feature eines On-Die Memorycontrollers nicht vor seinem Erscheinen im Nicht-SMP-Bereich schon wieder überholt ist. Ich erinnere da einfach mal an den P4 mit RAMBUS; dessen brachiale Speicheranbindung ging ab wie Nachbars Struppi, obwohl RAMBUS, wenn es um Latenzen geht, ja nun wirklich nicht das Gelbe vom Ei darstellt. Und wie man bei i875 sieht, kann man durchaus im Desktop-Bereich eine (quasi) PC800 Anbindung realisieren.
Damit hat dann de-facto ein heutiger P4-C schon die doppelte Speicherbandbreite zur Verfügung wie ein (noch nicht erhältlicher) Athlon 64. Und bei dem kommt noch dazu, dass die Codegröße beim Wechsel von 32 auf 64 bit -- wie schon bei 16 -> 32 bit -- ansteigen wird, er deshalb also eher noch mehr Bandbreite vertragen könnte.
SirGalahad5
Vice Admiral Special
@Grizz: Du nimmst mir die Worte aus dem Mund 
@ Grizz
Das mit der Codegrösse stimmt hauptsächlich für den itanium (150-300% grösser)
Bei A64 sinds laut AMD ca. 15% und die werden durch die verdoppelte Registerzahl mehr als wett gemacht.
Und wegen der Bandbreite:
den test haste dir wohl noch net angesehen:http://www.xbitlabs.com/articles/cpu/display/athlon64_6.html
memory read speed mehr als 50% schneller als Athlon XP@200FSB
memory copy auch deutlich schneller nur die write speed hängt n bissl hinterher (was möglciherweise durch n feintuning noch verbessert wird)
Und das Latenz unwichtig ist, weils prefetching gibt ist genauso Quatsch.Durch Prefetching wird bandbreite gegen latenz getauscht. Wenn die Latenz schon niedrig ist wird sie dadurch effektiv halt noch niedriger.
Das mit der Codegrösse stimmt hauptsächlich für den itanium (150-300% grösser)
Bei A64 sinds laut AMD ca. 15% und die werden durch die verdoppelte Registerzahl mehr als wett gemacht.
Und wegen der Bandbreite:
den test haste dir wohl noch net angesehen:http://www.xbitlabs.com/articles/cpu/display/athlon64_6.html
memory read speed mehr als 50% schneller als Athlon XP@200FSB
memory copy auch deutlich schneller nur die write speed hängt n bissl hinterher (was möglciherweise durch n feintuning noch verbessert wird)
Und das Latenz unwichtig ist, weils prefetching gibt ist genauso Quatsch.Durch Prefetching wird bandbreite gegen latenz getauscht. Wenn die Latenz schon niedrig ist wird sie dadurch effektiv halt noch niedriger.
...ab hier möchte ich mal meinen Senf dazugeben:
das mit den Prefetcheinheiten ist so eine Sache - die versuchen lediglich die unzähligen (so Daumen mal PI gerechnet geht das so gegen unendlich
) Sprünge moderner Programme dem Prozessor etwas vorzukauen, aber weil (ich programmiere selbst C, Assembler, PIC, Delphi, Java...) es so viele unvorhersehbare, von einem kurz vorhergehenden Ergebnis abhängige Sprünge gibt, sind diese mehr oder weniger nur eine kleine Hilfe - denn Hellsehen können die auch nicht!!!
daraus folgt, dass der Datendurchsatz mit Hilfe der Prefetch nur in einem Prozentsatz von ca. 5-15% verringert wird, was aber bedeutet, dass die Bandbreite immer noch ein sehr wichtiges Kriterium ist.
ich weiß es nicht, aber wie ich das hier verstanden habe, unterstütz der Speichercontroller des Opteron kein DualChannel-DDR... stimmt das? warum sind dann bei diversen Tests dann Systeme mit DualChannel-DDR gemacht worden - funktioniert das nur mit 2 Opterons
und warum wird von diesem Speichercontroller nur PC333 unterstützt läuft der Speichercontroller mit dem gleichen Takt wie der Opteron selbst
mfg
Apophis
das mit den Prefetcheinheiten ist so eine Sache - die versuchen lediglich die unzähligen (so Daumen mal PI gerechnet geht das so gegen unendlich
) Sprünge moderner Programme dem Prozessor etwas vorzukauen, aber weil (ich programmiere selbst C, Assembler, PIC, Delphi, Java...) es so viele unvorhersehbare, von einem kurz vorhergehenden Ergebnis abhängige Sprünge gibt, sind diese mehr oder weniger nur eine kleine Hilfe - denn Hellsehen können die auch nicht!!!daraus folgt, dass der Datendurchsatz mit Hilfe der Prefetch nur in einem Prozentsatz von ca. 5-15% verringert wird, was aber bedeutet, dass die Bandbreite immer noch ein sehr wichtiges Kriterium ist.
ich weiß es nicht, aber wie ich das hier verstanden habe, unterstütz der Speichercontroller des Opteron kein DualChannel-DDR... stimmt das? warum sind dann bei diversen Tests dann Systeme mit DualChannel-DDR gemacht worden - funktioniert das nur mit 2 Opterons
und warum wird von diesem Speichercontroller nur PC333 unterstützt läuft der Speichercontroller mit dem gleichen Takt wie der Opteron selbstmfg
Apophis
Original geschrieben von Baker
[...]
ich weiß es nicht, aber wie ich das hier verstanden habe, unterstütz der Speichercontroller des Opteron kein DualChannel-DDR... stimmt das? warum sind dann bei diversen Tests dann Systeme mit DualChannel-DDR gemacht worden - funktioniert das nur mit 2 Opterons
mfg
Apophis
Der Opteron hat 1x128Bit, er läuft mit einem 64Bit Speicherriegel überhaupt nicht. Warum nur PC2700? Es gibt schlichtweg keinen registered PC3200 ECC RAM.
Das ist allerdings der bisherige Kenntnisstand, also nicht 100% definitiv.
SirGalahad5
Vice Admiral Special
Kann ich mir kaum vorstellen, daß das so gering sein wird. Aber das kann man als einfacher User momentan schlecht nachvollziehen.
Es ist relativ egal, wieviele Register man hat..... alle Befehle sowieso kommen aus dem Instruction Register..... und davon hast du einen.
Ich habe nie behauptet, das die Speicherbandbreite schlecht sei..... oder gar schlechter als bei einem aktuellen AthlonXP System. Ich bin nur der Meinung, daß der integrierte Speichercontroller im Desktop Bereich eine Sackgasse ist, die offensichtlich werden wird wenn 64 Bit Code üblich wird. Intel ist jetzt mit seinem Canterwood/Springdale dem Athlon 64 deutlich voraus. Das ist das Fundament, auf dem der Prescott aufbauen kann/wird. Und ständig neue Athlon 64 mit neuen integrierten Speichercontrollern nachzuschieben ist
a. zu aufwändig
b. kundenunfreundlich
c. unwirtschaftlich
Prinzipiell gebe ich dir hier erst einmal recht. Aber prefetching ist viel mehr als ein Werkzeug um die Latenz zu verbessern. Es verbessert generell die Effizienz moderner CPU Architekturen. Und wie du eben sagst wird Bandbreite gegen Latenz getauscht. Situation beim Athlon 64: Ich habe einen Speichercontroller mit geringer Latenz aber einer absolut festgelegten maximalen Bandbreite. Wäre es dann nicht sinnvoller im Hinblick auf die Zukunft, die Prefetch - Algorithmen zu optimieren und die Bandbreite durch einen externen Controller nach oben hin flexibel zu gestalten?
SirGalahad5
Vice Admiral Special
Prinzipell möglich. Aber wohin möchtest du bei DDR400 denn noch wechseln?
Einen weiteren DDRI Standard wird es wohl nicht mehr geben, bleiben also noch Dual Kanal DDRI oder (in Zukunft) DDRII. Für beides wäre ein neues Board Pflicht. Und bei DDRII wäre ich mir auch nicht so sicher, ob zwischen verschiedenen Generationen dieses Speichertyps Kompatiblität herrschen wird.
Seemann
Admiral Special
Ist aber tatsächlich so, steht auch in c't und AMD-Dokumenten!
Was ist das Instruction Register?? Wir reden hier eigentlich über die GPRs (General Purpose Registers), derer der Hammer im 64-Bit-Modus 16 Stück hat - also 8 mehr als die üblichen x86-CPUs.
bei heutigen x86 Prozessoren lässt sich das IR nicht mehr so genau definieren; rein theoretisch gibt es da jetzt auch mehrere die die selbe Funktion haben, heißen halt anders - sind aber das selbe... jaja, diese paralellisierten, hellseherischen in schachtelform arbeitenden Digitaltiger sind schon was unglaublich komplexes, jaja...
Er meint das IP-Register (Instruction Pointer) welches die aktuelle OffsetAdresse der Instruktion enthält? Wir dürfen hier nicht Hard-Und Software verwechseln! IR-Register sind hardware! Es geht hier um GPR's das sind die für den Programmierer zugänglichen Register. Was die IR's machen ist hier egal.
Der Vorteil bei mehreren Registern ist, dass mehr Daten in Registern gehalten werden können (und nicht im lahmen RAM) und dadurch die Geschwindigkeit erhöht wird. Weiterhin erleichtert es Compiler-Programmierern das Programmieren (wie passend
)
Zuletzt bearbeitet:
@Baker:
Branch Prediction ist keineswegs so unsinnig. Wenn wir einmal von einer klassischen 5-stufigen Befehlspipeline ausgehen (und da hat sich in den letzten 15 Jahren nicht wirklich viel verändert), dann ist es durchaus ein Unterschied, ob mir nach einem Sprung meine Pipeline für ein oder 2 Takte leerläuft oder eben nicht. Wie sehr das eine CPU verbessern kann, sieht man am Pentium M, der u.a. eine Überarbeitung an der Branch Prediction bekommen hat.
@Seeman & Baker:
Klar brauch ich für Out-Of-Order mehrere IRs, denn vor der ID-Phase kann ich Befehle schlecht umsortieren. Aber Tatsache ist auch, dass das Interface des Athlon 64 eine beschränkte Bandbreite hat (nach jetzigem Kenntnisstand). Können wir das so festhalten? Die Performance kommt also mehr aus seiner geringen Latenz, das dürfte wohl auch bisheriger Konsens gewesen sein. Aber mal ehrlich, wie viele Anfragen gehen denn bei modernen CPUs noch wirklich an das RAM? Realistisch dürften 95% Hit-Rate für L1 und 80% für L2 sein, mit den zusätzlichen GPRs sollten Speicherzugriffe dann sogar noch seltener werden. Aber Zugriffe auf's RAM sind ja eh tödlich, da die selbst beim Speichercontroller des Athlon 64 Ewigkeiten dauern. Aber Caches und Register wollen auch gefüllt werden. Und dafür taugt dann, gerade bei so großen Caches wie beim Athlon 64, Bandbreite doch mehr als die niedrigen Latenzen. Denn kein noch so schneller Memory-Controller reicht einem L2 das Wasser, von einem L1 ganz zu schweigen.
@Appaloosa:
Naja, so ganz ignorieren kann man die Befehle bei einer CPU wohl nicht, sonst tut sie nicht arg viel. Jeder Befehl, der in die Execution-Phase will, geht vorher durch ein IR und muss dekodiert werden. Die Befehlswörter x86-64 werden länger (es müssen zusätzliche Register adressiert werden, der Adressraum wird größer, etc.), d.h. es werden für jeden Befehl mehr Daten aus dem Speicher geholt (bzw. aus dem Cache, aber auch der muss seine Daten erst mal aus dem Speicher beziehen; außerdem sind Transfers aus dem Cache ja vergleichsweise günstig). Für diesen Speicher->CPU-Transfer ist die höhere Bandbreite dann doch nicht zu verachten, die niedrigen Latenzzeiten erledigt dann der Cache (und mit Branch Prediction und Prefetching lassen sich solche Hit Rates wie oben angegeben durchaus erreichen).
Also, noch mal zusammenfassend: Moderne CPUs haben sehr wenige Speicherzugriffe, die Caches fangen das meiste ab. Das ist auch gut so, weil ein RAM-Zugriff eh ein halbes Jahrhundert (in Cycles) dauert. Deshalb sind kurze Latenzzeiten beim Speichercontroller auch nicht so wichtig, da die Caches eh kürzere Latenzen haben.
Auf der anderen Seite steht der P4, dessen hohe Bandbreite mit dem i875 (und großen Caches) ihm zu einer sehr hohen Leistung verhelfen.
Deswegen meine Befürchtung, dass eben der Speichercontroller des Athlon 64 noch vor dem Erscheinen überholt sein könnte. Außerdem trägt die zusätliche Hardware des Speichercontrollers sicher auch nicht dazu bei, den Yield des Athlon 64 zu verbessern. Und einen weiteren Controller hinzuzufügen (was ich nicht für durchführbar halte, ohne den Sockel zu ändern, aber mal prinzipiell), fügt nur noch mehr Transistoren hinzu, der Yield sinkt also noch mehr.
Für SMP-Systeme, bei denen dann jede CPU ihren eigenen Speicherkanal hat, dürfte das Konzept perfekt sein. Bei Single-CPU-Desktop System (und dafür wird der Athlon 64 gebaut), bin ich da sehr skeptisch, ob die Planung funktioniert. Aber das werden wir dann ja sehen. Aber man (oder AMD) darf mir gerne das Gegenteil beweisen; da wäre ich gerne bereit meinen Irrtum zuzugeben!
Branch Prediction ist keineswegs so unsinnig. Wenn wir einmal von einer klassischen 5-stufigen Befehlspipeline ausgehen (und da hat sich in den letzten 15 Jahren nicht wirklich viel verändert), dann ist es durchaus ein Unterschied, ob mir nach einem Sprung meine Pipeline für ein oder 2 Takte leerläuft oder eben nicht. Wie sehr das eine CPU verbessern kann, sieht man am Pentium M, der u.a. eine Überarbeitung an der Branch Prediction bekommen hat.
@Seeman & Baker:
Klar brauch ich für Out-Of-Order mehrere IRs, denn vor der ID-Phase kann ich Befehle schlecht umsortieren. Aber Tatsache ist auch, dass das Interface des Athlon 64 eine beschränkte Bandbreite hat (nach jetzigem Kenntnisstand). Können wir das so festhalten? Die Performance kommt also mehr aus seiner geringen Latenz, das dürfte wohl auch bisheriger Konsens gewesen sein. Aber mal ehrlich, wie viele Anfragen gehen denn bei modernen CPUs noch wirklich an das RAM? Realistisch dürften 95% Hit-Rate für L1 und 80% für L2 sein, mit den zusätzlichen GPRs sollten Speicherzugriffe dann sogar noch seltener werden. Aber Zugriffe auf's RAM sind ja eh tödlich, da die selbst beim Speichercontroller des Athlon 64 Ewigkeiten dauern. Aber Caches und Register wollen auch gefüllt werden. Und dafür taugt dann, gerade bei so großen Caches wie beim Athlon 64, Bandbreite doch mehr als die niedrigen Latenzen. Denn kein noch so schneller Memory-Controller reicht einem L2 das Wasser, von einem L1 ganz zu schweigen.
@Appaloosa:
Naja, so ganz ignorieren kann man die Befehle bei einer CPU wohl nicht, sonst tut sie nicht arg viel. Jeder Befehl, der in die Execution-Phase will, geht vorher durch ein IR und muss dekodiert werden. Die Befehlswörter x86-64 werden länger (es müssen zusätzliche Register adressiert werden, der Adressraum wird größer, etc.), d.h. es werden für jeden Befehl mehr Daten aus dem Speicher geholt (bzw. aus dem Cache, aber auch der muss seine Daten erst mal aus dem Speicher beziehen; außerdem sind Transfers aus dem Cache ja vergleichsweise günstig). Für diesen Speicher->CPU-Transfer ist die höhere Bandbreite dann doch nicht zu verachten, die niedrigen Latenzzeiten erledigt dann der Cache (und mit Branch Prediction und Prefetching lassen sich solche Hit Rates wie oben angegeben durchaus erreichen).
Also, noch mal zusammenfassend: Moderne CPUs haben sehr wenige Speicherzugriffe, die Caches fangen das meiste ab. Das ist auch gut so, weil ein RAM-Zugriff eh ein halbes Jahrhundert (in Cycles) dauert. Deshalb sind kurze Latenzzeiten beim Speichercontroller auch nicht so wichtig, da die Caches eh kürzere Latenzen haben.
Auf der anderen Seite steht der P4, dessen hohe Bandbreite mit dem i875 (und großen Caches) ihm zu einer sehr hohen Leistung verhelfen.
Deswegen meine Befürchtung, dass eben der Speichercontroller des Athlon 64 noch vor dem Erscheinen überholt sein könnte. Außerdem trägt die zusätliche Hardware des Speichercontrollers sicher auch nicht dazu bei, den Yield des Athlon 64 zu verbessern. Und einen weiteren Controller hinzuzufügen (was ich nicht für durchführbar halte, ohne den Sockel zu ändern, aber mal prinzipiell), fügt nur noch mehr Transistoren hinzu, der Yield sinkt also noch mehr.
Für SMP-Systeme, bei denen dann jede CPU ihren eigenen Speicherkanal hat, dürfte das Konzept perfekt sein. Bei Single-CPU-Desktop System (und dafür wird der Athlon 64 gebaut), bin ich da sehr skeptisch, ob die Planung funktioniert. Aber das werden wir dann ja sehen. Aber man (oder AMD) darf mir gerne das Gegenteil beweisen; da wäre ich gerne bereit meinen Irrtum zuzugeben!
SirGalahad5
Vice Admiral Special
Ich denke festhalten kann man auf jeden Fall:
Der Athlon64 wird in erster Revision mit Sicherheit inclusive des integrierten Speichercontrollers kommen. Die Chipsätze, die für den Launch zur Verfügung stehen sind fix und fertig und auch nicht so auf die Schnelle durch neue Versionen mit externem Speichercontroller zu ersetzen.
Anfangs wird der Athlon64 so auch ordentlich performen (sofern AMD den Takt noch ein wenig erhöht) und die Hersteller der Chipsätze bekommen so Zeit, externe Speichercontroller, die bsp. über Hyper Transport an die CPU angebunden werden, zu entwickeln.
Bei der 2. Generation der Athlon64 CPUs/Chipsätze wird dies dann zum Tragen kommen. Der Opteron/Athlon64 ist ja trotz integriertem Speichercontroller von AMD explizit auch für die Ansteuerung eines externen Controllers vorgesehen. D.h. ohne die Architektur des Prozessors zu verändern könnte direkt auf die externe Speicherlösung umgeschwenkt werden. Was ich mir zudem vorstellen könnte ist, das spätere Versionen des Athlon64 überhaupt keinen Speichercontroller mehr on-Die bekommen werden.
Voraussetzung ist hier natürlich, daß sich eine solche Variante auf lange Sicht günstiger produzieren lässt als die Variante mit Speichercontroller on-Die.
Der Athlon64 wird in erster Revision mit Sicherheit inclusive des integrierten Speichercontrollers kommen. Die Chipsätze, die für den Launch zur Verfügung stehen sind fix und fertig und auch nicht so auf die Schnelle durch neue Versionen mit externem Speichercontroller zu ersetzen.
Anfangs wird der Athlon64 so auch ordentlich performen (sofern AMD den Takt noch ein wenig erhöht) und die Hersteller der Chipsätze bekommen so Zeit, externe Speichercontroller, die bsp. über Hyper Transport an die CPU angebunden werden, zu entwickeln.
Bei der 2. Generation der Athlon64 CPUs/Chipsätze wird dies dann zum Tragen kommen. Der Opteron/Athlon64 ist ja trotz integriertem Speichercontroller von AMD explizit auch für die Ansteuerung eines externen Controllers vorgesehen. D.h. ohne die Architektur des Prozessors zu verändern könnte direkt auf die externe Speicherlösung umgeschwenkt werden. Was ich mir zudem vorstellen könnte ist, das spätere Versionen des Athlon64 überhaupt keinen Speichercontroller mehr on-Die bekommen werden.
Voraussetzung ist hier natürlich, daß sich eine solche Variante auf lange Sicht günstiger produzieren lässt als die Variante mit Speichercontroller on-Die.
Crashman
Grand Admiral Special
Wenn AMD vor hätte diese Technik schnell wieder zu verwerfen, hätten sie sich bestimmt nicht die Mühe gemacht sie zu entwickeln.
Es soll wohl verdammt schwer gewesen sein das fertig zu bekommen.
Steckt im Crossbarcontroller (für die Kommunikation mit der Aussenwelt zuständig) eigentlich Nvidia Technik ?
MfG
Es soll wohl verdammt schwer gewesen sein das fertig zu bekommen.
Steckt im Crossbarcontroller (für die Kommunikation mit der Aussenwelt zuständig) eigentlich Nvidia Technik ?
MfG
Ich glaube so etwas erfahren wir erst beim K10, wenn uber seine Entstehungsgeschichte geschrieben wird, bzw nVidia gegen AMD wegen irgendetwas klagt, weil dann wieder nVidia gerne mit Intel wegen des neuen q-Kasten auf BeOS Basis zusammenarbeitet.
Rein zeitlich gesehen glaube ich aber nicht, daß AMD viel Austausch mit nVidia hatte, denn als der Athlon frisch gabacken war, sind schon die Überlegungen zum Hammer gesponnen worden!
Rein zeitlich gesehen glaube ich aber nicht, daß AMD viel Austausch mit nVidia hatte, denn als der Athlon frisch gabacken war, sind schon die Überlegungen zum Hammer gesponnen worden!
Also so kundeunfreundlich istd er Integriert Speichercontroller nicht.
Denn beim A64 wird er von ANfang an DDR-400 unterstützen.
in 2. Revison wird er DDR2 Unterstützen (was abwärtskompatibel ist zu DDR1)
wahrscheinlich bis zum Speedgrade 667MHZ DDR2.
Und anders als zur Zeit ist das nicht wirklich, denn mit nem alten Mainboard wie KT333 oder gar kt133A verschenkt man gegenüber nforce2 massig performance und für DDR-400 oder FSB 166 musste man sich auch häufig n neues MB holen.
Ausserdem reduziert der integrierte COntroller auf Dauer die Mainboardkosten, da keine Northbridge mehr nötig ist (nur noch n AGP-Tunnel)
Das spart ausserdem auch an Stromverbrauch (3HT-links +dual_DDR COntroller verbrauchen auf dem Opteron grademal 5Watt)
Der Trend wird immer weiter gehen zu mehr Integration, AMD geht da genau den richtigen Weg.
Denn beim A64 wird er von ANfang an DDR-400 unterstützen.
in 2. Revison wird er DDR2 Unterstützen (was abwärtskompatibel ist zu DDR1)
wahrscheinlich bis zum Speedgrade 667MHZ DDR2.
Und anders als zur Zeit ist das nicht wirklich, denn mit nem alten Mainboard wie KT333 oder gar kt133A verschenkt man gegenüber nforce2 massig performance und für DDR-400 oder FSB 166 musste man sich auch häufig n neues MB holen.
Ausserdem reduziert der integrierte COntroller auf Dauer die Mainboardkosten, da keine Northbridge mehr nötig ist (nur noch n AGP-Tunnel)
Das spart ausserdem auch an Stromverbrauch (3HT-links +dual_DDR COntroller verbrauchen auf dem Opteron grademal 5Watt)
Der Trend wird immer weiter gehen zu mehr Integration, AMD geht da genau den richtigen Weg.
Also zur Zeit scheint nur noch Intel auf so'n externen Speicherkontroller zu setzen, is zwar schön flexibel, aber hat schlechte Latenzen und bei mehreren Prozessoren wird die Bandbreite pro CPU immer geringer. Intel antwortet klassisch mit noch mehr Cache und dazu noch dazu L3, L4, L5 und so weiter Cache, dies kostet aber Die-Fläche und macht die CPU's tendenziell teuer. Da hat AMD schon den geschickteren Weg gewählt, zumindest bei Vielfach-CPU Systemen.
PS ist es wirklich sicher, daß der Opteron zwingend nur mit 128 bit Speicherbreite läuft?
Oder anders Formuliert ein Athlon64 kann nicht auf einem Opteron Board laufen, da der Athlon64 zuwenig Beinchen hat?
PS ist es wirklich sicher, daß der Opteron zwingend nur mit 128 bit Speicherbreite läuft?
Oder anders Formuliert ein Athlon64 kann nicht auf einem Opteron Board laufen, da der Athlon64 zuwenig Beinchen hat?
Ähnliche Themen
