Dual-Core Prozessoren von AMD und Intel ein Schnellschuss?

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Über den kommenden Dual-Core Prozessor Toledo von AMD haben wir in den letzten Wochen bereits zur Genüge <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1092741550">berichtet</a>. Die Diskussion dazu hat auf Planet 3DNow! bereits im Oktober 2002 begonnen, als sich AMD Pressesprecher Jan Gütter auf einem <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1035412751">P3D-Themenabend</a> zu der Aussage <i>"die Architektur des "Hammer" ermöglicht mehrere CPUs auf einem Die. Mehr kann ich dazu im Moment nicht sagen"</i> hinreissen ließ. Zwar wurde die Möglichkeit dazu auch vorher schon im Forum hitzig diskutiert, allerdings basierte das noch vagen Theorien.

Knapp zwei Jahre ist das nun her und man darf davon ausgehen, dass die Entwicklung bereits deutlich früher begonnen hat, schließlich wurde der K8-Kern mit seinen HT-Links bereits in der Konzept-Phase darauf ausgelegt, auch mehrere CPU-Cores auf einem Die verwalten zu können. Kürzlich nun hat AMD den inzwischen mit dem Codenamen Toledo versehenen Dual-Core Prozessor für 2005 <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1083234877">angekündigt</a>. Gleichzeitig will auch Intel mit dem Itanium-Prozessor nicht zurückstehen und ebenfalls Dual-Core Versionen anbieten. IBMs Power4 dagegen befindet sich bereits auf dem Markt.

Trotz der langen Vorlaufzeit und der Möglichkeit, auf bestehende Kerne zurückgreifen zu können, zeichnet sich langsam ab, dass sowohl Intel, als auch AMD bei ihren Dual-Core Lösungen ein paar Abkürzungen genommen haben. So sollen laut <a href="http://www.zdnet.de/news/hardware/0,39023109,39125355,00.htm">ZDNet</a> beide Dual-Core CPUs ein eigenen Cache für jeden Core bekommen. Die schnellere, weil mit weniger Verwaltungsaufwand behaftete, Lösung wäre jedoch ein großer Cache für beide Kerne, da so die aufwändigen <a href="http://www.planet3dnow.de/artikel/diverses/doping/12.shtml">Koheränz-Schaltungen</a> entfallen könnten. IBM hat seinen Power4 mit diesem Layout versehen, während Intel und AMD bildlich gesprochen "einfach" zwei Single-Cores auf ein gemeinsames Die belichtet haben. "Unter Zeitdruck ist es der einfachste Weg für sie", meinte Kevin Krewell vom Microprocessor Report zu ZDNet.

Insbesondere beim AMD Toledo wird es generell interessant, wie AMD den Dual-Core realisieren wird, da es mit dem K8-Kern prinzipiell verschiedene Möglichkeiten zur Realisierung gibt. <ul>1. Die Ideallösung:
Zwei komplette Rechenwerke, die parallel zueinander arbeiten und über einen Cache und eine Anbindung mit der Außenwelt verbunden sind. Kommt scheinbar nicht zum Einsatz, da AMD sonst keine doppelten Caches benötigen würde</ul><ul>2. Die Notlösung:
Zwei Kerne (Recheneinheiten und Caches) arbeiten parallel und sind intern mit einem eigenen Bus, der mit Coretakt arbeitet (vgl. Bus zum L2-Cache) miteinander verbunden. Die Anbindung zur Außenwelt erfolgt über einen gemeinsamen HT-Linkverbund mit drei Links.

3. Die Schnellschußlösung:
Zwei komplette Opteron-Kerne wurden auf ein Die gepflanzt und über je einen HT-Link miteinander verbunden. Das ist ein Layout, wie wir es bei unserem diesjährigen <a href="http://www.planet3dnow.de/misc/010404/">Aprilscherz</a> gezeigt haben. Diese Lösung ist zwar die am schnellsten zu realisierende, aber eigentlich kein echter Dual-Core, sondern ein SMP-On-a-Chip-System. Nachteil: hoher Verwaltungsaufwand, niedrigere Geschwindigkeit, unnötigerweise mehrfach vorhandene Bauteile, größere teuerere Diefläche als nötig.</ul>Auf dem Microprocessor Forum im Oktober will AMD nähere Details zum Toledo bekannt geben. Dann werden wir wissen, für welche Lösung AMD sich entschieden hat...
 
