K9 - erste Fakten?
- Ersteller mtb][sledgehammer
- Erstellt am
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Kaum ist ein Prozessor erhältlich, so tauchen meist schon die ersten Gerüchte über dessen Nachfolger auf. Erste offizielle Fakten zum K8 gab es beispielsweise schon im Sommer 2000, nachdem der Athlon (K7) im Sommer 1999 in den Markt drängte. Den K8 gibt es mittlerweile seit April 2003 als Opteron und seit September 2003 als Athlon 64 zu kaufen, aber zu deren lanfristigen Nachfolgern der K9 Generation gab es bislang allenfalls Gerüchte, über die in unserem Forum auch ausführlichst <a href="http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=109777">diskutiert</a> wird.
Im <a href="http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF" target="b">Software Optimization Guide</a> für die AMD Athlon 64 und AMD Opteron Prozessoren findet man jedoch eine konkrete Andeutung auf eine mögliche Verbesserung im K9: <ul><i>Future processors with more or wider multipliers and adders will achieve better throughput using SSE and SSE2 instructions. (Today's processors implement a 128-bit-wide SSE or SSE2 operation as two 64-bit operations that are internally pipelined.)</i></ul>Der K8 Nachfolger soll also eine bessere 128 Bit SIMD (SSE/SSE2) Leistung bieten, eine Verbesserung, die auf alle Fälle Sinn machen würde. Denn heute verarbeiten die Hammer/K8 Prozessoren 128 Bit SIMD Operationen in je 2 Häppchen a 64 Bit, was natürlich den Durchsatz der CPU stark behindert. Damit erklärt sich im Übrigen auch, warum Opteron und Athlon 64 nicht - wie eigentlich erwartet - durch SSE2 einen enormen Geschwindigkeitsschub erhalten.
Eine weitere Andeutung machte Symon Chang, Geschäftsführer bei Tyan, in einem kürzlichen Interview: <ul><i>Around 2006, when the market moves to AMD's next generation of chips, you will be able to go over 8-way. What I mean is that with eight sockets, and dual cores, you then have sixteen processors, but with K9, you'll see it go over that. I think we'll see a significant increase in the amount of crossbar switches in the CPU. I'm not up on all the minute details, but you'll be able to go over 60 processors without adding any external crossbar chips.</i></ul>Während der Opteron duch seine integrierte Crossbar und die drei Hyper Transport Links heute fähig ist ohne zusätzliche Kommunikationschips bis zu sieben weitere Prozessoren anzusprechen (mit den kommenden <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1087248616">Dual Core Prozessoren</a> können sogar bis zu 16 Prozessoren direkt miteinander kommunizieren), soll es bei dessen Nachfolger demnach also möglich sein, über 60 Prozessoren direkt miteinander zu verbinden. Das komplette Interview mit Symon Chang findet ihr <a href="http://www.digitimes.com/news/a20040726PR202.html" target="b">hier</a>.
Thx Dresdenboy für den Hinweis
Im <a href="http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF" target="b">Software Optimization Guide</a> für die AMD Athlon 64 und AMD Opteron Prozessoren findet man jedoch eine konkrete Andeutung auf eine mögliche Verbesserung im K9: <ul><i>Future processors with more or wider multipliers and adders will achieve better throughput using SSE and SSE2 instructions. (Today's processors implement a 128-bit-wide SSE or SSE2 operation as two 64-bit operations that are internally pipelined.)</i></ul>Der K8 Nachfolger soll also eine bessere 128 Bit SIMD (SSE/SSE2) Leistung bieten, eine Verbesserung, die auf alle Fälle Sinn machen würde. Denn heute verarbeiten die Hammer/K8 Prozessoren 128 Bit SIMD Operationen in je 2 Häppchen a 64 Bit, was natürlich den Durchsatz der CPU stark behindert. Damit erklärt sich im Übrigen auch, warum Opteron und Athlon 64 nicht - wie eigentlich erwartet - durch SSE2 einen enormen Geschwindigkeitsschub erhalten.
Eine weitere Andeutung machte Symon Chang, Geschäftsführer bei Tyan, in einem kürzlichen Interview: <ul><i>Around 2006, when the market moves to AMD's next generation of chips, you will be able to go over 8-way. What I mean is that with eight sockets, and dual cores, you then have sixteen processors, but with K9, you'll see it go over that. I think we'll see a significant increase in the amount of crossbar switches in the CPU. I'm not up on all the minute details, but you'll be able to go over 60 processors without adding any external crossbar chips.</i></ul>Während der Opteron duch seine integrierte Crossbar und die drei Hyper Transport Links heute fähig ist ohne zusätzliche Kommunikationschips bis zu sieben weitere Prozessoren anzusprechen (mit den kommenden <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1087248616">Dual Core Prozessoren</a> können sogar bis zu 16 Prozessoren direkt miteinander kommunizieren), soll es bei dessen Nachfolger demnach also möglich sein, über 60 Prozessoren direkt miteinander zu verbinden. Das komplette Interview mit Symon Chang findet ihr <a href="http://www.digitimes.com/news/a20040726PR202.html" target="b">hier</a>.
Thx Dresdenboy für den Hinweis
PuckPoltergeist
Grand Admiral Special
Sicher? Die Logik ist ja die gleiche, welche den Datenaustausch mit den CPUs koordiniert. Gibt es dafür irgendwo was Schriftliches?
BLJ
Admiral Special
heut hab ich n shice Tag, sorry:
wie wärs mit:
1. ists im Original falsch negiert.(Original = kein Geschwindigkeitsschub wurde erwartet)
2. gefällt mir die Satzstellung mit dem keinen gleich nach dem Gedankenstrich besser, da es ja 'logisch' mit dem Zwischensatz verbunden ist...
so jetzt dürft ihr mich wegen meiner Pingeligkeit steinigen... ^^ (wär wohl ne gute Tat ^^)
cya
wie wärs mit:
1. ists im Original falsch negiert.(Original = kein Geschwindigkeitsschub wurde erwartet)
2. gefällt mir die Satzstellung mit dem keinen gleich nach dem Gedankenstrich besser, da es ja 'logisch' mit dem Zwischensatz verbunden ist...
so jetzt dürft ihr mich wegen meiner Pingeligkeit steinigen... ^^ (wär wohl ne gute Tat ^^)
cya
das mit dem direkten kommunizieren ist falsch. das sockeldesign lässt nur 3 hts nach außen zu. Somit ist keine "über-Kreuz" kommunikation mit zwei cores mehr möglich, was nur den schluß zulasst, daß ein datenstrom der path-through über core0 oder core1 den jeweils anderen erreicht.
die SSE2 leistung des athlon 64 ist komischerweise in geringen frequenzen (z.B. 800 MHz) sehr hoch...
die SSE2 leistung des athlon 64 ist komischerweise in geringen frequenzen (z.B. 800 MHz) sehr hoch...
mtb][sledgehammer
Grand Admiral Special
@Puck
Ich denke schon. Schließlich bleibt die Anzahl der Knoten (und damit die Anzahl der Spiechercontroller) identisch. Wieviele Kollegen drumherum sind, dürfte den Prozessor nicht interessieren.
Außerdem sagte Fred Webber in seinem ersten Interview, in dem er die Dual Cores ankündigte, dass man problemlos bestehende Plattformen aufrüsten könnte. OK das gibt jetzt natürlich weniger her.
3. Argument: AMD will leistungsfähigere Systeme anbieten
4. Argument: Symon Chang sagt das selbe
@BLJ
Ich gebe zu an diesem Satz habe ich auch nachgedacht, wie er am besten ist. Mir gefällts so besser
@not@AMD
Mit direkt meine ich, dass kein zusätzlicher Kommunikationschip nötig ist. Ansonsten hast du natürlich recht
Ich denke schon. Schließlich bleibt die Anzahl der Knoten (und damit die Anzahl der Spiechercontroller) identisch. Wieviele Kollegen drumherum sind, dürfte den Prozessor nicht interessieren.
Außerdem sagte Fred Webber in seinem ersten Interview, in dem er die Dual Cores ankündigte, dass man problemlos bestehende Plattformen aufrüsten könnte. OK das gibt jetzt natürlich weniger her.
3. Argument: AMD will leistungsfähigere Systeme anbieten
4. Argument: Symon Chang sagt das selbe
@BLJ
Ich gebe zu an diesem Satz habe ich auch nachgedacht, wie er am besten ist. Mir gefällts so besser
@not@AMD
Mit direkt meine ich, dass kein zusätzlicher Kommunikationschip nötig ist. Ansonsten hast du natürlich recht
PuckPoltergeist
Grand Admiral Special
Nein, die Cores werden noch vor der X-BAR gekoppelt, die müssen nicht übereinander kommunizieren.
edit: Die Verbindung wird über die SRQ (System Request Queue) hergestellt.
PuckPoltergeist
Grand Admiral Special
Das reicht ja noch nicht, die CPUs müssen alle "voneinander wissen", um die Cache-Kohärenz sicher zu stellen.
Man kann ja 8-fach Systeme mit DualCore-CPUs aufrüsten, muss dann nur vier Sockel unbstückt lassen.
Nein, es macht andersherum schon Sinn, also dass sich die Anzahl der CPUs dadurch verdoppelt. Nun ja, bin ja mal gespannt.
Trodat
Grand Admiral Special
Dann steinige ich dich jetzt mal virtuell
Meiner Meinung nach ist der Satzbau in der News nicht nur schöner, sondern dein Vorschlag ist durch die doppelte Verneinung sogar kaum noch lesbar.
also ich muß BLJ Recht geben. Der Satzbau in den News ist Sinngemäß falsch, da keine Negierung im "wie erwartet" Teil drin ist, bedeutet dadß das alles so ist wie erwartet.Original geschrieben von Trodat
Dann steinige ich dich jetzt mal virtuell
Meiner Meinung nach ist der Satzbau in der News nicht nur schöner, sondern dein Vorschlag ist durch die doppelte Verneinung sogar kaum noch lesbar.
Sehr leserlich find ich BLJ´s Vorschlag zwar auch nicht, aber er ist zumindest richtig und was besseres ist mir auch nicht eingefallen.
Allerdings ists mir beim durchlesen auch nicht aufgefallen dass das eigentlich falsch ist
*SchutzschildvorBLJaufbaugegenSteinigung*
Trodat
Grand Admiral Special
Original geschrieben von skfink
also ich muß BLJ Recht geben. Der Satzbau in den News ist Sinngemäß falsch, da keine Negierung im "wie erwartet" Teil drin ist, bedeutet dadß das alles so ist wie erwartet.
Sehr leserlich find ich BLJ´s Vorschlag zwar auch nicht, aber er ist zumindest richtig und was besseres ist mir auch nicht eingefallen.
Allerdings ists mir beim durchlesen auch nicht aufgefallen dass das eigentlich falsch ist
*SchutzschildvorBLJaufbaugegenSteinigung*
Ich bin immer noch der Meinung, dass da keine Negierung in den "wie erwartet" Einschub gehört. Das "nicht" im Hauptsatz steht ja vor dem Einschub, und dieser bezieht sich meinem Verständnis nach auf den Teil danach. Damit wäre es ja logisch dann korrekt, d.h. ursprünglich wurde ein enormer Geschwindigkeitsschub erwartet der dann aber nicht aufgetreten ist.
Aber egal was jetzt korrekt ist, ich denke so wie es in der News ist, weiß auf jeden Fall jeder was gemeint ist
Kamui
Grand Admiral Special
60 Prozessoren
Denke, das is für Server gedacht, weil ich brauch hoffentlich nich mehr als eine... im "Notfall" (
) auch zwei, aber mehr nich...Aber ne interessante News...
Ach ja, zu dem Satzbau: is doch wurscht, er wurde halt nich schneller
Zuletzt bearbeitet:
mtb][sledgehammer
Grand Admiral Special
So war auch mein Sprachgefühl: der Einschub bezieht sich auf das, was dahinter kommt. Das nicht auf alles was hinter nicht kommt. Falsch wäre is IMO folgendermaßen: <ul>warum Opteron und Athlon 64 - wie eigentlich erwartet - nicht durch SSE2 einen enormen Geschwindigkeitsschub erhalten</ul>
Mist, genau das wollte ich ursprünglich auch noch irgendwo hinpacken.
Da hast du recht, habe ich nicht bedacht.
Wie wär´s mit
"Damit erklärt sich im Übrigen auch, warum Opteron und Athlon 64 durch SSE2 keinen enormen Geschwindigkeitsschub erhalten, wie eigentlich erwartet."
Liest sich weniger holprig und ist genauso richtig wie die ursprüngliche Fassung. Die Ellipse am Ende bezieht sich ja auf den Sachverhalt des "Geschwindigkeitsschuberhaltens"; damit es deutlicher wird, würde ich sie aber evtl. ausschreiben ("wie dies eigentlich erwartet worden war").
"Damit erklärt sich im Übrigen auch, warum Opteron und Athlon 64 durch SSE2 keinen enormen Geschwindigkeitsschub erhalten, wie eigentlich erwartet."
Liest sich weniger holprig und ist genauso richtig wie die ursprüngliche Fassung. Die Ellipse am Ende bezieht sich ja auf den Sachverhalt des "Geschwindigkeitsschuberhaltens"; damit es deutlicher wird, würde ich sie aber evtl. ausschreiben ("wie dies eigentlich erwartet worden war").
du meinst wohl genauso falsch
wenn du deinen Satz anderst betonst merkst dus. Einfach mal eine Pause vor dem letzten Satzteil machen. Das "wie eigentlich erwartet" sagt aus dass das vorangegangene so war wie es zu erwarten war.
den letzten Teil konjugiert klingt das zwar schon besser, aber wohl immer noch um die die Richtigkeit betrogen:
"Damit erklärt sich im Übrigen auch, warum Opteron und Athlon 64 durch SSE2 keinen enormen Geschwindigkeitsschub erhielten, wie es eigentlich zu erwartet gewesen wäre."
mtb][sledgehammer
Grand Admiral Special
geht man von folgendem aus
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#1.5
Dann bearbeitet der Pentium 4 ebenfalls zweimal 64 Bit. Bei ihm brachte SSE2 jedoch einen enormen Schub, da der Pentium 4 mit normalen FP Operationen nicht mehr Befehle pro Takt bearbeiten konnte (hängt mit dessen internen µOp ports zusammen.) Der Opteron erreicht jedoch mit normalem FP den doppelten Durchsatz, was der selben Datenmenge wie mit SSE2 entspricht. Daher ist SSE2 nur unwesentlich schneller. Da ich das Gefühl habe, dass das sehr missverständlich ausgedrückt ist, fasse ich es in einer Tabelle zusammen: <table border="1"><tr><th>Prozessor</th><th>x87 FP</th><th>SSE2 SIMD</th></tr><tr><td>Athlon 64/Opteron</td><td>2 Ops/Takt</td><td>2 Ops/2 Takte</td></tr><tr><td>Pentium 4</td><td>1 Op/Takt</td><td>1 Op/Takt</td></tr></table>
Wobei ein SSE2 Op soviel leistet wie 2 x87 fp Ops
PuckPoltergeist
Grand Admiral Special
Das erklärt aber IMO nicht das extrem schlechte Abschneiden der P4s bei skalaren SSE-Operationen.
mtb][sledgehammer
Grand Admiral Special
Da hast du recht. Im Prinzip sollte diese in der selben Region liegen wie die x87 FP Perfomance. Eventuell findet sich das Problem im Decoder? Edit: Nein am Decoder liegt es wohl eher nicht (Das sollte der Trace Cache kompensieren)
Zur Tabelle muss ich noh ergänzen, dass diese nur auf FP Operationen zutrifft.
Zur Tabelle muss ich noh ergänzen, dass diese nur auf FP Operationen zutrifft.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Dresdenboy
Redaktion
☆☆☆☆☆☆
Vielleicht hilft auch das, was ich in einem anderen Thread schon schrieb, weiter (nachgemessen habe ich es allerdings nicht):
Andere Erklärungsidee:
Bis SSE2 werden die 2 oder 4 FP-Operanden bei Rechenoperationen unabhängig voneinander bearbeitet. Dadurch entfallen schon ein paar Schedulingprobleme, da sich die Latenzen nur um 1 Takt erhöhen, der Durchsatz aber verdoppelt. Bei Skalaroperationen wird nicht nur halb soviel pro Befehl erledigt, sondern können im folgenden Code schon nach weniger Takten Befehle auftreten, die vom vorherigen Ergebnis abhängig sind.
Anders dargestellt: Nehmen wir einmal 2 aufeinanderfolgende SSE2-Befehle (ADDPD, 4 Takte Latenz) an, wo der zweite vom ersten abhängt. Arbeite ich gerade nur mit SSE2, müsste ich 4 Takte mit anderen SSE2-Operationen überbrücken. Bei skalaren Operationen bräuchte ich 4 Befehle, bei Vektor-Operationen nur 2, da diese selbst einen Durchsatz von 1 Befehl aller 2 Takte aufweisen. Somit ergeben sich bei Vektorcode weniger Verzögerungen durch Operandenabhängigkeiten, da es bei den 8 Registern einfacher ist, die Lücke mit nur 2 anstatt 4 Befehlen füllen zu müssen.
Man könnte es auch damit vergleichen, daß die Vektorbefehle statt mit 2 Takten Durchsatz nur mit 1 Takt Durchsatz, aber bei halber Taktfrequenz und halben Latenzzeiten ausgeführt werden.
Nachtrag: Die Latenzangaben für SSE2 von George Woltman (meine Quelle) und Hans de Vries (www.chip-architect.com) differieren, aber ich schaue jetzt nicht extra im Manual nach, da das Prinzip gleich bleibt.
Andere Erklärungsidee:
Bis SSE2 werden die 2 oder 4 FP-Operanden bei Rechenoperationen unabhängig voneinander bearbeitet. Dadurch entfallen schon ein paar Schedulingprobleme, da sich die Latenzen nur um 1 Takt erhöhen, der Durchsatz aber verdoppelt. Bei Skalaroperationen wird nicht nur halb soviel pro Befehl erledigt, sondern können im folgenden Code schon nach weniger Takten Befehle auftreten, die vom vorherigen Ergebnis abhängig sind.
Anders dargestellt: Nehmen wir einmal 2 aufeinanderfolgende SSE2-Befehle (ADDPD, 4 Takte Latenz) an, wo der zweite vom ersten abhängt. Arbeite ich gerade nur mit SSE2, müsste ich 4 Takte mit anderen SSE2-Operationen überbrücken. Bei skalaren Operationen bräuchte ich 4 Befehle, bei Vektor-Operationen nur 2, da diese selbst einen Durchsatz von 1 Befehl aller 2 Takte aufweisen. Somit ergeben sich bei Vektorcode weniger Verzögerungen durch Operandenabhängigkeiten, da es bei den 8 Registern einfacher ist, die Lücke mit nur 2 anstatt 4 Befehlen füllen zu müssen.
Man könnte es auch damit vergleichen, daß die Vektorbefehle statt mit 2 Takten Durchsatz nur mit 1 Takt Durchsatz, aber bei halber Taktfrequenz und halben Latenzzeiten ausgeführt werden.
Nachtrag: Die Latenzangaben für SSE2 von George Woltman (meine Quelle) und Hans de Vries (www.chip-architect.com) differieren, aber ich schaue jetzt nicht extra im Manual nach, da das Prinzip gleich bleibt.
Ähnliche Themen
