Werden Intels Dualcore CPUs sich einen FSB teilen?

[mrdigital]

Weiss das einer? Teilen sich die beiden CPU Kerne einen gemeinsamen FSB (was eigentlich naheliegend wäre)?

[mrt]

Weiss das einer? Teilen sich die beiden CPU Kerne einen gemeinsamen FSB (was eigentlich naheliegend wäre)?

so weit ich weiß, ja. Was auch logisch ist, die kommen ja in den Sockel 775.

[mrdigital]

Wenn das so ist, weiss ich, welche Dualcore CPU die bessere sein wird ;D

[Savay]

hmm da der 775 von der pinbelegung umstrukturiert wird für die dualcore tippe ich mal glatt darauf das jeder core fast vollkommen separat an die NB angebunden wird...ergo jeder exklusiv die halbe busbreite abbekommt!

hmm ist die frage ob die cores dann auch untereinander per FSB ihre daten abgleichen... :confused:

das ganze würde sich dann ja eher wie nen klassischen SMP system verhalten! mit dem einzigen vorteil das es platz spart. :|

[Savay]

Wenn das so ist, weiss ich, welche Dualcore CPU die bessere sein wird ;D

warum? der DC A64 teilt sich auch 1 memcontroller und 1 HT port...

[mrdigital]

Natürlich wird sich das wie ein klassisches (Intel) SMP System verhalten. Mit all seinen Limitierungen und Nachteilen. EInzig für Intel bleibt der Kostenvorteil, dass es billiger ist zwei Kerne in ein Gehäuse zu packen als zwei vollwertige CPU zu bauen. Man erkauft sich diesen Kostenvorteil halt mit thermischen Limitierungen.

[Gaestle]

Aber kostet die "Doppelnutzung" des FSB nicht kräftig Speed?

Grüße

[mrdigital]

warum? der DC A64 teilt sich auch 1 memcontroller und 1 HT port...
Dafür kann ein Core mit der NB sprechen, ohne dass dies zu Lasten der Speicherbandbreite geht. Genau für diesen Fall hat AMD doch einen Crossbar Switch in die CPUs integriert. An dieser Crossbar sind 3x HT 2x64bit Memory und 1xCPU Core (bzw L2) angehängt
Bei Intel muss alles über den FSB.

[Savay]

das ist wohl wahr...aber auch bei heutigen AMD SMP systemen im gegensatz zu den intel pendants im grunde schon so

ich meinte eher bestimmte laufzeit limitierungen beim datenaustausch zwischen den caches und den cores! die wohl vorallem beim programmieren etwas haarig auswirken sollen wie ich mal gelesen habe... :confused:

wenn diese kommunikation über den FSB (ergo die northbridge!) geschieht ist das ja wesentlich ineffizienter als wenn die Cores direkt verbunden sind. wie es bei AMD der fall sein wird...

FALLS die intel dualcore das also wirklich tun verhalten sie sich im grunde exakt wie ein heutiges intel SMP system (ausser das der austausch gebremst wird durch den halbierten FSB)...

bei den AMDs dürften für diesen fall gewisse limitierungen wegfallen dadurch das die cores per crossbar untereinander und mit dem speicher verbunden sind!

wobei wohl auch die sich wie ein heutiges AMD SMP system verhalten dürften. da der crossbar ja quasi nen internen HT link darstellt...es bleibt aber trotzdem noch die schnellere kommunikation...

[mrdigital]

Aber kostet die "Doppelnutzung" des FSB nicht kräftig Speed?

Grüße
Ja sicher, deswegen skalieren Intel SMP Systeme auch nicht so schön mit der CPU Anzahl.
Als grober Wert:
2 CPUs --> 170%
4 CPUs --> 280%
Das sind zumindest meiner Erfahrung nach die Größenordnungen in denen sich das bewegt.

[mrt]

Dafür kann ein Core mit der NB sprechen, ohne dass dies zu Lasten der Speicherbandbreite geht. Genau für diesen Fall hat AMD doch einen Crossbar Switch in die CPUs integriert. An dieser Crossbar sind 3x HT 2x64bit Memory und 1xCPU Core (bzw L2) angehängt
Bei Intel muss alles über den FSB.

Der DC A64 hat nur einen HT-Link und der Memcontroller kann auch nur jeweils von einer CPU gleichzeitig verwendet werden. Ich sehe den Vorteil eher in den kürzeren Latenzen im Vergleich zur Intel'schen Lösung.

[mrdigital]

...
da der crossbar ja quasi nen internen HT link darstellt...es bleibt aber trotzdem noch die schnellere kommunikation...
Ich denke, dass AMD nichts anderes macht, als zwei Opteronkerne auf einem DIE zu fertigen. Die beiden Kerne sollten dann via HT miteinander sprechen, zumindest würde sich das anbieten, da man so den Entwicklungsaufwand in grenzen halten kann

[Coda]

Naja, das wird bestimmt für die Daten so sein, aber der Speichercontroller muss ja auch geteilt werden, das geht über HT nur schlecht. (außer das ist eine Master/Slave Konfiguration, was ich nicht glaube)

[Savay]

dann hätte man aber 1 master und 1 slave core...da man dann 1 der memcontroller ausschalten müsste, wäre 1 core gezwungenermaßen priorisiert (in dem sich der controller und der "externe" HT-link befindet) und weißt dem anderen dann daten zu...