Bei Intel ist das direkte aneinanderleimen zweier unabhängiger Kerne im Vergleich zum Xeon DP Design schon ein Vorteil, da jetzt nicht zwei CPU per langsamem CPU-Bus an einer Northbridge hängen, die die Kommunikation koordiniert.
Auch hat Intel ja die großen 300 mm Wafer und baut recht kompakte Caches (s. Prescott).
Ein Dual-Core Netburst (Nortwood-Shrink ?!) hätte wohl 200-250 mm2, ein Dual-Core Dothan (zzgl. x64) vielleicht 160-180 mm2. Alles wirtschaftlich machbar.

--------------------

zu AMD:


amdms_15.jpg


Quelle: http://www.planet3dnow.de/vbulletin/showthread.php3?s=&postid=1803775#post1803775

Dieses Schaltungsprinzip könnte bedeuten, daß z.B. CPU_0 zunächst im eigen Cache_0 Code sucht, dann (per SRQ) Cache_1 der CPU_1, später dann DRAM o. per HTr, wenn bei den Caches nicht erfolgreich.
Befinden sich Code/Datenbestandteile für die CPU_0 häufig im Cache_1, gibt es erhöhte Lazenzzeiten.

Meiner Meinung nach könnte eine doppelte Codehaltung in den beiden L2-Caches vermieden werden, wenn diese eben gezielt nur mit den für die jeweilige CPU relevanten Daten gefüllt werden.
Doppelt wären dann nur einige Daten in den L1 Caches, wohl bevorzugt Programmcode, oder ?

In Summe: wenig Notlösung bei AMD !


' != '

architektur.png
 
Original geschrieben von rkinet
amdms_15.jpg

