Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?

Ähm...daher:
Gulftown hat 3 Kanäle und 12 virtuelle kerne, also 0,25 Kanäle pro Kern.
Istanbul/Thuban hat 2 Kanäle und 6 Kerne, also 0,33 Kanäle pro Kern. -> weniger Probleme beim Istanbul.

d.h. 6-Kerne DC gegen 12-Kerne TC
Also Kernzahl virtuell verdoppelt, Speicherkanäle aber "nur" um 50%, wenn ich mich recht erinnere, war 3 doch um 50% mehr als 2, oder?
d.h. einem Thread steht anteilig weniger Bandbreite zur Verfügung als beim Istanbul.

Eigentlich nur die Zusammenfassung dessen was ich 3 Zeilen darüber selbst ausgerechnet hab...
3 / 12 = 0,25
2 / 6 = 0,333
 
Ähm...daher:


d.h. 6-Kerne DC gegen 12-Kerne TC
Also Kernzahl virtuell verdoppelt, Speicherkanäle aber "nur" um 50%, wenn ich mich recht erinnere, war 3 doch um 50% mehr als 2, oder?
Achso, die 50% Unterschied beziehen sich auf Gulftown vs. Istanbul (?).

d.h. einem Thread steht anteilig weniger Bandbreite zur Verfügung als beim Istanbul.
Anteilig Wovon?
Du musst auch berücksichtigen das beim Istanbul der Thread "anteilig" gesehen öfters läuft als beim Gulftown HT, da der HT-Thread nur dann zum Zuge kommt, wenn der Partner-HT-Kern auf was warten muss. Daher folgere ich das beim Gulftown, unter der Berücksichtugung das sämtliche HT-Kerne belastet werden, die beanspruchte Speicherbandbreite niedriger ist, als bei einer CPU mit Nativen-Kernen.

Eigentlich nur die Zusammenfassung dessen was ich 3 Zeilen darüber selbst ausgerechnet hab...
3 / 12 = 0,25
2 / 6 = 0,333
Äpfel vs. Birnen ;)
 
Ich glaube aber bei AMD nicht daran, mMn entstehen die Probleme bei Intel v.a. aufgrund der kleinen L2 Caches. Dadurch wird der Uncoreteil inkl. L3 und IMC über Gebühr belastet.
Vergiss nicht, das AMD auch eine andere Cache Strategie nutzt, die Exklusive Implementierung könnt hier einige Vorteile bringen, da man so mehr Speicher 'effektiv' nutzen kann.

PS: wenn ihr von der c't 7/10, S144/5sprecht, da ist Win7 genutzt worden, sogar in der 64bit Version (Skandal, Benachteiligung von Intel!!!11) und Fedora 12, ebenfalls AMD64.
 
Zuletzt bearbeitet:
Du musst auch berücksichtigen das beim Istanbul der Thread "anteilig" gesehen öfters läuft als beim Gulftown HT, da der HT-Thread nur dann zum Zuge kommt, wenn der Partner-HT-Kern auf was warten muss.

Das ist falsch. Was du hier beschreibst ist SoEMT (Switch-on-Event Multithreading), die Nehalem Architektur verwendet jedoch SMT (Simultaneous Multithreading), beide Threads laufen vollkommen unabhängig zur gleichen Zeit und wissen nichts voneinander.
 
Das ist falsch. Was du hier beschreibst ist SoEMT (Switch-on-Event Multithreading), die Nehalem Architektur verwendet jedoch SMT (Simultaneous Multithreading), beide Threads laufen vollkommen unabhängig zur gleichen Zeit und wissen nichts voneinander.

Wo habe ich etwas anderes behauptet?

Beide HT-Threads haben NICHT ZUR GLEICHEN ZEIT sämtliche Ausführungseinheiten für sich, d.h. einer muss zwangsläufig warten. Im Optimalfall warten beide gleich lang.
 
Ja, denn sonst würde HT eine Leistungssteigerung von +100% bringen, ist aber nicht der Fall.
 
"warten müssen" ist zu krass ausgedrückt.
die threads warten zwangsweise mal... wenn z.B. grade Daten aus dem RAM nachgeladen werden müssen, werden die Recheneinheiten für ein paar Takte "frei"... und in dieser Zeit kommt der 2. Thread an die Reihe....
Es werden also hauptsächlich leerläufe verringert indem die Recheineheiten inzwischen was anderes zu tun bekommen.