afaik sollen sie sich aber einen gemeinsamen memcontroller und HT-link teilen!


edit: oops... zu langsam :biggrin:

[mrdigital]

Naja, das wird bestimmt für die Daten so sein, aber der Speichercontroller muss ja auch geteilt werden, das geht über HT nur schlecht. (außer das ist eine Master/Slave Konfiguration, was ich nicht glaube)
Das machen aber viele Opteronboards momentan. Eine CPU hat keinen eigenen Speicher und holt die Daten via HT von der anderen CPU. Nicht optimal, aber immer noch besser als das FSB-sharing von Intel.

[StefanV]

das ist wohl wahr...aber auch bei heutigen AMD SMP systemen im gegensatz zu den intel pendants im grunde schon so

Öhm, AMD SMP Systeme haben nie einen FSB geshart ;)

Der AMD-760MP(X) steuert jede CPU mit einem eigenen FSB an, was auch der Grund ist, warum man keine VIA Chips genommen hat, wie bei alten P3 SMP Systemen, wo prinzipiell jeder Chipsatz SMP fähig war...

[Bokill]

Der Dual-Core K 8 teilt sich schon vor der X-Bar die Datenströme. In der SRQ wird der I/O zwischen Kern 0 und Kern 1 geregelt. Erst dann kommt die Cross-Bar.

Die X-Bar ist die Schnittstelle für Hypertransport und dem Speicherkontroller. Von dort aus gehts ab zur SRQ ...

Siehe auch Diagramm K8 (http://www.planet3dnow.de/artikel/diverses/64bitpreview/images/hammer_core.png).

MFG Bokill

[mrdigital]

Bist du dir da sicher? Das wäre dann doch mehr Enwicklungsaufwand als beide CPUs via (internem) HT zu koppeln.

[Bokill]

Damit wurde der K8 von Anfang an entworfen. Das Problem hat AMD schon längst gelöst, was intel jetzt noch lösen muss. Das gilt für den Itanium genauso wie für den Xeon, die hängen noch an einem Bus, der sowohl Daten vom Chipsatzt wie auch Speicherdaten durch den Bus schicken muss.

Aber selbst AMD hatte da schon Vorgänger, den Alpha EV-7. Aber hier hatte der 21364 kein spezielles Protokoll, sondern der EV-7 hatte 4 gleichberechtigte Links (der EV-7 hatte auch integrierte Speicherkontroller).

MFG Bokill

[GloomY]

Öhm, AMD SMP Systeme haben nie einen FSB geshart ;)

Der AMD-760MP(X) steuert jede CPU mit einem eigenen FSB an, was auch der Grund ist, warum man keine VIA Chips genommen hat, wie bei alten P3 SMP Systemen, wo prinzipiell jeder Chipsatz SMP fähig war...Das ist beim K7 kein "Bus", so wie es der Name FSB (Front-Side-"Bus") andeutet. Beim K7 hat jede CPU eine einzelne Punkt-zu-Punkt Verbindung zur Northbridge. Jede dieser Punkt-zu-Punkt Verbindungen enthält 64 Datenleitungen, mindestens 30 Adressleitungen (36 Bit Adressierung abzüglich Bits für Cacheline-Größe; hier 6 Bits für 64 Byte Cacheline), ein paar Steuerleitungen und ein paar Leitungen, welche exklusiv zum Snoopen verwendet werden. D.h. dass die Snoop-Daten nicht mal über die üblichen Datenleitungen übertragen werden, wie das imho bei sämtlichen Xeons der Fall ist, sondern parallel zum Datentransfer stattfinden können. :massa:

Technisch gesehen ist die K7 Anbindung von Anno 2000 (sprich: EV6 Anbindung von 1998(!)) weit fortschrittlicher als Intels Chipsatz-Anbindung im Jahre 2005 oder 2006 sein wird! Vom Opteron mit integriertem Speichercontroller, zwei uni-direktionalen HT-Links pro Richtung usw. wollen wir lieber gar nicht reden...
Das Problem hat AMD schon längst gelöst, was intel jetzt noch lösen muss. Das gilt für den Itanium genauso wie für den Xeon, die hängen noch an einem Bus, der sowohl Daten vom Chipsatzt wie auch Speicherdaten durch den Bus schicken muss.Jep...

[Endorphine]

Ja, mit 98%iger Wahrscheinlichkeit werden sich die CMPs von Intel in der näheren Zukunft (also mindestens bis zum Presler/Dempsey) einen FSB zur Northbridge teilen. Und darüber wird dann jeglicher I/O der CPUs laufen.

Warum? Ganz einfach, schaut euch folgende Grafik an und denkt dabei daran, dass Nachteile einer Architektur einfach nicht besprochen werden und man -- so gut es geht -- versucht, einfach nicht darüber zu reden. Da ist eben keine Verbindung der CPUs zwischeneinander. Deshalb liegt es für Intel wohl auch so nahe, statt einem großen Kern lieber zwei kleinere auf einem Träger zu verbauen (know-how ist ja dazu seit dem PPro vorhanden).

Ich glaube, dass das wohl auch der Tribut ist an die kurze Zeit, in der Intel den Smithfield aus dem Boden gestampft hat. Intel fehlt eben eine Basis wie die HTr-Links bei AMD, um mal eben zwei CPU-Kerne untereinander zu verbinden, ohne die primäre I/O-Verbindung eines Kerns dafür zu missbrauchen.

