AMD demonstriert Dual-Core CPU

[Gast]

http://www.amd.com/us-en/assets/content_type/DownloadableAssets/040831_DC_presentation.pdf

up

[StefanV]

Dazu passt auch das (http://hardtecs4u.com/?id=1093958932,9341,ht4u.php)

[Tigerchen]

HP???
Sind die nicht "First Tier" für Itanium-Server?

:tongue:

[Botcruscher]

Hallo

"Während Intel mit EM64T so lang gewartet hat, bis es im Markt ausreichend unterstützt wird, springt nun AMD ebenfalls auf die von Intel mühevoll durchgesetzte HyperThreading-Unterstützung auf."

Also sollte die Softwarebasis garnicht so schlecht sein.

Wie sieht es eigentlich bezüglich der Hardware aus? Wenn der Sockel 940 jetzt schon mit einem Bios update Dualcore fähig ist sollten ja die andern Sockel auch kein Problem sein.

Wurde auch etwas konkretes über die Verlustleistung gesagt?

[StefanV]

Wurde auch etwas konkretes über die Verlustleistung gesagt?
Ja:

Geringfügig höher.

[dildo4u]

Hallo


Wurde auch etwas konkretes über die Verlustleistung gesagt?
Maximal 95watt

http://www.computerbase.de/news/hardware/prozessoren/amd/2004/juli/amds_dual_core_athlon_95_watt/

[Endorphine]

OMG, AMD hat verstanden. :O •Higher Performance Per Watt
–Customers will experience the performance advantages of dual core processors by getting the best performance per watt available inthe market Bravo, endlich mal was praxisrelevantes, statt immer nur den MHz nachzujagen oder dem Wahn durch sinnbefreite Pentium-Ratings nachzueifern. (y)

Jetzt bin ich auf den CMP von AMD für den Mainstream-Markt gespannt. Hoffentlich wird das nicht so ein ineffizientes Design von zwei aneinandergeklebten herkömmlichen Vorgängercores wie beim PA-8800, Ultra SPARC-IV und jetzt Opteron.

[Quasar]

"Customers will experience the performance advantages of dual core processors by getting the best performance per watt available inthe market"

Ich hoffe, damit meinen die den Gesamtmarkt und nicht nur SMP-Server, denn da wäre es erstens kein Kunststück und zweitens für (die meisten von) uns nutzlos.

[Endorphine]

Das Dokument behandelt nur den Opteron. Ich habe die Hoffnung immer noch nicht aufgegeben, dass dieser Irrsinn an Ineffizienz mit zwei aneinandergeklebten normalen Cores nie den Massenmarkt erreicht.

Statt die parallel arbeitenden Einheiten kräftig aufzustocken, den Cache ebenso kräftig wachsen zu lassen, alles via SMT bequem auszulasten und damit die Entwicklung weiterlaufen zu lassen wie bisher werden auf einmal zwei für Single-Core gedachte Kerne mit etwas Verbindungslogik zusammen auf einem Die angebracht. Was für eine unglaubliche Verschwendung von Diefläche und damit teuer erkauften Produktionsprozessvorteilen, nachdem in der Vergangenheit immer galt, dass Flächeneffizienz zu größter Wirtschaftlichkeit führt.

In die andere Richtung gedacht könnte man auch bei gleichem Flächenverbrauch im Vergleich zum CMP-Opteron/PA-8800/Sparc-IV & Co. auch mehr absolute Rechenleistung bzw. überhaupt mehr Effizienz erzielen, in dem man das Design mit Techniken wie SMT optimiert behaupte ich mal.

[BlackBirdSR]

Das Dokument behandelt nur den Opteron. Ich habe die Hoffnung immer noch nicht aufgegeben, dass dieser Irrsinn an Ineffizienz mit zwei aneinandergeklebten normalen Cores nie den Massenmarkt erreicht.

Statt die parallel arbeitenden Einheiten kräftig aufzustocken, den Cache ebenso kräftig wachsen zu lassen, alles via SMT bequem auszulasten und damit die Entwicklung weiterlaufen zu lassen wie bisher werden auf einmal zwei für Single-Core gedachte Kerne mit etwas Verbindungslogik zusammen auf einem Die angebracht. Was für eine unglaubliche Verschwendung von Diefläche und damit teuer erkauften Produktionsprozessvorteilen, nachdem in der Vergangenheit immer galt, dass Flächeneffizienz zu größter Wirtschaftlichkeit führt.

In die andere Richtung gedacht könnte man auch bei gleichem Flächenverbrauch im Vergleich zum CMP-Opteron/PA-8800/Sparc-IV & Co. auch mehr absolute Rechenleistung bzw. überhaupt mehr Effizienz erzielen, in dem man das Design mit Techniken wie SMT optimiert behaupte ich mal.

Dann bring doch mal ein paar Beweise für deine nicht übersehbare Abneigung.
Wie wäre es mit ein paar Gegenvorschlägen, und Verdeutlichungen warum es so höllisch ineffizient ist.

Daneben dann gleich eine Begründung, warum es ohne weiteres möglich ist, die Ausführungseinheiten ohne Probleme aufzustocken, warum man aus x86 plötzlich mehr IPC rausholen soll.Wenn du schonmal dabei bist, wären ein paar Informationen über den Befehlsfluss von Befehlen mit SMT bei einer 12 Stufen Pipe nicht schlecht, die nichtmal dafür ausgelegt ist.
Aja, dann noch die Sache mit den Decodern.
Und wenn du fertig bist, reden wir über "bequem" und "irrsinnig"

[StefanV]

@Endo

Irgendwie leuchtet es mir nicht ein, warum SMT besser sein soll als Dual Core on DIE :|

Besonders wenn man beiden Cores dedizite Caches verpasst.

Gut, man hat ev. einige Daten doppelt, dafür hat man aber auch kein thrashing und vorallendingen können sich die beiden Cores (außer beim Speichercontroller und IO Zugriff) nicht gegenseitig behindern...

SMT hingegen hat irgendwie Probleme mit THrashing und das sich die Teile gegenseitig behindern können...

[Endorphine]

Wie wäre es mit ein paar Gegenvorschlägen, Siehe vorheriges Posting. Man braucht nur das Prinzip von SMT zu Ende zu denken. und Verdeutlichungen warum es so höllisch ineffizient ist. Ein CMP nach dem Schema frisst einfach nur Diefläche ohne Ende, ohne in gewohnter Art und Weise für die zusätzlichen Gatter auch adäquat Mehrwert zu bringen. Simples Beispiel: Wenn sich der L2-Cache beim Pentium-M verdoppelt passt auf einmal doppelt so viel Code oder Daten hinein. Klebt man stur zwei SingleCore-Kerne aneinander wird im praktischen Betrieb bei der Parallelverarbeitung eine Menge auch parallel in beiden Caches vorgehalten. Die Effizienz sinkt. Mit einem großen SMT-Design könnte man alles flexibel auslasten (ich denke auch an SSE3 dabei), bei zwei einfachen Cores läuft bei Abhängigkeiten erst mal eine CPU leer. Daneben dann gleich eine Begründung, warum es ohne weiteres möglich ist, die Ausführungseinheiten ohne Probleme aufzustocken Bitte eine Begründung von dir , warum das auf einmal nicht mehr gehen sollte. Wurde auf einmal vergessen, dass man Räder rund baut? warum man aus x86 plötzlich mehr IPC rausholen soll..Wenn du schonmal dabei bist, wären ein paar Informationen über den Befehlsfluss von Befehlen mit SMT bei einer 12 Stufen Pipe nicht schlecht, die nichtmal dafür ausgelegt ist.[/QUOTE] Ich sprach gar nicht vom Opteron, sondern von zukünftigen Mainstream-Designs. Bei Server/HPC/Workstation-CPUs kann man sich sowas scheinbar leisten. Im Massenmarkt halte ich das für nicht sehr wahrscheinlich. Im Massenmarkt können hohe Entwicklungskosten auch durch die schiere Menge an CPUs wieder hereingeholt werden, bei kleineren Mengen an extrem teuren CPUs ist es schon eher relevant, mal ein paar Millionenbeträge bei R&D einzusparen. Aja, dann noch die Sache mit den Decodern. Du hast mein Posting wirklich gelesen? Und wenn du fertig bist, reden wir über "bequem" und "irrsinnig" Die Bedeutung dieser Adjektive ist dir sicher geläufig, die brauch' ich nicht zu erläutern denke ich. :)

[Endorphine]

@Endo

Irgendwie leuchtet es mir nicht ein, warum SMT besser sein soll als Dual Core on DIE :| Davon habe ich nie gesprochen. Liest keiner meine Postings? Ich sprach nur davon, dass ich CMP nach dieser Bauweise für nicht sonderlich effizient halte und dass z. B. mittels SMT die klassische steigende Paralellisierung im Kern ungebremst weitergehen kann, ohne die Effizienznachteile, die solche einfachen CMPs mit sich bringen. Das ist nur eine Idee von mir, was man sonst machen könnte, um den Platz effizienter auszunutzen. Im Markt des Opteron ist der Die-Platzverbrauch aber nicht so wichtig, R&D-Kosten in der Evolution sind scheinbar wichtiger, siehe auch Itanic, äh Itanium, der sich mehr durch immer größere Caches auszeichnet als durch ausgefeiltere Kerne.

[StefanV]

ja, nee, ist klar, daß der 'Performancezuwachs' aktuell nicht soo groß ist, da man nicht wirklich die SW darauf ausgelegt hat, nur könnte künftige SW von Multi Core durchaus recht stark profitieren, mehr als von 'ein paar GHz mehr'.

Und sei mal ehrlich, solangsam sind wir an einem Punkt angelangt, wo man nur noch 'in die breite' gehen kann, sprich Multi Core und SMT, mehr MHz ist langfristig nicht wirklich möglich.

Obs wirtschaftlich sinnig ist oder nicht, ist ansichtssache, auf jeden Fall ist Multi Core die Zukunft, irgendwann werden wohl mal 3-4 Cores auf der CPU sitzen und nicht nur einer, wie heute...

[chAot]

@ stefan Payne-konnte dein bild nicht loaden und hoffe das es nicht das ist:

(hab ich beim surfen gefunden)

[StefanV]

DAS ist ein Fake ;)