Sollte es sich bei diesem Schaubild um ein authentisches handeln, so entspräche das in der Tat in etwa Lösung (2.) Meiner Meinung nach trotzdem nicht ideal, denn das von Dir beschriebene Szenario kann vielleicht bei zwei getrennten Tasks/Prozessen funktionieren, bei zwei Threads jedoch, Beispiel Video-Encoding, wo zwei Threads gemeinsam an einem Datenpool herumwerkeln, ist es kaum zu vermeiden, dass CPU0 zu einem guten Prozentsatz auf den Cache von CPU1 zugreifen muss und umgekehrt. :(
 
Zuletzt bearbeitet von einem Moderator:
Original geschrieben von Nero24
Sollte es sich bei diesem Schaubild um ein authentisches handeln, so entspräche das in der Tat in etwa Lösung (2.) Meiner Meinung nach trotzdem nicht ideal, denn das von Dir beschriebene Szenario kann vielleicht bei zwei getrennten Tasks/Prozessen funktionieren, bei zwei Threads jedoch, Beispiel Video-Encoding, wo zwei Threads gemeinsam an einem Datenpool herumwerkeln, ist es kaum zu vermeiden, dass CPU0 zu einem guten Prozenzsatz auf den Cache von CPU1 zugreifen muss und umgekehrt. :(
Authentisch dürfte es schon sein. Schließlich passt es auch zu den von AMD veröffentlichten diversen Papieren.

Bezüglich Effizienz dieser Geschichte zitiere ich mich mal aus dem von rkinet oben verlinkten Posting selbst:
Auch bei einer einzelnen multithreaded programmierten Anwendung wird es bei zig MB an Daten (z.B. Photoshop, DivX, Cinema 3D (Texturen usw.), Games) selten der Fall sein, daß größtenteils gleiche Daten in beiden Caches liegen.
Und selbst bei den identisch vorhandenen Daten sind nur jene für die Kohärenz-Geschichte (inkl. Cacheline-Updates usw.) kritisch, die verändert werden.
 
AMD ideal, oder nicht ?


Nun, AMD dürfte einige Benchmarks mit seinen Prototypen gefahren haben. Auch hatte man ja gut 2 Jahre Entwicklungszeit zur Verfügung, seit der jetzige Opterone bzgl. Schaltungstechnik fertiggestellt wurde - s. wohl 2002.
Also bei AMD kann's schon rein zeitlich keine 'Notlösung' gewesen sein, man hatte den Dual-Core ja schon ewig in der Planung.


Und AMD kippt ja lt. Roadmap komplett die Single-Core Opterone,
also kann ein Dual-Core kaum bzgl. einer Dual-CPU Lösung Nachteile aufweisen, oder ?
 
Es war doch eigentlich von vornherein klar in welcher Form die AMD Dualcores kommen werden, oder?
Warum fangen jetzt alle an darüber zu diskutieren?
Es werden wohl 2 fast komplette Cores werden, die über die SRQ miteinander verbunden sind.
Ein besseres Design werden wir wohl erst beim K9 finden.

MfG
 
Original geschrieben von rkinet
also kann ein Dual-Core kaum bzgl. einer Dual-CPU Lösung Nachteile aufweisen, oder ?
Abwarten! Ein Dual-Opteron-System verfügt insgesamt über 4 Speicherkanäle, ein Dual-Core Single-System nur über zwei, während der Rest relativ identisch ist. Ich sehe nicht, wo ein Dual-Core Opteron gegenüber einem Dual-Opteron System Vorteile haben soll außer beim Preis und dass man auf ein Dual-Mainboard zwei Dual-Core Opterone stecken kann und so 4-way Computing auf einem Dual-Board betreiben kann bzw 2-way Computing mit einem Single-Board (was wohl die interessanteste Variante sein dürfte).
 
Ich dachte, dass gerade eigener Speicher für jede CPU von Vorteil ist, da sich so die Speicherzugriffe nicht gegenseitig behindern.

Warum sollte das nicht auch für den Cache-Zugriff gelten?

Unterscheiden muss man sicherlich die beiden Anwendungsfälle
- beide CPUs arbeiten für eine Anwendung (Multithreaded)
- jede CPU rechnet für eine andere Anwendung

Im letzteren Fall würde ich klare Vorteile sehen, wenn jede CPU eigenen Cache hat.

Oder liege ich damit vollkommen falsch?

Bleibt die Frage, auf welchen Anwendungsfall man die Architektur optimieren soll.

Jonathan
 
Also ich hatte eigentlich angenommen, dass die Dual-CPU´s einen gemeinsammen Cache hätten, denn wo sollte sonst der Produktionsvorteil liegen? Der Ausschuß wird wohl durch das mehr an Transistoren nicht gerade sinken.
Technisch macht deshalb ein Dual-Core nur Sinn, wenn ich mir Vorteile durch mehr Rechenleistung ohne Nachteile durch kleinere Speicherbandbreite und mehr an Produktionsaufwand verschaffe.
Ich kann mich erinnern, dass vor einiger Zeit irgendwo die Rede war, dass zukünftige AMD-CPU´s (K9?) bei Mehrprozessorsystemen CPU-übergreifend auf Caches und sogar bei der Verteilung der Last auf die einzelnen Pipes Vorteile haben werden, da sie die Last selbstständig verwalten.
Wenn die Dual-Opterons einfach nur "zusammengebackene" normale Opterons wären, macht das, wie Nero schon sagt, wegen der kleineren Speicherbandbreite nicht unbedingt viel Sinn....
 
@Aslan
Der Sinn ist ganz einfach. AMD hat in der Entwicklung schon Dualcore vorgesehen. Die Entwicklung des Dual-Core K8 ist gleichsam for free.

Gegenfrage: Warum sollte AMD dann etwas völlig neues machen, wenn sie "gratis" die Dualcoremöglichkeit haben? Denn die SRQ war und ist von Anfang an drin, auch im Sempron.

@Nero24
Finde den Titel sehr unglücklich :(

Auch scheinbar ist falsch gewählt. Anscheinend ist das korrekte Wort.
Beispiele:
Wenn scheinbar Gefahr im Verzug ist, dann hat das Milchmädchen nur einen Albtraum gehabt (sie schläft ja harmlos im Bett).
Wenn sie von Blutunden gehetzt wird, dann ist anscheinend Gefahr im Verzug, auch wenn`s Herrchen sagt "die wollen nur (Zerreissmich? ) spielen"

MFG Bokill
 
Original geschrieben von Nero24
Abwarten! Ein Dual-Opteron-System verfügt insgesamt über 4 Speicherkanäle, ein Dual-Core Single-System nur über zwei, während der Rest relativ identisch ist.


Die vier Speicherkanäle bei einem Dual-CPU Opteron wurden ja bereits in der Vergangenheit gekürzt, bzw. bringen kaum Performanceschub, da der L2 vieles im Alltag abfedert.

Der max. doppelte Traffic trifft so auf ein Dual-RAM Design, daß noch Kapazität hat und wohl kaum dabei in die Knie geht.
Realistisch betrachtet, hat AMD beim Opteron den DRAM Zugriff übertrieben dimensioniert, s. auch S.754.
So waren ja ursprünglich Dual-CPU Systeme im Gespräch mit 2* 256k L2 und eben 2* Single-DRAM.

Der Dual-Core würde somit nur das üppige DRAM-Interface richtig auslasten.
 
@bokill

Einfach nur einen Dual-Core zu "basteln", ohne was davon zu haben, ist Sinnlos...
Ein Dual-Core in der Version mit Cache für jede CPU-Hälfte kostet im Endeffekt genauso viel Platz auf dem Wafer, wie zwei einzelne CPU´S, nur mit dem Risiko behaftet, dass eben eher was schief gehen kann. Doppelt so viele Transistoren heißt nun mal, doppelt so viele Fehlermöglichkeiten. Bei einem Dual-Core, wie ihn der Power-PC hat, sehe (verstehe) ich den Vorteil, sollte der AMD tatsächlich zwei eigenständige Caches haben, bleibt kein Vorteil, nur der Nachteil der höheren Fehlerwahrscheinlichkeit.
 
Es ist fertigungstechnisch kein riesiger Vorteil, aber es ist auch kein Nachteil.
Eine Dualcore CPU ist immernoch günstiger als 2 CPU's. Desweiteren ist die Infrastruktur (Single Boards) günstiger zu haben.

Der K8 ist AMD's erster Ansatz zu einer Dualcore CPU. Diese Version wurde auf einem relativ einfachen und dennoch effektivem Weg Weg realisiert. Im Gegensatz zu Intel hat AMD dennoch viele Vorteile durch HT und integriertes Speicherinterface.
Wer mehr will, muss eben warten. Eine neue Technik kommt nicht immer in der exklusivsten und besten Form daher.

MfG
 
Original geschrieben von Aslan
Einfach nur einen Dual-Core zu "basteln", ohne was davon zu haben, ist Sinnlos...


genau, weder beim Stromverbrauch, noch bei der Herstellung sichtbare Vorteile.
ok, man spart später beim Server-Design, denn ein Dual-Core benötigt nur 2 DRAM-Kanäle, statt sonst 4 bei Dual-CPU.

was auffällt ist, daß AMD ja durchgängig den Dual-Core in der Roadmap hat, also nicht nur eine High end Opteron 8xx und FX Reihe.
ok, AMD dürfte mal wieder schummeln, also wenn der letzte Single-Core vom Band läuft kündigt sich schon 65nm an, wo AMD Dual-Core fast als Zugabe mitproduzieren kann.


Meine Tip:
- Die beiden L2 verhalten sich in vielen Situation additiv, d.h. wirken fast wie 2* 2MB-L2 bei zwei getrennten CPUs. Sie wären dann Intels zukünftigen Standard Xeonen mit 2 MB-L2 gleichwertig beim L2.
- Das Dual-DRAM Interface wird kaum zusätzlich belastet.
 
@PuckPoltergeist

kann ich doch jetzt auch schon: Tyan 2875 ( und MSI,und, und...mehr fallen mir spontan nicht ein)
Und der Preisvorteil? Die CPU wird wohl kaum viel billiger werden, als zwei einzelne. Sollte es anders sein, werd` ich mich sehr freuen! Bleibt besten Falls der Vorteil eines billigeren Single-Mainboards und der alleine spielt bei einer so aufwändigen Rechenmaschine eigentlich nur noch bedingt eine Rolle.

Um nicht falsch verstanden zu werden: bin selbst AMD-Fan und habe privat keine Intel-Maschinen und auch die Entwicklung der Dual-CPU gefällt mir von der Idee her, nur sollte sie so kommen, wie es jetzt die Spatzen vom Dach pfeifen, ist meine Freude nicht mehr ganz so riesig, wie ürsprünglich. Aber vielleicht gibt`s ja mal eine K8-2 (....), die das dann hat, was ich dachte
 
Original geschrieben von Aslan
@PuckPoltergeist

kann ich doch jetzt auch schon: Tyan 2875 ( und MSI,und, und...mehr fallen mir spontan nicht ein)

Solche Boards sind teurer und aufwändiger als die single-Variante. Dazu dauern Speicherzugriffe des zweiten Prozessors länger als bei dualcore, weil bei ATX nicht genügend Platz ist, um der zweiten CPU eigene RAM-Riegel zu verpassen. Ich sehe da schon einen deutlichen Vorteil bei dualcore.
 
Original geschrieben von Aslan
Also ich hatte eigentlich angenommen, dass die Dual-CPU´s einen gemeinsammen Cache hätten, denn wo sollte sonst der Produktionsvorteil liegen? Der Ausschuß wird wohl durch das mehr an Transistoren nicht gerade sinken.
Technisch macht deshalb ein Dual-Core nur Sinn, wenn ich mir Vorteile durch mehr Rechenleistung ohne Nachteile durch kleinere Speicherbandbreite und mehr an Produktionsaufwand verschaffe.
...

Die Dual-Cores werden ja für ne ganze Weile der 500-2000$-Klasse vorbehalten bleiben, da darf das Die auch ruhig etwas größer sein, ohne gleich die Gewinne zu schmälern (dürfte bei reinen Produktionskosten so grob 10-20$ mehr ausmachen). Ausbeute sinkt natürlich etwas, aber man kann ja notfalls einen der Cores deaktivieren und die CPU als single-Version noch verkaufen.
Mit dem später anstehenden Schritt auf 65nm bei 300mm-Wafern wird das nicht mehr so wichtig sein, dann kann es auch für billigere Mainstream-CPUs der 100$-Klasse kommen.

Daß diese Version bis auf dem Preis nicht besser als ein jetziges Dual-Socket-System ist, ist klar; aber es kommt ja immer auf den Preis an (sonst würden sich die Leute ja nur mit Power5 und Itanium eindecken) - ein 4-fach-System zum Preis eines 2-Wege-Systems dürfte schon reizen, besonders, da man die "alten" (z.B. mit 244er Opterons) sehr einfach aufrüsten kann.

Im Endeffekt also deutliche Mehrleistung "für lau", bzw. vernachlässigbare Mehrkosten, für AMD und für die Kunden.

Original geschrieben von Jonathan
Ich dachte, dass gerade eigener Speicher für jede CPU von Vorteil ist, da sich so die Speicherzugriffe nicht gegenseitig behindern.

Warum sollte das nicht auch für den Cache-Zugriff gelten?
Beispiel mit 2 Leuten, die ein Puzzle gemeinsam zusammensetzen wollen: Sitzt jeder an einem eigenen Tisch und hat einen Teil der Puzzlestückchen vor sich, dann hat er zwar geringfügig schneller den Überblick, ob ein passendes Teil auf seinem Tisch liegt, weil ihn keiner beim Suchen stört, und kann es dann fix einbauen. Aber wenn er es nicht findet, muß er erst aufstehen, zum anderen Tisch rübergehen und seinen Kollegen fragen, damit der ihm das Teil gibt.

Wenn aber beide am selben Tisch sitzen, dann hat jeder den Überblick über alle Teile. Allerdings muß der Tisch dann breit genug sein, damit sich die beiden beim Wühlen nicht ins Gehege kommen. Wenn einer ein Teil nimmt, dann kann der andere das gerade nicht probieren, und wenn er es wieder hinlegt, müssen beide Ordnung halten, sonst findet keiner mehr was wieder.

->2. Lösung ist bei einem gut eingespielten Team etwas schneller als die erste, aber wenn das Team nicht funktioniert, dann bremst und blockiert es sich selbst extrem.


Übertragen auf CPU bedeutet das, daß AMD lieber den sicheren Weg geht, das Eistungsplus ist auch so groß genug. Mit dem K9 können sie das dann nochmal verbessern.
Vor allem werden die Dual-Cores ja auch hauptsächlich in Boards mit mehreren Sockeln enden, da sieht das OS eh nur 4 gleiche CPUs statt 2x2 und verteilt die Daten entsprechend gleichmäßig. Also nutzt es wenig, wenn Core0 superschnell auf die Daten von Core1 zugreifen kann, aber in 2/3 der Fälle sowieso per HT auf einen der beiden Cores des anderen Sockels zugreifen muß, bzw. sogar auf deren RAM.

Original geschrieben von rkinet
Bei Intel ist das direkte Aneinanderleimen zweier unabhängiger Kerne im Vergleich zum Xeon DP Design schon ein Vorteil, da jetzt nicht zwei CPU per langsamem CPU-Bus an einer Northbridge hängen, die die Kommunikation koordiniert.
Wieso? Die beiden Cores hängen doch weiterhin über einen Bus am Chipsatz, der seinerseits mit dem RAM kommuniziert.
Wobei das im ersten Schritt wirklich nur ein Aneinanderleimen ist, die CPU-Cores müssen trotzdem weiterhin selber um den Bus kämpfen. Erst in einem zweiten Schritt wird es eine dedizierte Logik geben, die sich um die Verteilung kümmert. Das läßt natürlich darauf schließen, daß die Dual-Core-Lösung etwas kurzfristiger entworfen wurde.
 
Zuletzt bearbeitet:
Dazu dauern Speicherzugriffe des zweiten Prozessors länger als bei dualcore

ähem... bist Du Dir da sicher? Wenn, dann wohl überhaupt nur wegen einer eventuell geringeren Latenz.
Interessant ist die Überlegung von rkinet. Sollte tatsächliche das Ding einen solchen "exklusive-Cache" haben, wäre dass aber allerdings dann eingentlich ja das ganze dann so, wie bei einem einzigen, gemeinsamen Cache!
 
Original geschrieben von Aslan
ähem... bist Du Dir da sicher? Wenn, dann wohl überhaupt nur wegen einer eventuell geringeren Latenz.

Ja bin ich. Bei der dualcore Variante würde ein Zugriff Core-SRQ-XBAR-Memorycontroller sein, bei zwei getrennten Prozessoren Core-SRQ-XBAR-HTr-HTr-XBAR-Memorycontroller.


Interessant ist die Überlegung von rkinet. Sollte tatsächliche das Ding einen solchen "exklusive-Cache" haben, wäre dass aber allerdings dann eingentlich ja das ganze dann so, wie bei einem einzigen, gemeinsamen Cache!

Nun wir werden sehen. Ich tippe im Moment doch eher auf die räumliche Zusammenlegung von zwei Prozessoren, unter Beibehaltung der bekannten Protokolle.
 
Original geschrieben von PuckPoltergeist
Ja bin ich. Bei der dualcore Variante würde ein Zugriff Core-SRQ-XBAR-Memorycontroller sein, bei zwei getrennten Prozessoren Core-SRQ-XBAR-HTr-HTr-XBAR-Memorycontroller

Wenn Du vom hier gezeigten Schaubild ausgehst, hast Du sicher recht. Aber ob das stimmt, werden wir wohl leider abwarten müssen.
 
Original geschrieben von Aslan
Original geschrieben von PuckPoltergeist
Ja bin ich. Bei der dualcore Variante würde ein Zugriff Core-SRQ-XBAR-Memorycontroller sein, bei zwei getrennten Prozessoren Core-SRQ-XBAR-HTr-HTr-XBAR-Memorycontroller

Wenn Du vom hier gezeigten Schaubild ausgehst, hast Du sicher recht. Aber ob das stimmt, werden wir wohl leider abwarten müssen.
Wie der Zugriff auf den RAM des anderen Sockels abläuft, ist ja klar, das passiert ja in der kaufbaren Realität seit anderthalb Jahren.
Und selbst wenn der Dual-Core unsinnigerweise so aufgebaut wäre wie im P3D-Aprilscherz, dann wäre das trotzdem noch geringfügig schneller, weil die Länge der Leitungen zwischen den Sockeln wegfällt (2mm statt 15cm).

btw, Aslan: Hat das einen bestimmten Grund, daß Du die QUOTE-Tags in Deinen Posts immer entfernst?
 
Original geschrieben von OBrian
Und selbst wenn der Dual-Core unsinnigerweise so aufgebaut wäre wie im P3D-Aprilscherz,

Also ich wäre schon fast bereit meinen Rechner darauf zu verwetten, daß dem nicht so ist. Da wäre ja die SRQ reichlich überflüssig.
 
Original geschrieben von OBrian
a)
Die Dual-Cores werden ja für ne ganze Weile der 500-2000$-Klasse vorbehalten bleiben ... aber man kann ja notfalls einen der Cores deaktivieren und die CPU als single-Version noch verkaufen.

Im Endeffekt also deutliche Mehrleistung "für lau", bzw. vernachlässigbare Mehrkosten, für AMD und für die Kunden.
-------

b)

(Xeon)

Wieso? Die beiden Cores hängen doch weiterhin über einen Bus am Chipsatz, der seinerseits mit dem RAM kommuniziert.
Wobei das im ersten Schritt wirklich nur ein Aneinanderleimen ist, die CPU-Cores müssen trotzdem weiterhin selber um den Bus kämpfen.


a)
nun, lt. AMD Roadmap wird Dual-Core flächig eingeführt, vom Opteron 1xx bis 8xx. Dies bedeutet bis Ende 2005, daß auch die low end Klasse in Dual-Core kommt.


b)
bisher gehts den CPUs noch schlechter. Über zwei getrennte Busse und eine Norbridge mit DRAM muß die CPU<>CPU Kommunikation/Synchronisation und der Datenzugriff erfolgen.
Zukünfig nur noch der Zugriff per einem Bus auf die Northbridge, CPU<>CPU erfolgt intern. Auch kann Intel dann die Chipsätze für Single-Core weiterverwenden undderen Infrastruktur nutzen für eine definitiv schnellere Technik.
Bei Intel gibts im Vergleich zum Xeon DP meiner Meinung nach einen deutlichen Performace-Schub, wenn auch alles deutlich unterhalb Opteron-Niveau bleiben wird.

Beim Mobil Dual-Core ist natürlich der Leistungsbedarf zu beachten. Ein Dual-Core mit shared 2MB-L2 spart eben 2 MB-L2 ein und einige Synchronisationsvorgänge.
 
Original geschrieben von rkinet
Beim Mobil Dual-Core ist natürlich der Leistungsbedarf zu beachten. Ein Dual-Core mit shared 2MB-L2 spart eben 2 MB-L2 ein und einige Synchronisationsvorgänge.

Da kommt dann wieder die Logik für die Arbitrierung dazu. Das dürfte wirklich nur dann sparen, wenn der Cache verkleinert wird.
 
Zurück
Oben Unten