http://images.anandtech.com/reviews/tradeshows/IDF/2005/Spring/Day1/Wrapup/ioatslide.jpg

Wobei ich das nicht als so furchtbar schlimm ansehe wie manche AMD-Verfechter. Die jetzigen Xeons haben ja das selbe "Problem". Die K8 SMP-Systeme haben das Problem der NUMA, was theoretisch die Speicherbandbreite linear mit jeder CPU skalieren lässt (so denn an jeder CPU auch Speicher hängt, was kein Zwang ist, siehe manche Tyan-Boards). Dafür muss die Software für optimale Performance auf NUMA Rücksicht nehmen. Und nicht nur das OS, sondern auch die Anwendungen. Meines Wissens nach gibt's noch nicht mal eine Schnittstelle, über die Software feststellen kann, auf welcher CPU welcher physikalische RAM angesprochen wird. Das mindert also auch die Effizienz. Es ist ja nicht umsonst so, dass 4-fach Opterons in (manchen/einigen/vielen? laut iX ist das jedenfalls kein Einzelfall) Benchmarks schon wieder weniger Durchsatz/Leistung bringen als 2-fach Systeme. Die Xeons haben halt den FSB als Flaschenhals. Beides ist suboptimal, wobei man natürlich (entsprechende SW-Schnittstellen vorausgesetzt) das NUMA-Problem umgehen kann, den FSB-Flaschenhals bei den Xeons kann man nicht durch Software "wegoptimieren". Momentan mindert aber beides unbarmherzig die Skalierung von SMP-Systemen. Bitte betrachtet nicht immer nur die eine Seite der Medaille.

p.s. Falls mein Beitrag etwas wirr ist -- ich mache gewisse alkoholische Getränke dafür verantwortlich. :redface:

[zeckensack]

FALLS die intel dualcore das also wirklich tun verhalten sie sich im grunde exakt wie ein heutiges intel SMP system (ausser das der austausch gebremst wird durch den halbierten FSB)...Der FSB war bei SMP ala Intel schon immer "halbiert", dh er wird und wurde zwischen den Prozessoren zeitbasiert dynamisch aufgeteilt.

[Coda]

Dafür muss die Software für optimale Performance auf NUMA Rücksicht nehmen. Und nicht nur das OS, sondern auch die Anwendungen.Wenn das OS davon weiß ist eigentlich schon das meiste getan.

[Botcruscher]

Also bei Intel nichts weiter als mehrere Cores auf einem Träger. Böse ausgedrückt eigentlich gar kein "Dualcore" sondern nur Multiprozessor.

Wie wird sich das auf die Geschwindichkeit auswirken?

[Bokill]

Eigentlich hat intel die Lösung sogar zweifach in der Schublade.

Zum einen kann intel ein frisiertes PCI-Express Protokoll für die Verschmelzung von der Xeon/Itaniumplattform nehmen (Sockelwechsel waren eh nie ein Problem).

Zum anderen hat intel die Patente von Alpha übernommen. EV-6, EV-7 sowie EV-8 sind jederzeit auch von intel möglich :D ... passt aber nicht so ganz mehr in die Zeit rein.

Meine Vermutung ist, dass intel ab 2007 eine vergleichbare Hypertransportlösung stricken wird, allerdings mit dem Unterschied von externen Speicherkontrollern.

Eine Systemverbindung ist konservativer und beständiger als ein Speicherbus ... auch wenn da FB-DIMM da die Aussicht bietet, dass auch der Speicher mal endlich einen robusteren seriellen Link bekommt ... falls da nicht doch noch DDR3 dazwischenfunkt (was aber technisch auch im FB-DIMM möglich sein könnte).

MFG Bokill

[Endorphine]

Also bei Intel nichts weiter als mehrere Cores auf einem Träger. Böse ausgedrückt eigentlich gar kein "Dualcore" sondern nur Multiprozessor.

Wie wird sich das auf die Geschwindichkeit auswirken? Lies' das verfügbare Xeon MP Material. :)

Es ist übrigens vollkommen egal, wie du es nennst. Es ist SMP. Punkt. SMP kann man auf verschiedene Arten ausführen. NUMA hat auch Nachteile und die CMPs von AMD werden sich auch anders verhalten als die MP-Opterons mit ihren eigenen Speichercontrollern. Das kann ein Vorteil ggü. NUMA werden (weil dann Xeon-optimierte Software u. U. besser läuft), oder auch ein Nachteil (die Bandbreiten-Skalierung mit der Wege-Anzahl fällt weg). Schaun 'mer mal.

Und da du ja immer wieder auf der Spiele-Eignung herumreitest: die CMPs werden Spielern in nächster Zeit wohl überhaupt nichts bringen. Das ist vielmehr eine Technik, die sich im produktiven Einsatz bezahlt macht in der nächsten Zeit und in der Lebenszeit der ersten Dual-Core Systeme.

[Windi]

Also bei Intel nichts weiter als mehrere Cores auf einem Träger. Böse ausgedrückt eigentlich gar kein "Dualcore" sondern nur Multiprozessor.

Wie wird sich das auf die Geschwindichkeit auswirken?
Hast dir ja eigentlich die Antwort schon selbst gegeben. Schau dir ein Xeon System mit 2 Prozessoren an und du weisst es.

PS: Ich denke gerade über ein Xeon System mit 4 Dual-Core Prozessoren nach. übel übel :rolleyes:

[Savay]