Sind 2 Palomino Cores auf einem Träger untergebracht, Photoshop rult halt ;9

[BlackBirdSR]

Siehe vorheriges Posting. Man braucht nur das Prinzip von SMT zu Ende zu denken.

Das ist für mich kein Gegenvorschlag.
Das Prinzip von SMT ist gut, keine Frage.
Aber du läufst gegen eine Wand, wenn du damit das Scalingproblem lösen willst.

Ein CMP nach dem Schema frisst einfach nur Diefläche ohne Ende, ohne in gewohnter Art und Weise für die zusätzlichen Gatter auch adäquat Mehrwert zu bringen. Simples Beispiel: Wenn sich der L2-Cache beim Pentium-M verdoppelt passt auf einmal doppelt so viel Code oder Daten hinein. Klebt man stur zwei SingleCore-Kerne aneinander wird im praktischen Betrieb bei der Parallelverarbeitung eine Menge auch parallel in beiden Caches vorgehalten. Die Effizienz sinkt.

Du weisst ja wieviel extra Transisitoren man inwzwischen braucht, um bei x86 noch signifikante Steigerungen zu erhalten. Du weisst sicher auch um die Probleme der Signallaufzeiten, Treiber und Metaliiserungen. Ja ich bin sicher, das hast du nicht vergessen.
Achja, dazu kommt noch der Entwicklungsaufwand für soetwas. CPUs werden ja leider nicht in 6 Monaten entwickelt. So ein Anbau den du forderst auch nicht. Was ist nun ineffizient?
Dein Beispiel bringt mich nicht weiter. Um sowas gehts es gar nicht. Siehe meine Punkte gerade eben.