@Twodee:
Ich bezog meine Argumentation auf die freche Unterstellung der C't dass der Istanbul zu wenig Speicherbandbreite bei Dual Channel haben könnte, nur weil Gulftown anscheinend durch sein Triplechannel limitiert wird.
Daher habe ich versucht aufzuzeigen, mal völlig abgesehen von Architektonischen Eigenheiten, Caches etc. dass Gulftown bei vollauslastung rein rechnerisch, jedem Thread (jedem virtuellen Kern) 0,25 Speicherkanäle zur Verfügung stellen kann, also ein zwölftel der gesamten 3 Speicherkanäle (und damit der Bandbreite) die einem einzelnen Thread zur Verfügung stehen.
Dieses Verhältnis ist bei Istanbul trotz einem Kanal weniger besser, da er "nur" 6 Kerne versorgen muss.
Daher der Vergleich 0,25 zu 0.33 und dass Gulftown gegenüber AMDs 6-KErner zwar 100% mehr Threads gleichzeitig verarbeiten kann, aber nur 50% mehr Speicherbandbreite zur Verfügung hat, bei gleicher Taktung natürlich.
Damit wäre die schammige Argumentation des Prozessorgeflüsters widerlegt, einfach mal eben so von einem Gulftown-Benchmark auf Thuban/Istanbul zu folgern.
Das war eigentlich alles was ich damit ausdrücken wollte.
Den Äpfel/Birnen - Vergleich haben die C't-Leute schon angestellt indem sie derart waghalsige Behauptungen aufstellen ohne sie mit konkreten Messwerten untermauern zu können.

Mittlerweile sind wir ja hier in der Argumentation so weit dass auch die größeren Caches als "Ausweg" gelten können warum AMD nicht an dem Problem leiden wird. Ich habe das mal außen vor gelassen und nur anhand der theoretischen Speicherbandbreite argumentiert, die pro Kern gesehen bei 6 Kernen auf Dualchannel eben immernoch höher ist als bei 12 Kernen auf Triplechannel.
 
@Twodee:
Ich bezog meine Argumentation auf die freche Unterstellung der C't dass der Istanbul zu wenig Speicherbandbreite bei Dual Channel haben könnte, nur weil Gulftown anscheinend durch sein Triplechannel limitiert wird.
Daher habe ich versucht aufzuzeigen, mal völlig abgesehen von Architektonischen Eigenheiten, Caches etc. dass Gulftown bei vollauslastung rein rechnerisch, jedem Thread (jedem virtuellen Kern) 0,25 Speicherkanäle zur Verfügung stellen kann, also ein zwölftel der gesamten 3 Speicherkanäle (und damit der Bandbreite) die einem einzelnen Thread zur Verfügung stehen.
Dieses Verhältnis ist bei Istanbul trotz einem Kanal weniger besser, da er "nur" 6 Kerne versorgen muss.

Daher der Vergleich 0,25 zu 0.33 und dass Gulftown gegenüber AMDs 6-KErner zwar 100% mehr Threads gleichzeitig verarbeiten kann, aber nur 50% mehr Speicherbandbreite zur Verfügung hat, bei gleicher Taktung natürlich.
Damit wäre die schammige Argumentation des Prozessorgeflüsters widerlegt, einfach mal eben so von einem Gulftown-Benchmark auf Thuban/Istanbul zu folgern.
Das war eigentlich alles was ich damit ausdrücken wollte.
Den Äpfel/Birnen - Vergleich haben die C't-Leute schon angestellt indem sie derart waghalsige Behauptungen aufstellen ohne sie mit konkreten Messwerten untermauern zu können.
Wie gesagt der Vergleich hinkt gewaltig.
Bei AMD sind es 6 echte Threads (jeder Thread läuft ohne Einschränkung auf einem Core), welcher jeweils volle Leistung fahren könnte, und diese Teilen sich eine Dual-Channel Ram-Anbindung.