Der FSB war bei SMP ala Intel schon immer "halbiert", dh er wird und wurde zwischen den Prozessoren zeitbasiert dynamisch aufgeteilt.

interessant! das war mir nicht klar...dann müsste imm falle der dualcore aber eher sowas wie eine viertelung stattfinden...
gesetz dem fall das der LGA775 nicht genug pins über hat für 2 vollwertige busverbindungen! :conf:

naja vielleicht sind sie ja vollwertig angebunden...dann wär der intel dualcore quasi nur nen platz und kosten ersparniss ggü deren klassischen SMP setups!?

[Coda]

Warum vierteln? Halbieren ist schon richtig bei einer Dual Core CPU.
Und nein, LGA775 hat ganz sicher keine 2 Busse an den Pins, das ist alles zusätzliche Masse.

[Savay]

ach bus...jetzt...das sagt ja eigentlich alles! ich trottel ;D sind ja quasi parallel über die selben datenleitungen angebunden! ähm kay

[GloomY]

Ja, mit 98%iger Wahrscheinlichkeit werden sich die CMPs von Intel in der näheren Zukunft (also mindestens bis zum Presler/Dempsey) einen FSB zur Northbridge teilen. Und darüber wird dann jeglicher I/O der CPUs laufen.

Warum? Ganz einfach, schaut euch folgende Grafik an und denkt dabei daran, dass Nachteile einer Architektur einfach nicht besprochen werden und man -- so gut es geht -- versucht, einfach nicht darüber zu reden. Da ist eben keine Verbindung der CPUs zwischeneinander. Deshalb liegt es für Intel wohl auch so nahe, statt einem großen Kern lieber zwei kleinere auf einem Träger zu verbauen (know-how ist ja dazu seit dem PPro vorhanden).Wo liegt der Vorteil wenn man keine Verbindung zwischen den CPUs hat? Bei diesen besteht im Übrigen ein starker (d.h. Latenz- und Bandbreiten-kritischen) Drang zum direkten Informationsaustausch untereinander in Form von Snoop-Informationen für die Caches. Was liegt da näher als dies durch eine direkte und schnelle Verbindung zwischen den CPUs zu realisieren?
Intel fehlt eben eine Basis wie die HTr-Links bei AMD, um mal eben zwei CPU-Kerne untereinander zu verbinden, ohne die primäre I/O-Verbindung eines Kerns dafür zu missbrauchen.Warum kann Intel denn nicht das offene Hypertransport verwenden, so wie es zig andere Firmen auch tun? Wenn dies ein Patent von AMD wäre und somit eine Lizenzfrage entstünde, könnte ich das nachvollziehen. Aber so...?

Auf der anderen Seite gibt es doch so viele serielle High-Speed Interconnects auf dem Markt. Selbst wenn davon wirklich nichts direkt passt, warum entwirft Intel denn dann nicht selbst etwas? Hey, immerhin geht es hier um Intel (!)... ;)