Mit einem großen SMT-Design könnte man alles flexibel auslasten (ich denke auch an SSE3 dabei), bei zwei einfachen Cores läuft bei Abhängigkeiten erst mal eine CPU leer

Mit einem großen SMT Design. Sowas wie Power5?
Gut dass AMDs Designteam so groß ist wie das von IBM. Und man bereits auf einen großen Post-RISC Prozessor als Basis zurückgreifen kann.

Bitte eine Begründung von dir , warum das auf einmal nicht mehr gehen sollte. Wurde auf einmal vergessen, dass man Räder rund baut?

Ich habe gefragt, weitergeben zählt vielleicht in der Logik. Hier nicht.
Aber wie schon gesagt. Du kannst dir ja mal ein bischen Wissen aneignen, was sich bei vielen Transistoren unter Last alles ändert. Vielleicht auch paar Brocken, wie sich das dann auf die verschiedenen Werte auswirkt.
Ich warte immernoch auf deine Begründung.

Ich sprach gar nicht vom Opteron, sondern von zukünftigen Mainstream-Designs. Bei Server/HPC/Workstation-CPUs kann man sich sowas scheinbar leisten. Im Massenmarkt halte ich das für nicht sehr wahrscheinlich. Im Massenmarkt können hohe Entwicklungskosten auch durch die schiere Menge an CPUs wieder hereingeholt werden, bei kleineren Mengen an extrem teuren CPUs ist es schon eher relevant, mal ein paar Millionenbeträge bei R&D einzusparen. :
jetzt plötzlich sprichst du nicht vom Opteron, aber zukünftigen mainstream-designs?
naja, das sind auch x86. Also?


Du hast mein Posting wirklich gelesen?

hast du wirklich verstanden was ich sagen wollte? Scheint mir nicht so, denn du hast die Sache mit den Decodern ja schön vernachlässigt.
Kannst dich ja mal schlau machen, wie gut sich Doubles mit 2 Threads in den Pipes vertragen.


Die Bedeutung dieser Adjektive ist dir sicher geläufig, die brauch' ich nicht zu erläutern denke ich.

Deren bedeutung durchaus, deine Verwendung dieser ist allerdings ... interessant.

[BlackBirdSR]

Davon habe ich nie gesprochen. Liest keiner meine Postings? Ich sprach nur davon, dass ich CMP nach dieser Bauweise für nicht sonderlich effizient halte und dass z. B. mittels SMT die klassische steigende Paralellisierung im Kern ungebremst weitergehen kann, ohne die Effizienznachteile, die solche einfachen CMPs mit sich bringen. Das ist nur eine Idee von mir, was man sonst machen könnte, um den Platz effizienter auszunutzen. Im Markt des Opteron ist der Die-Platzverbrauch aber nicht so wichtig, R&D-Kosten in der Evolution sind scheinbar wichtiger, siehe auch Itanic, äh Itanium, der sich mehr durch immer größere Caches auszeichnet als durch ausgefeiltere Kerne.

ungebremst weitergehen?

Ich weiss gar nicht mehr was ich noch antworten soll.
Bist du Endo, oder einer dieser Gäste die einfach so mit Ausdrücken um sich werfen.
Ich bin mir nicht mehr sicher.

[Gast]

Info:
http://www.amd.com/us-en/assets/content_type/styleone/roadmap_072704.gif

==> Toledo =)

up

[HellHorse]

Ja klar, und wenn Intel die Cache Grösse verdoppelt spricht niemand von Irrsinn, unglaublicher Verschwendung an Diefläche für einen kleinen realen Performancegewinn.

[BlackBirdSR]

Ja klar, und wenn Intel die Cache Grösse verdoppelt spricht niemand von Irrsinn, unglaublicher Verschwendung an Diefläche für einen kleinen realen Performancegewinn.

Wenn man etwas tiefer blickt, ist das gar nicht mehr so unglaublich.
SRAM ist wesentlich einfacher zu handhaben als ein Extra an Logik.
Es ist einfach zu bewerkstelligen, billig in vielen Hinsichten und erhöht Leck und Lastströme nur in geringen Mengen.

Mehr Logik heisst größere CPU Kerne. Neben all den Problemen in der Fertigung, gibt es eine Fülle von elektrischen Faktoren.
Obendrauf ist eine größere DIE durch Logik anfälliger für Fehler.
Redundanz gibt es nur bei Caches. Größere DIEs durch mehr Cache sind einfacher zu fertigen.

Wenn man dann noch Performance dafür bekommt, ist es quasi das perfekte Mittel. Es erscheint plump, einfallslos und verschwenderisch. Dabei ist es einer der letzten Wege um die Performance kostengünstig zu erhöhen.

[Haarmann]

HellHorse

Fragt sich ja, was effizienter ist...
2 Cores und 2 mal 1MB Cache oder 2MB Cache und ein Core ...

Ich setze auf die 2 Cores.

[Gandharva]

HellHorse