Bei Intel jedoch sind es 12 Threads (2 Threads pro echtem Core), welche NICHT den gleichen Durchsatz schaffen können, als wenn es nur 6 Threads (1 Thread pro echtem Core) wären, da sich jeweils 2 Threads die Ausführungseinheiten etc.. miteinander teilen müssen. Würde man die erbrachte Leistung zweier HT-Threads addieren, käme man im Schnitt auf +10 bis +20%.
D.h.
1 Thread auf einem Core => 100%
2 Threads auf einem Core => 110% - 120% (im Optimalfall natürlich)
das wiederum bedeutet das beide Threads nur noch mit ca. 55% - 60% laufen
=> 2 Threads sind in der Summe schneller, aber einzeln langsamer als wenn nur ein Thread auf dem Kern laufen würde
Daher schlussfolgere ich, das 2 Threads auf einem Core niemals den doppelten Speicherdurchsatz erzeugen/verlangen/beanspruchen könnten, als wenn nur 1 Thread auf dem "echten" Core laufen würde.
Ich nehme mal an das der max. Ramdurchsatz pro Core eben auch um ~20% Steigen könnte:

=> 3 Kanäle / ( 6 Cores * 120 % [HT]) = 0,41 Kanäle pro HT-Core

[AMD: 2 Kanäle / 6 Core = 0,33 Kanäle pro Core]
 
Zuletzt bearbeitet:
Darüber kann man streiten... Die zwei Threads teilen sich zwar die Recheneinheiten, können aber beide mehr oder minder unabhängig voneinander den uncore-Bereich beschäftigen bzw. der eine Rechnet wären der andere auf Daten aus dem RAM wartet... gleichfalls müssen auch für beide Threads verwaltungsinformationen mitgespeichert, und die Rechenergebnisse in den caches vorgehalten werden, egal ob der jeweilige thread grade arbeitet oder darauf wartet dass sein Zwilling die rEcheneinheiten für ein paar takte freigibt... die Verwaltung ist also trotzdem doppelt, auch wenn es nur zwei "virtuelle" threads sind.
 
Darüber kann man streiten... Die zwei Threads teilen sich zwar die Recheneinheiten, können aber beide mehr oder minder unabhängig voneinander den uncore-Bereich beschäftigen bzw. der eine Rechnet wären der andere auf Daten aus dem RAM wartet... gleichfalls müssen auch für beide Threads verwaltungsinformationen mitgespeichert, und die Rechenergebnisse in den caches vorgehalten werden, egal ob der jeweilige thread grade arbeitet oder darauf wartet dass sein Zwilling die rEcheneinheiten für ein paar takte freigibt... die Verwaltung ist also trotzdem doppelt, auch wenn es nur zwei "virtuelle" threads sind.

Wie wahrscheinlich ist es, dass beide Threads gleichzeitig auf den Speicher warten? [Und falls das der Fall sein sollte, wieviel fängt hier der dicke L3 davon ab?]
Ist es nicht wahrscheinlicher, dass ein Thread auf den Speicher wartet, während in der Zwischenzeit der 2. Thread am rechnen ist?
Wieviel "Speicher-Last" erzeugt dein Verwaltungsaufwand (was meinst du damit? Stack, Register, etc?) Bestenfalls wird das im Cache verbleiben, aber selten über den L3 hinaus ins Ram geschoben, oder?
 
Natürlich, aber das was der eine Thread im Cache zwischenlagert, steht seinem Zwilling nicht mehr zur Verfügung.
Effektiv halbiert sich also salopp gesagt der Cache pro Kern, wenn SMT in Betrieb ist.
Ob beide gleichzeit warten kann natürlich keiner wirklich sagen... es ist aber ebfenalls nicht auszuschließen, schließlich sind instruktionen ja nicht unbedingt gleich lang etc. bei max. Auslastung kanns da schon mal kollisionen geben.
Zumindest ist diese Theorie nicht weniger plausibel wie ohne weitere Beweise einfach so zu unterstellen eine andere Architektur hätte die selben Probleme...
 
Das der Thuban die selben Probleme hat, hab ich ja aufgrund dessen das es "nur" 6 Threads sind auch für unwahrscheinlich gehalten.
Ich frage mich halt ob das auf absehbare Zeit ein Problem wird mit zu vielen Threads, ältere Software scheint das ja gar nicht zu vertragen laut CT liegen mit dem Hexacore bis zu 23% zwischen Vista und Win7.
Da könnte die Entscheidung von AMD kein SMT zu verbauen durchaus sich positiv auswirken.
 