edit: Aha (http://www.vr-zone.com/?i=1812&s=1). :)
Wobei ich das nicht als so furchtbar schlimm ansehe wie manche AMD-Verfechter. Die jetzigen Xeons haben ja das selbe "Problem". Die K8 SMP-Systeme haben das Problem der NUMA, was theoretisch die Speicherbandbreite linear mit jeder CPU skalieren lässt (so denn an jeder CPU auch Speicher hängt, was kein Zwang ist, siehe manche Tyan-Boards).

Dafür muss die Software für optimale Performance auf NUMA Rücksicht nehmen. Und nicht nur das OS, sondern auch die Anwendungen.In wie fern? Welchen Möglichkeiten der Einflussnahme hat eine Anwendung denn?
Imho ist das Sache des OSes, wo welche Pages physikalisch gelagert werden.
Meines Wissens nach gibt's noch nicht mal eine Schnittstelle, über die Software feststellen kann, auf welcher CPU welcher physikalische RAM angesprochen wird. Das mindert also auch die Effizienz.Imho muss das die Software gar nicht wissen.
Es ist ja nicht umsonst so, dass 4-fach Opterons in (manchen/einigen/vielen? laut iX ist das jedenfalls kein Einzelfall) Benchmarks schon wieder weniger Durchsatz/Leistung bringen als 2-fach Systeme.Ja, da erinnere ich mich auch ganz schwach daran. Kannst du meinem Gedächnis auf die Sprünge helfen und mir sagen, in welcher iX das war?
Die Xeons haben halt den FSB als Flaschenhals. Beides ist suboptimal, wobei man natürlich (entsprechende SW-Schnittstellen vorausgesetzt) das NUMA-Problem umgehen kann, den FSB-Flaschenhals bei den Xeons kann man nicht durch Software "wegoptimieren". Momentan mindert aber beides unbarmherzig die Skalierung von SMP-Systemen. Bitte betrachtet nicht immer nur die eine Seite der Medaille.cc-NUMA hat sicherlich auch Nachteile, aber ich würde mich hüten, zu behaupten, dass diese gleichgroß sind wie das Bus-"Problem" bei den Xeons.

[Coda]

Also mich hätte es gefreut wenn Intel den offenen Standard HT akzeptiert hätte, aber dafür sind sie wohl zu eitel, bzw würden AMD einen reichen Segen an HT kompatiblen Chips bescheren :rolleyes:

Aber irgendwie lustig wie Intel AMD grad alles nachbaut :D

[Ihr Benutzername:]

Wo liegt der Vorteil wenn man keine Verbindung zwischen den CPUs hat? Bei diesen besteht im Übrigen ein starker (d.h. Latenz- und Bandbreiten-kritischen) Drang zum direkten Informationsaustausch untereinander in Form von Snoop-Informationen für die Caches. Was liegt da näher als dies durch eine direkte und schnelle Verbindung zwischen den CPUs zu realisieren? Ich sage gar nicht, dass das irgendwie ein Vorteil wäre, alle Kommunikation über den FSB laufen zu lassen. :) Natürlich ist das ein Nachteil ggü. beispielsweise einem HTr-Link zwischen 2 Kernen zum Cache-schnüffeln oder wie beim Opteron für den Zugriff auf NUMA-Speicher anderer CPUs. Oder gar auf die I/O-Ressourcen. Da kann man es schon in Frage stellen, ob Opteron-SMP überhaupt noch SMP ist und nicht eher eine Mischform aus SMP und Master-Slave MP-Architektur, wenn der Link zum Chipsatz nur von einer CPU verwaltet wird. Oder von mehreren, wie beim nForce Professional. Warum kann Intel denn nicht das offene Hypertransport verwenden, so wie es zig andere Firmen auch tun? Wenn dies ein Patent von AMD wäre und somit eine Lizenzfrage entstünde, könnte ich das nachvollziehen. Aber so...? Die Frage kann ich dir nicht beantworten, ich arbeite nicht für Intel. Ich vermute aber, dass es einfach eine Zeitfrage war/ist. Und es ist (wieder Vermutung) wohl auch prima wirtschaftlich, die bestehende Xeon SMP-Technik erstmal weiterzunutzen. Ich finde es ehrlich gesagt gar nicht so schlimm, auch wenn ich die AMD-Fans verstehe, dass aus deren Sicht Intels Untergang unmittelbar bevorsteht, weil Smithfield und Presler einen technischen Nachteil ggü. den AMD-Dualcores haben. Bestehende Software ist auf SMP à la Xeon optimiert und skaliert auch so ordentlich. Und NUMA hat wie gesagt auch Skalierungsnachteile. Genau das sage ich ja schon die ganze Zeit - man sollte das nicht überbewerten und AMDs Weg wieder für das einzig Wahre erklären. Auch NUMA hat Nachteile und die Dualcores von AMD werden sich mit einem Speichercontroller für 2 Kerne auch wieder anders verhalten als die Opterons. Also warum so eine Aufruhr um nichts? Das Verhalten der Xeons ist bekannt. Aus meiner Sicht besteht viel mehr Diskussionsbedarf um die Dualcore-Modelle von AMD. Da wird sich nämlich im Gegensatz zu Intel demnächst etwas ändern, wenn ein Speichercontroller auf zwei K8-Kerne kommt. Ja, da erinnere ich mich auch ganz schwach daran. Kannst du meinem Gedächnis auf die Sprünge helfen und mir sagen, in welcher iX das war? Wenn meine alten Postings hier stimmen, dann müsste das die iX 12/2003 sein. Ich glaube, ich hatte dir den Artikel damals sogar eingescannt und gemailed afair. :)cc-NUMA hat sicherlich auch Nachteile, aber ich würde mich hüten, zu behaupten, dass diese gleichgroß sind wie das Bus-"Problem" bei den Xeons. Das kommt ganz auf die Software an. Ich denke nur, dass diese Kleinigkeit hier überzogen dargestellt wird. Eine Relativierung der Relevanz dieses Flaschenhalses ist imho notwendig. Relativierung ist wohl immer notwendig, wenn die Produkte einer Firma erstmal grundsätzlich "geil" und "leet" und die der anderen "böse" und "uncool" sind...

[Coda]

Bestehende Software ist auf SMP à la Xeon optimiert und skaliert auch so ordentlich.Mhm? Was soll das bedeuten? Die Bandbreitenprobleme bei >2 CPUs kann man schlecht wegoptimieren.

Und NUMA hat wie gesagt auch Skalierungsnachteile.Öh genaugenommen hat NUMA ala K8 nur Vorteile :rolleyes:

Wenn man den Speicherbereich nicht lokal hat, geht man halt über den HT zu der nächsten CPU, das dauert auch nicht länger als beim Xeon zum Chipsatz.

[HOT]

Mhm? Was soll das bedeuten? Die Bandbreitenprobleme bei >2 CPUs kann man schlecht wegoptimieren.

Öh genaugenommen hat NUMA ala K8 nur Vorteile :rolleyes:

Wenn man den Speicherbereich nicht lokal hat, geht man halt über den HT zu der nächsten CPU, das dauert auch nicht länger als beim Xeon zum Chipsatz.

Es gibt sicherlich Fälle, in denen mehrere CPUs etwas gleichzeitig über einen HT Link schicken möchten. Ich könnt mir vorstellen, dass sich das bei Quadsystemen negativ auswirken kann, vor allem, da dann ohne Optimierungen die Chance steigt, dass ein HT Link genutzt werden muss und nicht der eigene Speichercontroller. Jede weitere CPU vergrössert diese Chance, bei 8 CPUs müsste man teilweise über 2 Controller hoppen. Das wird dann böse. Trotz dieser Nachteile ist ein solches Quad System immernoch wesentlich effizienter als ein geviertelter Bus. Es bedeutet ja auch einen wesentlich höheren Implementierungsaufwand für einen Platinenhersteller, da sehr viel mehr Leitungen verlegt werden müssen, die laufzeitkritisch sind.
Die Unterschiede in der Praxis können gewaltig sein, sobald man ein OS für NUMA optimiert. Das ist bisher aber nicht geschehen und ich habe so meine Zweifel, das das in naher Zukunft passieren wird.