Fragt sich ja, was effizienter ist...
2 Cores und 2 mal 1MB Cache oder 2MB Cache und ein Core ...

Ich setze auf die 2 Cores.

mir wären 2 cores die sich 2mb cache teilen lieber. wäre doch am effizientesten, sofern man die gemeinsame nutzung des caches, zu implemetieren in der lage ist.

soll das beim Paxville nicht der falls sein?


dabei soll es sich um 2 p4 kerne auf einem chip handeln, die den gemeinsamen bus just so wie externe prozessoren doppelt belasten.


und wie ist obige aussage bezüglich Paxville zu verstehen? ist das dann eine cpu mit 2 kernen die je HTT implemetiert haben?

[StefanV]

mir wären 2 cores die sich 2mb cache teilen lieber. wäre doch am effizientesten, sofern man die gemeinsame nutzung des caches, zu implemetieren in der lage ist.

Bei 2x1MB hast du kein thrashing Problem

Von der Effizienz dürfte beides ähnlich sein...

[HellHorse]

Wenn man etwas tiefer blickt, ist das gar nicht mehr so unglaublich.
SRAM ist wesentlich einfacher zu handhaben als ein Extra an Logik.
Es ist einfach zu bewerkstelligen, billig in vielen Hinsichten und erhöht Leck und Lastströme nur in geringen Mengen.

Es ging mir nicht um die Kosten sondern um die hier oft zitierte "Flächeneffizienz".

Beispiel Prescott:
Die ganze CPU hat wesentlich mehr Transistoren, eine praktisch unveränderte pro-MHz Leistung, lässt sich nicht siginifikant höher takten und hat trotz fortschrittlicherem Produktionsprozess eine höhere Leistungsaufnahme. Hier spricht man allerdings nicht von Verschwendung und Irrsinn.

[BlackBirdSR]

Es ging mir nicht um die Kosten sondern um die hier oft zitierte "Flächeneffizienz".



Es geht am Ende nur um die Kosten.
Und wenn die (unwahrscheinlicherweise) DIE 5x so groß ist, aber die Kosten nur halb so hoch wie jetzt, dann ist das prima.

[Muh-sagt-die-Kuh]

Bei 2x1MB hast du kein thrashing ProblemThrashing Probleme hast du bei einem gesharten Cache auch nicht, er muss nur ausreichend groß sein und sollte eine hohe Assoziativität haben.

[Haarmann]

Muh-sagt-die-Kuh

Das Problem dürfte sein, dass ein gesharter Cache komplizierter zu implementieren ist auch ohne Trashing an sich. Der muss ja auch jeweils 2 Anfragen bearbeiten können und nicht nur eine.

[CrazyIvan]

@ Haarmann

Das ist wohl immer der Fall, wenn man statt Brute Fore eben Intelligenz einsezten will. Die Vorteile sind allerdings nett von der Hand zu weisen.

[Sunrise]

Es ging mir nicht um die Kosten sondern um die hier oft zitierte "Flächeneffizienz".

Beispiel Prescott:
Die ganze CPU hat wesentlich mehr Transistoren, eine praktisch unveränderte pro-MHz Leistung, lässt sich nicht siginifikant höher takten und hat trotz fortschrittlicherem Produktionsprozess eine höhere Leistungsaufnahme. Hier spricht man allerdings nicht von Verschwendung und Irrsinn.
"Verschwendung" und "Irrsinn" sind bei dem Thema lediglich Reizwörter, denn sie sind im Sinne von DIE-Fläche abhängig von Design und wirtschaftlichen Faktoren. Wenn dadurch primär die Margen nicht leiden, macht sich plötzlich kaum einer Gedanken mehr über ein eigentlich recht "ineffizientes" Design. Dieses Ziel hat Intel bei 90nm bereits mit 80-90% der Produktion erreicht. Am Ende wird dann aus "Verschwendung" und "Irrsinn" plötzlich "eine Clevere Möglichkeit weiterhin kostengünstig zu produzieren und die Leistung ein paar Prozent nach oben zu schrauben ohne dabei einen sonderlich hohen Mehraufwand zu haben und Nachteile im Wärme-Haushalt der CPU zu riskieren".

[GloomY]

mir wären 2 cores die sich 2mb cache teilen lieber. wäre doch am effizientesten, sofern man die gemeinsame nutzung des caches, zu implemetieren in der lage ist.Okay, lass uns das mal durchdenken: Du musst den L2 auf jeden Fall mit zwei Ports ausstatten, um einen gleichzeitigen Zugriff von beiden Cores zu ermöglichen. Das kann man über Multi-Bank Caches erreichen (so wie das beim L1-D Cache des Athlons der Fall ist), was aber entsprechend mehr Logik für die einzelnen Banks und die zusätzlichen Multiplexer bedeutet. => Cache-Komplexität nimmt zu.
(Zusätzlich dazu kannst du nicht garantieren, dass beide Cores nicht ab und zu auch mal auf die gleiche Bank zugreifen, wonach für diese Fälle der Dual-Port Cache zu einem Single-Port Cache wird, d.h. ein Prozessor muss warten. Das ist bei getrennten Caches nie der Fall.)

Du musst den L2 höher assotiativ machen, um das gestiegene Konfliktpotential durch zwei Threads, die sich um die Sets streiten können, entgegenzutreten. Höhere Assotiativität bedeutet mehr Tag-Vergleicher und mehr Bits für den Tag. => Cache-Komplexität nimmt zu. Zusätzlich dazu könnte die Zugriffszeit noch leicht ansteigen.