Aja, was mir noch einfällt, blätter mal in der c't auf die genannte Seite vor, auf der sie den Hexa Core testen und schau nach, welches OS sie haben.

Wenn es kein Win7 ist, dann ist das nur das übliche Scheduler Problem, das wäre dann nichts Neues.
Im Linux Falle ... keine Ahnung ^^

ciao

Alex

Der Linux scheduler sollte mit sowas keine probleme haben.
 
Wir werden sehen was am Ende raus kommt. Einen Thuban mit 6 Kernen ohne die Erhöhung des L3 Speichers ist auch nicht unbedingt das gelbe vom Ei.

Werden die Quadcores denn von der Menge des L3 limitiert?
Der L3 ist recht langsam, das ist IMHO eher ein Problem der akt. K10.5 Generation. Weniger die Größe.
Man darf nicht vergessen dass die L1 und L2-Caches bei AMD vergleichsweise groß sind im Gegensatz zu intels Nehalems.
Zudem sind die caches exklusiv, d.h. weniger Platzverschwendung, daher sollte man eigentlich eher mit weniger Cache auskommen als Intel.
Abgesehen davon, selbst wenn die 6-Kerner dann am Limit in Sachen Cachegröße angekommen sein sollten, machen wir uns nichts vor... die 6-Kerner sind mehr oder weniger ein Deneb mit einem Regor angeflanscht. Der Uncore-Bereich ist quasi 1:1 der eines Denebs.
Minimale Verbesserungen und Turbomodus und fertig ist der Thuban.
Wer da ernsthaft Wunder erwartet lebt in einer anderen Welt. Vor dem Erscheinen von Orochi erwarte ich im Desktopbereich bei AMD keine großen Performance-Sprünge mehr.
Thuban existiert nur um angesichts eines Westmere wenigstens "ich auch" schreien zu können wenn es um 6-Kerner geht. Dass man beim akt. 45nm-Prozess nicht mal eben 50% mehr cache draufschlagen kann ohne ein Monster-Die zu fabrizieren dürfte auch klar sein. Vor allem angesichts eines Lisbon X2, alias Magny Cours.

"Das gelbe vom Ei" - stellt Huban also wohl in keinster Weise dar. Aber das ist momentan einfach alles was man hat. Ein Drei-Modul-BD wäre da sicherlich ein ganz anderes Kaliber aber nunja... man muss irgendwie Zeit schinden bis dahin...

Trotzdem kann ich mich nicht einfach hinstellen und sagen "Gulftown wird bei 12 Threads vom Triplechannel ausgebremst, also hat ein Thuban bestimmt bei 6 Threads und Dualchannel die selben Probleme"... das ist nicht nur unseriös sondern schlicht weg Obstvergleich.

Mir soll mal einer schlüssig mit Rechenweg nachweisen bei welcher RAM-Taktung, Uncore-Takt und welchem Zugriffsmuster ein akt. Prozessor wirklich an "mangelnder Speicherbandbreite" leidet und vor allem wo man das bei normaler PC-Nutzung merkt.
Verglicht mal zwei gleichgetaktete Nehalems, einen Lynnfield und einen Bloomfield bei Wald-Und-Wiesen-Software mitienander, und dann sagt nochmal was dem Bloomfield seine fette Triple-Channel-Transistorenverschwendung einbringt. ;)

Und dabei reden wir nur über 2 fast gleich aufgebaute Kerne mit unterschiedlicher Speichernabindung und folgern noch nicht einmal auf eine andere Architektur.

Steht eigentlich schon fest welchen Uncore-Takt ein Thuban haben wird?

Gruß,
ich
 
Einen Thuban mit 6 Kernen ohne die Erhöhung des L3 Speichers ist auch nicht unbedingt das gelbe vom Ei.
Kann man so nicht sagen. Es ist das gleiche L3-Kern-Verhältnis wie bei der 800er Serie. Und ein X4 810 liegt laut CB im Gesamtrating nur 0,3 Prozentpunkte hinter einem X4 940 @ 2,6 GHz und identischem Speicher. Also absolut vernachlässigbar. Von 50% mehr Kernen und Turbo wird man weit mehr profitieren als von 50% mehr L3 oder was immer du dir auch vorstellst.
 