[Coda]

Das wird dann böse.Das immer noch schneller als der Intel FSB iirc.

da sehr viel mehr Leitungen verlegt werden müssen, die laufzeitkritisch sindHT ist ein serielles Interface, da ist gar nix laufzeitkritisch.

[mrdigital]

iX 4/05 8 fach Opteronsysteme im Test, Seite 64ff.
Fazit :
"Für Anwendungen mit großem Speicherhunger und vielen gleichzeitig laufenden Prozessen bietet die D80z den richtigen Rahmen ... Zwar skaliert die Rechenleistung beim Verdoppeln des Quad-Packs (anm.: in diesem Server wurden zwei 4fach Boards via HT aneinander geklebt) nicht mehr linear mit der CPU-Anzahl, es entsteht ein Balast von 20% (anm.: 8 CPUs und nur 20% Verschnitt, also ca 1 CPU, das kann kein XEON System, ein XEON System "verliert" bei vier CPUs bereits mehr als eine CPU), trotzdem kommt insgesamt ein System heraus, das in der Klasse der 19" Server an der Spitze steht."

[mrdigital]

...
Es bedeutet ja auch einen wesentlich höheren Implementierungsaufwand für einen Platinenhersteller, da sehr viel mehr Leitungen verlegt werden müssen, die laufzeitkritisch sind.
...

HT ist eine Punkt zu Punkt Verbindung, dadurch ist sie nicht besonders timingkritisch. Vom Aufwand ist es also das selbe, ob man ein Dual oder Quad oder 8fach System aufbaut, mal von der benötigten Platinenfläche abgesehen.

[GloomY]

Ich sage gar nicht, dass das irgendwie ein Vorteil wäre, alle Kommunikation über den FSB laufen zu lassen. :) Natürlich ist das ein Nachteil ggü. beispielsweise einem HTr-Link zwischen 2 Kernen zum Cache-schnüffeln oder wie beim Opteron für den Zugriff auf NUMA-Speicher anderer CPUs. Oder gar auf die I/O-Ressourcen. Da kann man es schon in Frage stellen, ob Opteron-SMP überhaupt noch SMP ist und nicht eher eine Mischform aus SMP und Master-Slave MP-Architektur, wenn der Link zum Chipsatz nur von einer CPU verwaltet wird. Oder von mehreren, wie beim nForce Professional.Warum sollte es kein SMP sein? Wo I/O stattfindet, ist nicht ausschlaggebend.
Aber das ist natürlich alles eine Definitionsfrage...
Die Frage kann ich dir nicht beantworten, ich arbeite nicht für Intel. Ich vermute aber, dass es einfach eine Zeitfrage war/ist. Und es ist (wieder Vermutung) wohl auch prima wirtschaftlich, die bestehende Xeon SMP-Technik erstmal weiterzunutzen.Ich vermute, dass es ums Chipsatz-Geschäft geht. Dort verdient Intel auch nicht schlecht und eine Architektur, bei der der Speichercontroller in der CPU sitzt und auf offene I/O-Verbindungen setzt (offen im Sinne von frei zugängliche Standards ohne Lizenzgebühren), wird es Wettbewerbern wesentlich leichter machen als es jetzt der Fall ist.

Dass Intel so etwas nicht will ist verständlich. Es ändert aber nichts an der Notwendigkeit zu diesem Schritt hin, weil die alte Bus-Architektur einfach technisch unterlegen ist. Intel wird 2007 auch einen integrierten Speichercontroller anbieten. Früher oder später kommt niemand drum herum.
Ich finde es ehrlich gesagt gar nicht so schlimm, auch wenn ich die AMD-Fans verstehe, dass aus deren Sicht Intels Untergang unmittelbar bevorsteht, weil Smithfield und Presler einen technischen Nachteil ggü. den AMD-Dualcores haben.Es ist dann schlimm, wenn die SMPs nicht gut skalieren. Solange die Daten einigermaßen in den Caches liegen, geht es den Xeons (und Nachfolgern) ja noch ganz gut. Wenn aber extensiv der gemeinsame Bus benutzt wird, um Daten auszutauschen, wird es eng und dann zeigen sich eben Schwächen.

Intel versucht natürlich mit allen Mitteln diese Nachteile auszubügeln: SMT hilft als Latenz-versteckende Maßnahme und große Caches (4 MiB L3 bei Xeons, demnächst 8 MiB L3) helfen, dass man seltener in die Situation kommt, viele Daten über den Bus transportieren zu müssen. (Der Snoop-Traffik ist im Vergleich zum extensiven Datentraffic bei ständigen Cache Misses recht gering)