Zum Glück muss man bei einem physikalisch indiziertem Cache bei einem Miss nicht auch noch nach Aliases suchen wie bei einem virtuell indiziertem Cache. Dieses Durchsuchen wird mit steigender Assotiativität immer aufwändiger, weil man mehr Tags pro Set checken muss. Leider muss man beim Snoopen in einem Mehrprozessorsystem aber genau das tun, nämlich ein komplettes Set durchsuchen. Um dies nicht zu verlangsamen, muss man zusätzliche Hardware einbauen, die das parallel machen kann => Cache-Komplexität nimmt zu.

Das Routing der einzelnen Datenpfade der einzelnen Bänke sowie der Datenpfade der beiden Ports ist ein nicht zu vernachlässigender Faktor beim Entwurf. Das macht einiges an Arbeit.
Das Layout für einen Cache mit zwei Datenpfaden (für 2 Ports) kann längere Signallaufzeiten als bei zwei getrennten Caches bedeuten, weil man diese einzeln besser so auf dem Die plazieren kann, dass sie näher an den für sie jeweils kritischen Stellen liegen. Das kann die Zugriffszeit negativ beinflussen.


Es sollte klar sein, dass ein gemeinsamer Cache deutlich komplexer wird als zwei getrennte. Nicht nur, dass man einiges an Transistoren mehr für den Logikaufwandt reinstecken muss, die Zugriffszeit könnte ebenso darunter leiden wie der Aufwandt für den Entwurf.

[mrdigital]

Das sehe ich eigentlich genau so. Cachegrösse macht fertigungstechnisch und entwicklungstechnisch keine Probleme, es ist relativ billig, "einfach" den Cache zu verdoppeln. Es ist, wie BBSR hier schön ausgeführt hat wesentlich unkritischer, den Cache zu vergrössern. Daher sehe ich keinen Sinn darin, das sich zwei Cores einen L2 Cache teilen.


Wenn man etwas tiefer blickt, ist das gar nicht mehr so unglaublich.
SRAM ist wesentlich einfacher zu handhaben als ein Extra an Logik.
Es ist einfach zu bewerkstelligen, billig in vielen Hinsichten und erhöht Leck und Lastströme nur in geringen Mengen.

Mehr Logik heisst größere CPU Kerne. Neben all den Problemen in der Fertigung, gibt es eine Fülle von elektrischen Faktoren.
Obendrauf ist eine größere DIE durch Logik anfälliger für Fehler.
Redundanz gibt es nur bei Caches. Größere DIEs durch mehr Cache sind einfacher zu fertigen.

Wenn man dann noch Performance dafür bekommt, ist es quasi das perfekte Mittel. Es erscheint plump, einfallslos und verschwenderisch. Dabei ist es einer der letzten Wege um die Performance kostengünstig zu erhöhen.

[Gast]

Die Sache mit dem Cache ist sicherlich komplizierter als viele hier meinen =)
Gerade der 2nd-LC ist, seit er auf dem die, ist Ausfallfaktor Nr.1!
Gerade hat Intel damit jede Menge Stress beim Prescott.
Allerdings ist AMD ja, wie Intel, auch ein Cache-Spezialist und vielleicht hat AMD die clevere Lösung?

up

[Tigerchen]

Davon habe ich nie gesprochen. Liest keiner meine Postings? Ich sprach nur davon, dass ich CMP nach dieser Bauweise für nicht sonderlich effizient halte und dass z. B. mittels SMT die klassische steigende Paralellisierung im Kern ungebremst weitergehen kann, ohne die Effizienznachteile, die solche einfachen CMPs mit sich bringen. Das ist nur eine Idee von mir, was man sonst machen könnte, um den Platz effizienter auszunutzen. Im Markt des Opteron ist der Die-Platzverbrauch aber nicht so wichtig, R&D-Kosten in der Evolution sind scheinbar wichtiger, siehe auch Itanic, äh Itanium, der sich mehr durch immer größere Caches auszeichnet als durch ausgefeiltere Kerne.

Der Abschnitt über SMT läßt tief blicken. Überhaupt ist dieses Posting sehr interessant. Sehe ich da die blanke Angst im blauen Lager?:rolleyes:

[BlackBirdSR]

Die Sache mit dem Cache ist sicherlich komplizierter als viele hier meinen =)
Gerade der 2nd-LC ist, seit er auf dem die, ist Ausfallfaktor Nr.1!
Gerade hat Intel damit jede Menge Stress beim Prescott.
Allerdings ist AMD ja, wie Intel, auch ein Cache-Spezialist und vielleicht hat AMD die clevere Lösung?

up

Gerade deshalb gibt es Redundante Subarrays beim Cache.
Die Fangen schonmal eine Menge ab.

Hauptausfallfaktor sollten SRAMs trotzdem nicht sein.
Da gibt es genug, komplexere Stellen im Chip bei denen Ausfälle auftreten können. Und ob das wirklich eines der großen Probleme beim Prescott ist?
Scheint mir nicht so, wenn man schon 2MB Modelle bringen will.

@Tigerchen:
Muss sowas sein?

[Gandharva]

danke für die ausführliche erklärung gloomy.

ich dachte mir eben, dass es einfacher wäre den gemeinsamen zugriff auf den cache zu implemtieren.
also, einfach so eine art steuerwerk welches den beiden ports vorgeschalten ist einzubaun, das regelt, welcher core welche im cache liegenden daten zu bearbeiten hat.

scheinbar ist die umsetzung aber wesentlich aufwendiger.

effizienter sollte das aber doch schon sein, wenn die arbeit von 2 kernen die "voneinander wissen" ausgeführt wird, als wie wenn diese nur stur nebeneinander herarbeiten!?

[BlackBirdSR]

effizienter sollte das aber doch schon sein, wenn die arbeit von 2 kernen die "voneinander wissen" ausgeführt wird, als wie wenn diese nur stur nebeneinander herarbeiten!?