... Thuban existiert nur um angesichts eines Westmere wenigstens "ich auch" schreien zu können wenn es um 6-Kerner geht.
...
"Das gelbe vom Ei" - stellt Huban also wohl in keinster Weise dar. Aber das ist momentan einfach alles was man hat. ...
Also sooo schlecht muss man den Thuban auch nicht machen.

Alleine schon die Aussicht einer fest eingebauten automatischen Über/Untertaktung macht den Thuban interessant.
Dann noch die Zusage, dass damit auch noch DDR2-RAM genutzt werden kann, das ist das ein richtig gutes Angebot.

Wenn ich die abgkühlte Liebe von Sun/Oracle sehe, dann ist das für AMD auch eine wichtige Rückversicherung. Etwas ältere Modellreihen bekommen ein Performance-Upgrade ... ohne das dabei gleich das Rad neu erfunden werden muss.

Aber auch IBM, HP und Dell nehmen diese Sechkerner-Option von AMD bestimmt gerne wahr, wenns mit wenig Neuaufwand verbunden ist.
Ich bin aber dennoch gespannt in wie weit sich DDR3-Speicher absetzen kann gegenüber den DDR2-Lösungen. Und ich erwarte, dass zudem der neue Hochtakt-Low-Power DDR3 mit dem Thuban rund läuft.

MFG Bobo(2010)
 
Zuletzt bearbeitet:
Kann man so nicht sagen. Es ist das gleiche L3-Kern-Verhältnis wie bei der 800er Serie. Und ein X4 810 liegt laut CB im Gesamtrating nur 0,3 Prozentpunkte hinter einem X4 940 @ 2,6 GHz und identischem Speicher. Also absolut vernachlässigbar. Von 50% mehr Kernen und Turbo wird man weit mehr profitieren als von 50% mehr L3 oder was immer du dir auch vorstellst.

Und wenn man sich dann mal eine Rosine wie Winrar (was bekanntlich sehr gut am Speicher hängt) herauspickt, sind es doch schon gute 12% Unterschied ;)
 
Tja, wir picken uns aber nun mal keine Rosinen heraus. Das solltest du doch wissen. ;)

edit:
Vor allem, da es lediglich der integrierte Test ist. In der realen Anwendung sind es dann nur noch 2%.
 
Zuletzt bearbeitet:
Also sooo schlecht muss man den Thuban auch nicht machen.

Alleine schon die Aussicht einer fest eingebauten automatischen Über/Untertaktung macht den Thuban interessant.

Ich hatte keineswegs vor ihn schlecht zu machen. Im Gegenteil.
Bei der allgemeinen Nehalem.Hyterie wird nur gerne etwas übertrieben und von AMD scheinabr erwartet sich mal eben nen zweiten K7 ausm Ärmel zu schütteln der Nehalem dahin tritt wos wehtut.
Dass das alles andere als einfach ist...tja...

Abgesehen davon, wenn ich mir einen 2,8Ghz Thuban kaufe, und quasi keine Software von 6 KErnen profitiert sodass er ständig auf Turbomodus läuft, lass es 3,2Ghz sein...
Wo ist dann nochmal der Vorteil zu einem Deneb 955?
 
Abgesehen davon, wenn ich mir einen 2,8Ghz Thuban kaufe, und quasi keine Software von 6 KErnen profitiert sodass er ständig auf Turbomodus läuft, lass es 3,2Ghz sein... Wo ist dann nochmal der Vorteil zu einem Deneb 955?
Der Vorteil besteht darin, dass Du Dir Software zulegen kannst, die von 6 Kernen profitiert ;D
 
Tja, wir picken uns aber nun mal keine Rosinen heraus. Das solltest du doch wissen. ;)

edit:
Vor allem, da es lediglich der integrierte Test ist. In der realen Anwendung sind es dann nur noch 2%.

Ja davon mal abgesehen musst ich schon sehr genau picken, um überhaupt solch einen Ausreißer zu finden.
Aber zufälligerweise kackt dort auch der 6-Core i7 mit aktivierten HT DEUTLICH ab. Zufall das es wieder WinRar ist?
 
Zurück
Oben Unten