So lange obige Dinge einigermaßen helfen, können die Xeons noch recht gut skalieren. Bei speicherbandbreiten-limiterten Programmen (von denen es ja nicht wenige gibt; fast sämtliche wissenschaftliche Rechnungen wie Matrix-Matrix- oder Matrix-Vektor-Multiplikation, aber auch Multimedia) sieht's mit der Skalierung aber ziemlich schlecht aus. Dort zeigt sich einfach die Auswirkungen der Bus-Architektur (ich verkneife mir hier jetzt ein wertendes Adjektiv ;) ).
Bestehende Software ist auf SMP à la Xeon optimiert und skaliert auch so ordentlich."Ordentlich" im Sinne der Möglichkeiten eines Bus-basierten SMP-Rechners. Dort ist im Prinzip aber mehr möglich, wenn die CPUs besser an den Speicher angebunden wären.
Und NUMA hat wie gesagt auch Skalierungsnachteile. Genau das sage ich ja schon die ganze Zeit - man sollte das nicht überbewerten und AMDs Weg wieder für das einzig Wahre erklären.Der Test der iX, auf den du dich beziehst, ist (mittlerweile) relativ alt. Die neuen Messungen der iX (MrDigitals Post) zeigen ein anderes Bild.
Ich habe es damals nicht so recht glauben können, habe mir aber nicht anmaßen wollen, die Tests der iX anzufechten (z.B. dass 4 CPUs langsamer sein sollen als 2). Dass NUMA (hier besser cc-NUMA für cache-coherent NUMA) auch Nachteile hat, bestreite ich ja nicht, aber wie ich oben schon sagte, sollten wir nicht nur anschauen, ob Nachteile vorhanden sind, sondern wie groß diese sind. Und ich bin sicher, dass cc-NUMA im Allgemeinen besser skaliert als ein busbasierter SMP-Rechner.
Insofern ist cc-NUMA der bessere Weg. Und in dem Sinne (rein technisch betrachtet) ist es dann nunmal auch "das einzig Wahre" (von Warsteiner mal abgesehen :D).