Der K8 weiss, dass er 2 Kerne beherbergt. Und es ist ja Aufgabe des OS und der Programme Threads zu verteilen.
Stell es dir ganz grob wie ein SMP System vor.
2 CPUs, die sich einen FSB und eine NB teilen.
Hier halt auf einem Chip.

[Gandharva]

Der K8 weiss, dass er 2 Kerne beherbergt. Und es ist ja Aufgabe des OS und der Programme Threads zu verteilen.
Stell es dir ganz grob wie ein SMP System vor.
2 CPUs, die sich einen FSB und eine NB teilen.
Hier halt auf einem Chip.

schon klar. hab mich evtl. schlecht ausgedrückt. mit "voneinander wissen" meinte ich das gemeinsame bearbeiten des caches, welches durch eine art steuerwerk geregelt wird.

[BlackBirdSR]

schon klar. hab mich evtl. schlecht ausgedrückt. mit "voneinander wissen" meinte ich das gemeinsame bearbeiten des caches, welches durch eine art steuerwerk geregelt wird.

Das brauchst du auch bei eigenen Caches für jede CPU, sonst geht gar nichts.
Cache-Koherenz!


Beim K8 ist dafür das cHT Protokoll zuständig.
Irgendwo hab ich aufgeschnappt, dass das jetzt als DirectConnect im Umlauf sein soll.

[Gandharva]

Das brauchst du auch bei eigenen Caches für jede CPU, sonst geht gar nichts.
Cache-Koherenz!


ah, ok. dann ist da gar kein so großer leistungsmäßiger unterschied, ob ein gemeinsamer oder 2 getrennte caches verwendet werden. aber der, dass 2 getrennte leichter zu implementieren sind. thx

wenn mir nun noch einer erklären könnte ob ich obiges zitat aus der c´t bezüglich Paxville richtig verstanden habe, dann bin ich vollends glücklich.

[GloomY]

danke für die ausführliche erklärung gloomy.

ich dachte mir eben, dass es einfacher wäre den gemeinsamen zugriff auf den cache zu implemtieren.
also, einfach so eine art steuerwerk welches den beiden ports vorgeschalten ist einzubaun, das regelt, welcher core welche im cache liegenden daten zu bearbeiten hat.Damit kannst du aber nicht gleichzeitig mit beiden Cores auf den Cache zugreifen.
scheinbar ist die umsetzung aber wesentlich aufwendiger.Es ist durchaus möglich einen gemeinsamen L2 zu verwenden, wie andere CPUs bereits gezeigt haben.

Ich denke, dass es auch einen Performanceschub bringen würde, wenn man statt 2x 1MiB L2 auf 1x 2MiB L2 umstellt und dabei alle notwendigen Änderungen berücksichtigt. Bloß muss man eben ein paar mehr Transistoren als bei 2 x 1MiB investieren und eine Menge Entwicklungszeit und Know-How reinstecken. Und gerade bei der Man-Power der Entwickler dürfte es AMD wohl fehlen. Also hat man sich für das einfachere Design entschieden.


Nochmal etwas anderes: Wenn man einen DualCore Opteron und ein 2x SMP Opteron System vergleicht, fällt auf, dass der DualCore Opteron nur noch die Hälfte der Speicherbandbreite besitzt. Was man aber auch nicht vergessen darf, ist dass der Zugriff auf den Speicher eines anderen Prozessors länger geht als vom eigenen aus. Die geschätzten 60 ns gegenüber ~100 ns bei einem externen Zugriff über HT stehen nun einheitliche 60 ns für beide Cores gegenüber. Man hat also effektiv Bandbreite gegen Latenz getauscht und wer mich kennt, der weiss bestimmt, dass mich das erfreut ;)

[BlackBirdSR]

Nochmal etwas anderes: Wenn man einen DualCore Opteron und ein 2x SMP Opteron System vergleicht, fällt auf, dass der DualCore Opteron nur noch die Hälfte der Speicherbandbreite besitzt. Was man aber auch nicht vergessen darf, ist dass der Zugriff auf den Speicher eines anderen Prozessors länger geht als vom eigenen aus. Die geschätzten 60 ns gegenüber ~100 ns bei einem externen Zugriff über HT stehen nun einheitliche 60 ns für beide Cores gegenüber. Man hat also effektiv Bandbreite gegen Latenz getauscht und wer mich kennt, der weiss bestimmt, dass mich das erfreut ;)

wofür AMD angeblich auch ca 10% geringere Leistung gegenüber einer SMP Variante angibt.
Bleibt abzuwarten wie sie das gemessen haben.

[CrazyIvan]

Das sehe ich eigentlich genau so. Cachegrösse macht fertigungstechnisch und entwicklungstechnisch keine Probleme, es ist relativ billig, "einfach" den Cache zu verdoppeln. Es ist, wie BBSR hier schön ausgeführt hat wesentlich unkritischer, den Cache zu vergrössern. Daher sehe ich keinen Sinn darin, das sich zwei Cores einen L2 Cache teilen.

Ich zumindest redete auch nicht davon, dass sich zum Beispiel zwei K8 Kerne 1MiB Cache teilen, sondern den gemeinsamen zugriff auf 2 MiB L2 statt 2 x 1 MiB L2. Und wer sagt, dass man den erhöhten Transistor Count bei Cache Verdopplung preislich verkraften kann, der wird doch bei geschätzten 5 - 20 % zusätzlich durch evtl. Logikschaltungen für Cache-Sharing nicht kneiffen wollen.

@ GloomY

Deine Ausführungen sind durchaus nachvollziehbar, aber warum hätte IBM ein Cache-Sharing integrieren sollen, wenn es mehr Nach- als Vorteile hätte? Die Frage ist nur, ob dies für den Massenmarkt relevant ist. Schließlich kostet ne Power5 so viel wie ein Einfamilienhaus und so teuer ist der K8 zum Glück noch nicht ;)

[Stone2001]

Beim K8 ist dafür das cHT Protokoll zuständig.
Irgendwo hab ich aufgeschnappt, dass das jetzt als DirectConnect im Umlauf sein soll.
Hast du zum Cache-Kohärenzprotokoll des K8 nähere Informationen?
Ich kenne nur das vom K7.

[StefanV]

@ GloomY

Deine Ausführungen sind durchaus nachvollziehbar, aber warum hätte IBM ein Cache-Sharing integrieren sollen, wenn es mehr Nach- als Vorteile hätte? Die Frage ist nur, ob dies für den Massenmarkt relevant ist. Schließlich kostet ne Power5 so viel wie ein Einfamilienhaus und so teuer ist der K8 zum Glück noch nicht ;)

a) hat IBM mehr Man Power
b) ist der Preis der CPU egal, beim Power5...

Denn soweit ich weiß, wird der Power5 auch noch in einem sehr teuren Herstellungsprozess gefertigt, was der genau macht, kann ich dir leider nicht sagen, hab ich leider 'verdrängt'.

Auf jeden Fall ist mit dem 'Power 5 Prozess' kein Consumer Prozessor möglich, da der in der Herstellung teurer wäre als manch ein Main Stream Prozessor aktuell ist...

[BlackBirdSR]

Hast du zum Cache-Kohärenzprotokoll des K8 nähere Informationen?
Ich kenne nur das vom K7.

Hypertransport an sich:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/HyperTransport_-_Chris_Neuts.pdf

cHT ist ein Teil davon.
Allerdings habe ich nichts was ins Detail geht,
Anscheinend ist das Protokoll an sich nicht in den Spezifikationen zu HT enthalten, sondern baut nur darauf auf. Wurde also von AMD selbst entwickelt.

[Muh-sagt-die-Kuh]

Hast du zum Cache-Kohärenzprotokoll des K8 nähere Informationen?
Ich kenne nur das vom K7.Der K8 verwendet das MOESI Cache-Kohärenzprotokoll, eine Erweiterung des klassischen MESI-Protokolls. Hans de Vries beschreibt es in diesem Artikel (http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#3.18) sehr ausführlich.

[Gast]

http://www.digitmag.co.uk/images/news/4383/amd-dual.jpg

The chips -- which contain two processor cores and 1MB of Level 2 cache for each core -- use the same 940-pin socket used by AMD's single-core Opteron processors manufactured with a 90-nanometer process, according to information posted on the AMD's Web site.



up

[Gast]

Tip:
http://www.computerbase.de/artikel/hardware/prozessoren/dual_core_athlon_64/

up

[Coda]

Also ich weiß ja nicht, aber in dem Computerbase Artikel steht schon ziemlich viel scheiße :|

[Botcruscher]

Hier dei Pläne von Intel

http://www.computerbase.de/news/hardware/prozessoren/intel/2004/august/intels_dualcore_ausblick_zukunft/

[BlackBirdSR]

Also ich weiß ja nicht, aber in dem Computerbase Artikel steht schon ziemlich viel scheiße :|

nicht einfach meckern, her damit!

[Gandharva]

Unter Umständen handelt es sich hierbei jedoch nur um eine leicht geschummelte Variante, denn möglicherweise müssen sich die beiden Recheneinheiten einen gemeinsamen L2-Cache teilen. Die Entwicklung einer Dual-Core-CPU mit einem gemeinsamen Cache ist im Vergleich zu der von AMD gewählten Lösung als komplizierter einzustufen, dankt dies jedoch durch einen geringeren Verwaltungsaufwand und arbeitet darüber hinaus effektiver.

schon werden meine wünsche erfüllt :D
aber was ist jetzt daran geschummelt? lt. gloomy soll das ja performanter sein. kommt aber wahrscheinlich auch darauf an, wie man es realisiert.

und irgendwie hoffe ich stark das intel auf den dothan setzt und nicht nochmal versucht den prescott zu verkleinern. wir haben ja bereits gesehen was dabei rauskommt.

[Coda]

Hier sind jedoch die Ausführungs-Einheiten (Execution Units) und Level-1-Data- und Instruction-Caches tatsachlich doppelt vorhanden
Gemeint ist HTT. Das ist absoluter Blödsinn.

[Gandharva]

Gemeint ist HTT. Das ist absoluter Blödsinn.

die meinen doch die power4 prozessoren und nicht htt. von htt ist im satz vorher die rede.

[BlackBirdSR]

Gemeint ist HTT. Das ist absoluter Blödsinn.

nein, gemeint ist CMP beim Power4(+)
Wurde wohl hier entnommen:

http://www-1.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4.html
" Included in what we are referring to as the processor are the various execution units and the split first level instruction and data caches. The two processors share a unified second level cache,"

Allerdings ist die Sache recht blöde ausgedrückt, indem hier SMT fast mit CMP verglichen wird, was natürlich falsch ist.
Nach dem text zu schließen, wird der Power4 von CB auch nicht als echte DualCore CPU angesehen :confused:

[Gast]

Es handelt sich ja um eine Vorschau bei ComputerBase:

Dual Core Athlon 64
Das kann die Hammer-Architektur

Autor:
Thomas Hübner
Veröffentlichung:
11. März 2004

trotzdem lesenswert =)

up

[Gandharva]