Ich weiss, dass du das vielleicht nicht hören magst, aber so läuft es nunmal. Bei der technischen Wahl nimmt man die Lösung, welche am wenigsten Nachteile hat. Es hilft nichts, die Nachteile der einen Lösung hervorzuheben, wenn diese insgesamt besser geeignet ist, das Problem zu lösen. Dann muss man eben mit diesen Nachteilen leben, weil es nunmal die - bisher - beste Lösung ist. Wenn du eine noch bessere weisst, dann nur her damit. ;)
Dann würde das gleiche für cc-NUMA gelten und ich würde sagen: Hinfort damit. Solange das aber nicht eingetreten ist, bleibt cc-NUMA die bessere Wahl.
Auch NUMA hat Nachteile und die Dualcores von AMD werden sich mit einem Speichercontroller für 2 Kerne auch wieder anders verhalten als die Opterons. Also warum so eine Aufruhr um nichts? Das Verhalten der Xeons ist bekannt. Aus meiner Sicht besteht viel mehr Diskussionsbedarf um die Dualcore-Modelle von AMD. Da wird sich nämlich im Gegensatz zu Intel demnächst etwas ändern, wenn ein Speichercontroller auf zwei K8-Kerne kommt.Das ist korrekt. Was die Anbindung an den Speicher angeht, so hat ein ein-CPU Dual-Core Rechner gegenüber einer zwei-CPU single-Core Maschine einen Nachteil. Verglichen mit einer busbasierten SMP-Maschine (genauso: je zwei Cores auf einem Die, welche über einen Bus angebunden sind; konkret: Presler/Dempsey...) kann dieser Dual-Core aber Daten und Snoop-Informationen zwischen den beiden Cores mit extremer Geschwindigkeit austauschen. Unter dem Strich dürfte dies trotzdem wesentlich effektiver sein. Ich bin schon auf erste Benches gespannt :)Wenn meine alten Postings hier stimmen, dann müsste das die iX 12/2003 sein. Ich glaube, ich hatte dir den Artikel damals sogar eingescannt und gemailed afair. :)Du hast mir mal einen Artikel über SMP-Knoten in einem Cluster geschickt (iX irgendwas) und dann einmal über SMT beim P4 (aus C't). Den angesprochenen Artikel kann ich in meiner Mail-Box nicht mehr finden, aber ich erinnere mich auf jeden Fall inhaltlich an ihn. Vielleicht hab' ich ihn auch übersehen (oder doch in gedruckter Form noch irgendwo rumliegen). Nachdem du mir ja sagen konntest, in welcher Ausgabe dies stand, werde ich mal verstärkt danach Ausschau halten... =)
Das kommt ganz auf die Software an. Ich denke nur, dass diese Kleinigkeit hier überzogen dargestellt wird. Eine Relativierung der Relevanz dieses Flaschenhalses ist imho notwendig. Relativierung ist wohl immer notwendig, wenn die Produkte einer Firma erstmal grundsätzlich "geil" und "leet" und die der anderen "böse" und "uncool" sind...Ich hab' mich oben schon ausführlich zu den Flaschenhälsen geäußert.
Eines möchte ich aber noch zum Ausdruck bringen: Meine Motivation war und ist immer technischer Natur gewesen. Dass du mir jetzt Fan-Boy Gehabe vorwirfst, finde ich nicht ganz fair. :(

[Bokill]

Zudem Gloomy ja seine wahre Liebe in dem Avatar zeigt ... DEC mit dem Alpha. :D

Dass SUN übrigens nun definitiv den Xeon aus der Produktonslinie gecancelt hat, und dass Solaris 10 nativ auf der K8 Plattform entworfen wurde ist aber bekannt oder?

Mit Solaris 10 ist erstmals eine AMD CPU mit besagtem Link Hypertransport als Refenzplattform gewählt worden. Und Server/Workstsationumgebungen werden nicht beliebig schnell wie Unterhosen gewechselt ... Die Vorteile mit dem Link (statt Bus) scheint die Mannen um SUN begeistert haben.

MFG Bokill

[G@st]

hmmm.... durch die fsb limitierung könnte sich (bei den dualcores) endlich ein deutlicherer vorteil für die extreme-editions (mit fsb1066 und nicht fsb800) ergeben - oder?

[BlackBirdSR]

hmmm.... durch die fsb limitierung könnte sich (bei den dualcores) endlich ein deutlicherer vorteil für die extreme-editions (mit fsb1066 und nicht fsb800) ergeben - oder?

Laut Intel haben auch die Extreme Edition CPUs nur den FSB800

[HOT]

Laut Intel haben auch die Extreme Edition CPUs nur den FSB800

Warum eigentlich? Macht doch eigentlich keinen sinn, wenn es jetzt schon Plattformen gibt, die besseres können.

[alpha-centauri]

Weiss das einer? Teilen sich die beiden CPU Kerne einen gemeinsamen FSB (was eigentlich naheliegend wäre)?

hab ich mal auf der cebit nachgefragt. die haengen an einem FSB und "teilen" sich diesen. die extreme ann auf 1066er, manch aber nur auf 800er. zwischen den cores gibts keine kommunikation.

den dual-extreme hab ich mir auf der cebit mal vorfuehren lassen.

[jfguf]

warum steigert intel nicht einfach den FSB? FSB800 gibt es ja schon ewig und FSB1066 gerade mal bei den extreme´s.

technisch sollte heutzutage doch sogar FSB1200 drinnen sein, wenn ich mir so manche oc-ergebnisse anschau.

[mrdigital]

so einfach ist es leider nicht, den Bustakt kann man nicht "mal so" anheben, auch wenn das bei einigen OC Leuten klappt. Elektrisch ist das ein sehr empfindlicher Punkt und Intel tut gut daran, hier auf Nummer ganz sicher zu gehen.

[GloomY]

warum steigert intel nicht einfach den FSB? FSB800 gibt es ja schon ewig und FSB1066 gerade mal bei den extreme´s.

technisch sollte heutzutage doch sogar FSB1200 drinnen sein, wenn ich mir so manche oc-ergebnisse anschau.Bei den Systemen mit einer CPU ist das vielleicht sogar noch möglich.

Erstaunlicherweise haben die Xeon MPs (4 oder mehr CPUs) alle noch einen FSB von 100 MHz. Ich vermute mal, dass es mit steigender Anzahl an Busteilnehmern elektrisch schwieriger wird, die Signale innerhalb der Taktperiode an alle Teilnehmer zu schicken. Immerhin hängen diese Geräte ja alle an ein und den selben Leitungen.
Und gerade bei mehr Prozessoren ist es ja wichtig, dass man einen schnellen Bus hat, weil dieser hier den Flaschenhals darstellt.

[Bokill]

Das ist ja der Witz an seriellen Links ... sie sind robuster und skalieren offensichtlich leichter mit hohen Frequenzen.

Dank integrierten Speicherkontroller bei der K8 Plattform (und auf der Alpha EV-7) Plattform ist schlichtes aneinanderstecken der CPUs untereinander möglich geworden. Das spart dann auch wieder Verdrahtungsaufwand. Mit einem externen Speicherkontroller sähe es bei der K8 Plattform deutlich komplexer aus.

MFG Bokill.

[mrdigital]

Der Trick heisst "Skew", also der (zeitliche) Versatz, den ein Signal bei (verschiedenen) Empfängern hat. Die Signale haben eine endliche Ausbreitungsgeschwindikeit, daher erreicht ein Signal zwei unterschiedliche Empfänger zu unterschiedlichen Zeitpunkten (wenn die beiden Empfänger nicht exakt gleich weit vom Sender entfernt sind). Bei höherer Taktfrequenz bleibt weniger Toleranzzeit übrig und schon klappt es nicht mehr mit mehreren Empfängern.

[CrazyIvan]

@ mrdigital

Vielleicht verstehe ich Dich gerade falsch, aber ich sehe das vielmehr als ein Problem, statt eines Tricks.
"Dank" des Skews steigt also bei mehreren Prozessoren der Synchronisationsaufwand. Mit Erhöhung der Frequenz sinken die Toleranzen. Irgendwann steigen allerdings die Laufzeitunterschiede über die Zeit zwischen zwei Takten. Und genau an dieser Stelle ist dann Schluss mit Taktsteigerung.
Richtig so?

[mrdigital]

Der "Trick" war ironsich ;) Aber du hast mich trotzdem richtig verstanden, nur dass bei wesentlich weniger Versatz schon Schluss ist, d.h tskew muss nicht erst so gross werden wie eine Taktperiode. Es reichen meistens ca 10%, um die Funktionstüchtigkeit der Schaltung nicht mehr gewährleisten zu können

[Haarmann]

Eigentlich müsste ein DC A64 doch fast genau wie ein Dual "S754" System reagieren. DC A64 zu Dual Opteron müsste sich wohl in etwa wie ein 754er zu nem sonst identischen 940er oder 939er verhalten.

mrdigital

Paar Chaintech Boards lassen ne Skew Einstellung zu, damit die RAMs auch brav funzen bei tiefen Timings.