klingt imho ganz gut der amd artikel. wenn man die benchmarks mal 1:1 auf die ersten dual core amds ummünzt, kann dadurch die FPU leistung erheblich gesteigert werden und der rückstand im bereich multimedia zu intel verringert bis ausgeglichen werden.

wenn ich mir so ansehe wie dual core die FPU leistung steigert, wäre ein dual kern auf basis des dothans doch für intel das beste. geringere leistungsaufnahme, extrem hohe leistung im bereich multimedia und der rückstand des jetzigen dothan bei FPU berechnungen könnte aufgeholt werden. nicht zu vergessen die evtl. gemeinsame nutzung des caches, die nochmal leistung bringt.

wird ein spannendes jahr 2005.

[BlackBirdSR]

klingt imho ganz gut der amd artikel. wenn man die benchmarks mal 1:1 auf die ersten dual core amds ummünzt, kann dadurch die FPU leistung erheblich gesteigert werden und der rückstand im bereich multimedia zu intel verringert bis ausgeglichen werden.

wenn ich mir so ansehe wie dual core die FPU leistung steigert, wäre ein dual kern auf basis des dothans doch für intel das beste. geringere leistungsaufnahme, extrem hohe leistung im bereich multimedia und der rückstand des jetzigen dothan bei FPU berechnungen könnte aufgeholt werden. nicht zu vergessen die evtl. gemeinsame nutzung des caches, die nochmal leistung bringt.

wird ein spannendes jahr 2005.

ich sehe du basierst hier alles auf den SiSoft Sandra Benchmarks.
Tu dir den gefallen,vergiss das gleich wieder ;)
Sandra ist überhaupt nicht repräsentativ für echte Anwendungen.

[Gandharva]

ich sehe du basierst hier alles auf den SiSoft Sandra Benchmarks.
Tu dir den gefallen,vergiss das gleich wieder ;)
Sandra ist überhaupt nicht repräsentativ für echte Anwendungen.

inwiefern trifft denn deiner meinung nach meine obige spekulative aussage auf die reale anwendungsperformance zu?

[BlackBirdSR]

inwiefern trifft denn deiner meinung nach meine obige spekulative aussage auf die reale anwendungsperformance zu?

abwarten.
Je nach Programm wird sich was Anderes ergeben.

Wie die Sache mit den Abkömmlingen des Dothan aussieht, muss sich auch erst zeigen.

[Stone2001]

Der K8 verwendet das MOESI Cache-Kohärenzprotokoll, eine Erweiterung des klassischen MESI-Protokolls. Hans de Vries beschreibt es in diesem Artikel (http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#3.18) sehr ausführlich.
;) Also hat sich seit dem K7 nichts geändert! ;) Ich bin bisher auch davon ausgegangen, das es auch beim K8 verwendet wird, war mir dort aber nicht sicher.

[CrazyIvan]

Also wenn, dann sollte man die Leistungswerte eines Dual Core K8 schon eher mit denen nach NUMA Architektur vergleichen können und nicht mit denen, die sich den Speicher sharen. Ich würde schon davon ausgehen, dass man das ganze mit Dual Channel kombiniert - zumindest im Sockel 939. Beim 940er siehts damit wohl zwecks Abwärtskompatibilität vorerst anders aus.
Und wenn die Sandra Werte bei CB eins gezeigt haben, dann doch wohl, dass den beiden Opteronen ein bissl die Bandbreite ausgegangen ist. Auch die Latenz sollte um einiges besser sein, als bei dem dort benutzen SMP System.

[StefanV]

Ich würde schon davon ausgehen, dass man das ganze mit Dual Channel kombiniert - zumindest im Sockel 939. Beim 940er siehts damit wohl zwecks Abwärtskompatibilität vorerst anders aus.
Der öhm, der S940 hat doch auch ein DC Interface, nur mag er halt Unbuffered RAM nicht soo gerne...

[Gast]

http://www.amdzone.com/pics/cpus/dualcore/1stdemo/opt13090dualcore.jpg

Info:
http://www.amdzone.com/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=55&page=1

up

[GloomY]

http://www.amdzone.com/pics/cpus/dualcore/1stdemo/opt13090dualcore.jpg

Info:
http://www.amdzone.com/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=55&page=1

upJetzt das Ganze nochmal etwas ausführlicher:

http://www.amdzone.net/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=56&page=1

http://www.amdzone.net/pics/cpus/dualcore/1stdemo/dualcoreopt.jpg

[reunion]

Hm, warum besteht der Dual-Core Prozessor auch nur aus einem Die?
Ich dachte immer da werden einfach zwei Dies draufgepackt?!

//EDIT: ich finde es immerwieder erschreckend wieviel Platz AMD für den Cache benötigt, da geht fast der halbe Platz des gesamten Dies drauf, wenn man das mal meit dem Prescott vergleicht wird einem ganz übel. :D

http://www.amdzone.net/pics/cpus/dualcore/1stdemo/dualcore_hires_small.jpeg

[mrdigital]

Scheinbar macht diese hohe Integration kein Problem. Dazu kommt, dass man bei einer Die manche Einheiten gemeinsam nutzen kann. Auf dem BSB kann man das doch schön erkennen, dass der Memorycontroller und das HT Interface gemeinsam genutzt werden. Das liegt ja daran, dass der FSB des A64 nicht von aussen zugänglich ist. Die beiden Kerne in einem Package per HT verbinden hätte auch den Nachteil, dass man keine vierfach Systeme mehr bauen könnte, weil dann HT Links fehlen würden (jeder A64 Kern trägt ja 3 HT Links und in der 4er Konfiguration ist jeder Kern mit jedem verbunden, aber dann brauchts ja noch ne Verbindung zur Aussenwelt, also braucht man 3 HT Links)