Bulldozer rollt an....
- Ersteller neax
- Erstellt am
- Status
Na ja, ein neuerer Server kann eben auch durch eine neuere & effizientere Kühl-System oder andere Komponeten effizienter sein.
Mir wäre es ja recht, falls di 4% eher stimmen, da ich dann mit meiner Ableitung auf exakt 3,5 Ghz @ 8-Core-Bulldozer kommen würde.
Vorallem, da Intel heute einen 3,46 Ghz-6-Core vorstellte, würde ein 3,5 Ghz-8-Core von AMD dann umsomehr passen.
Genau das, was John Frühe sagte.
Wobei er es mit Durchsatz-bei-selben-Thermischen-Rahmen nannte.
Zuletzt bearbeitet:
gruffi
Grand Admiral Special
JF sprach von einem anderen Sachverhalt, nämlich der Performance eines Threads gegenüber zwei auf dem selben Modul (+80%). Wir sprachen hingegen vom Unterschied CMT vs CMP, oder genauer gesagt die Performance eines Moduls gegenüber einem theoretischen Bulldozer Dual-Core ohne CMT Design. Und hier soll ersteres eben 80% Performance liefern. Die entsprechenden Infos dazu findest du auf den Folien von AMD.
Hier nochmal zur Veranschaulichung:
Oben der theoretische CMP Dual-Core mit Bulldozer Architektur und ohne CMT, unten die tatsächliche Implementierung inklusive CMT.
CMP Design hätte mehr Leistung als CMT weil jedes Cluster seinen eigenen Fetch, Decode, L2 Cache & FP Scheduler hat.
CMP wäre ein richtiger Dual Core.
Bei CMT (Bulldozer / Orochi DIE) müssen sich die 2 Cluster in einem Modul diese Ressourcen teilen, das ist der Nachteil und deshalb ist ein CMT Modul kein Dual Core sondern ein physicher Core mit 2 logischen Prozessoren die geteilte Ressourcen nutzen.
CMP wäre ein richtiger Dual Core.
Bei CMT (Bulldozer / Orochi DIE) müssen sich die 2 Cluster in einem Modul diese Ressourcen teilen, das ist der Nachteil und deshalb ist ein CMT Modul kein Dual Core sondern ein physicher Core mit 2 logischen Prozessoren die geteilte Ressourcen nutzen.
Zuletzt bearbeitet:
Ui, die 80% hatte ich übersehen.
Aber Frage bleibt, was ein "Single-Core-Bulldozer ist".
Laut den Grafiken hätte der "Single-Core-Bulldozer" ein 2-Fach-Front-End mit 2-ALU sowie einen eigenen AVX-FPU. (=Fall 1)
(Ein Dual-Core-Bulldozer @ CMP hätte somit auch doppelte FPU-Performance, aber das ist AFAIK nicht das Thema)
Ein 2-Fach-Front-End mit 2-ALUs wäre schon ordentlich langsamer als ein K10 (3-Fach-Front-End & 3 ALUs)
Und wenn dann ein Dual-Core Bulldozer(Fall 1) @ CMT nur 80% bringt, dann hätte ein Modual gar nur ~145% (~90%*160) Performance eines K10.5.
Wenn aber ein "Single-Core-Bulldozer-Core" mit 4-Fach-Front-End mit 4-ALUs (=Fall 2) gemeint ist/war, dann ergeben die 80% des CMP ja Sinn, da so ein Single-Core (Fall 2) mit 4-Fach-Front-End & 4-ALUS ja sowieso 125% (bzw. 127% laut dir) eines K10.5 hätte und dann mit 80% @ CMT statt CMP eben ebenfalls auf 200% (=125%*160) bzw. eines Dual-Core K10.5 kommt.
Wobei es vielleicht nicht genau 125% sondern etwas mehr wären, da laut JF ein Interlagos unter Multi-Thread +50% Mehr Performance-pro-Watt hat.
Das bedeutet wiederum, dass bei 33% mehr Cores und ~10% mehr Takt (siehe Super-Computer) ein bald kommender Bulldozer-Core unter Multi-Thread eben eine Performance in K10-Gegend haben muss bzw. eventuell paar Prozent (3-7%) mehr.
Somit hätte die Aussage "80% CMT vs. CMP" für mich Sinn, wenn ein hypotetischer Bulldozer-Single-Core ein 4-Fach-Front-End mit 4-ALUS hätte (= 33% Mehr Front-End (+ flexibel) sowieo + 33% mehr ALUs), da das dann mit der K10.5-Performance ja auch (irgendwie) zusammenpassen soll.
Oder anders gesagt: Mit 33% mehr Front-End und 33% mehr ALU würde ein Bulldozer
Fall 1: ("CMP-Variante") 125% Performnace eines K10.5 bringen und
Fall 2: ("CMT-Variante") 200% Performance eines K10.5 bringen.
Und eine CMT-Variante mit einem K10.5 Core (3-Fach-Front-End und 3 ALUs, würden 180% bringen?, was ja nicht geht, weil ein Modul-Konzept mit 3 ALUS (1. Integer-Core mit 2 ALUs und 2. Integer-Core mit 1.ALU überspannt mit 3-Fach-Front-End) natürlich nicht so gut skaliert wie ein Modul-Konzept mit 4-Fach-Front-End mit 2.ALUs pro Integer-Core, sondern eben (deutlich) weniger als +80%.
Ich hoffe ich liege jetzt damit richtig.
200% / 33% = Performance-pro-zusätzlichen-Front-End-&-ALUs entspricht eine "(Integer-)Einheiten-Effizienz-Steigerung" von ~50%.
Laut John-Früher soll die Performnace-pro-Watt @ Server aber zusätzlich mit einer Strukturverkleinerung auf 32nm um 50% steigen. Ob man diese beide Werte überhaupt vergleichbar sind?
Eines ist auch noch interessant auf der 2.Folie. Da seht
"When only one Thread ist aktive, it has full access to all shared resources"
Also, das sollte bedeuten, wenn der 2.Integer-Core @ TurboCore schlafengelegt wird, hätte der 1.Integer-Core den ganzen 4-Fach-Front-End für sich alle.
Da ein 4-Fach-Front-End für 2-ALUs @ Single-Thread völlig überdimensioniert wäre, hätte es viel sinn, die 2-ALUs deutlich zu übertakten (+33%?, +50%? oder gar +100%)
Mal sehen, ob die Andeutungen dann doch nicht täuschen.
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
Das ergäbe also:
theoretischer CMP Dual-Core mit Bulldozer Architektur und ohne CMT: 100%
tatsächliche Implementierung inklusive CMT: 80%
Somit hätten wir den Vergleich CMP mit CMT vor Augen, von dem eben auch im Hot Chips Video die Sprache war - auf Basis der hier gezeigten Folien.
Dabei galt:
CMP - 2 Threads
CMT - auch 2 Threads
JF sprach von Leistung des CMT mit 1 bzw. 2 Threads.
Der Fall mit 2 Threads steht auch schon oben: 80% der CMP-Leistung, aber auch 180% der Leistung von 1 Thread auf CMT (oder 90% pro Thread). Das heißt auch, dass nur 1 Thread/Modul 55,6% der 2-Thread-Leistung (100%) erreicht bzw. 111% mit 2 Threads auf 2 Modulen. Nun entspräche die 2-Thread-Leistung 90% (1/1,11) der Leistung von 2 Threads auf einem hypothetischen CMP mit 2 Modulen (1T/M).
Verknüpft man diese Aussagen auf dieser Basis, ist der CMP-Core von den Folien ("Fully-capable core") nochmal 12,5% schneller (0,9/0,8) als das ganze CMT-Modul, wenn 1 Thread darauf läuft. Also hätte man die Fähigkeiten des Cores für die Verwendung als Modul reduziert. Das wäre widersprüchlich.
Was stellt nun also 1 Thread auf CMT dar (volle Nutzung der shared Ressourcen, Nichtnutzung des 2. Int Cores)? Wäre die Leistung nun höher oder niedriger als die eines CMP-Cores? Schließlich wurde das Modul laut Folien "aufgebohrt".
Definiere mal bitte "logischer Prozessor" und erkläre, weshalb zwei physisch real existierende Rechenkerne nur noch logisch sind.
Und hier muss aber neben der Die-Fläche auch an den Energieverbrauch gedacht werden. Die 2 CMP-Kerne hätten eine höhere Leakage und auch einen höheren Verbrauch (mehr aktive Logik). Und dank Ineffizienzen, Bubbles zwischen Bursts usw. hättest du mit dem ganzen Aufwand gerade mal 25% mehr Rechenleistung bei gleicher Thread-Zahl, dafür aber weniger Kerne bei gleichem Stromverbrauch, also statt 8C Zambezi eine CPU mit 5C u. knapp 80% der Rechenleistung.
Gäbe es keine Grenzen, hättest du schon längst deinen 8GHz 20-Core Chip mit 8-wide issue.
Um mal ein bisschen Verwirrung zu stiften:
Kann man ein 2-ALU/2-AGU Design nicht auch so bauen,dass die AGUs
ALU-Grundfunktionen mit durchführen können,so wie ein simples ADD?
RISC-CPUs ?
Dresdenboy
Redaktion
☆☆☆☆☆☆
Kann man.Um mal ein bisschen Verwirrung zu stiften:
Kann man ein 2-ALU/2-AGU Design nicht auch so bauen,dass die AGUs
ALU-Grundfunktionen mit durchführen können,so wie ein simples ADD?
.
EDIT :
.
Kennen wir die schon?
.
EDIT :
.
Und noch ein Letztes für heute:
http://www.tektalk.org/wp-content/u...ort-Sandy-Bridge-Spans-Generations-243901.pdf
(Microprocessor Report Artikel zu Sandy Bridge)
Jein, ich finde gerade den Post von JF nicht, aber afaik meinte er, dass man nur ganze Module abschalten kann. Bei einem Thread pro Modul könnte man also höchstens Clock-Gating betreiben. Außerdem müsste man dann auch noch schauen mit welcher Granularität man Takt und Spannung einstellen kann, ich vermute auch eher per Module, zumindest was die Spannung betrifft. Weiterhin wird man Front-End und ALUs sicherlich nicht getrennt takten können, so dass ein Mehrtakt bei den ALUs auch ein Mehrtakt beim Frontend bedeutet, wodurch das Verhältnis zwischen Front-End- zu ALU-Leistung gleich bleibt.
Aus diesen Gründen bin ich mir nicht sicher, ob es nicht sogar sinnvoller wäre alle Threads auf möglichst wenige Module zu verteilen. Man verliert damit zwar unter Umständen erst einmal ein wenig Leistung, aber man hat auch Vorteile, vor allem, wenn Threads des gleichen Tasks zusammen auf einem Modul laufen (z.B. wegen der shared Caches). Außerdem kann man dann ein Teil der Module komplett abschalten, was mehr einsparen sollte als bloßes Clock-Gating innerhalb eines Moduls und so mehr Turbo für die restlichen Module ermöglicht.
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ne kannten wir (zumindest ich) noch nicht.
Aber das sieht ja fast aus wie eine der billigen Fälschungen:
- Erstmal die komische Farbe
- In Zeile 2: no shared execution Units
- Weiter unten: Shared FPU
Dass dann auch noch der L3 innerhalb des "Bulldozer Modules" Kreises liegt, ist schon egal
ciao
Alex
Dr@
Grand Admiral Special
Der eigentliche Witz besteht aber darin, dass die Folie ganz offenbar direkt von AMD stammt:
Klick mich!
Klick mich!
Dresdenboy
Redaktion
☆☆☆☆☆☆
Richtig, da kommt sie her
Eine sehr wahrscheinliche Fälschung ist dagegen die 3DMark Vantage Übersicht mit Zambezi-Scores, wo der mit Turbo (warum mal mit, mal ohne?) genau 17,001% höher ist als der ohne.
http://www.rumorpedia.net/amd-bulldozer-benchmarks-leaked/
Zuletzt bearbeitet:
Ich würde nicht so weit gehen zu behaupten dass ein 2-issue-BD "Singlecore" weniger IPC haben müsste als K10.5.
Dazu müssten wir die mittlere Auslastung der 3 Pipes eines K10 kennen... Wenn die wegen Bubbles, Frontend, Prediction usw. ohnehin nur bei 2,1 läge (im mittel, wohlgemerkt) verliert ein BD-Modul da quasi nichts...
Dafür ist das Frontend (höchstwahrscheinlich) viel besser, und der TraceCache steht noch zur Diskussion.
Also ist es durchaus möglich dass bereits ein einzelner INT-Core eines BD-Modules in der Praxis bereits eine höhere IPC hat als ein K10.5 Kern erreicht. Mal völlig ungeachtet der Tatsache dass ein K10.5 theoretisch mehr Asuführungseinheiten für einen Thread zur Verfügung hat... (Was aber auch nur für INT-Code zutrifft, die FPU ist ein ganz anderes Kaliber...)
Nur mal so am Rande bemerkt...
Dazu müssten wir die mittlere Auslastung der 3 Pipes eines K10 kennen... Wenn die wegen Bubbles, Frontend, Prediction usw. ohnehin nur bei 2,1 läge (im mittel, wohlgemerkt) verliert ein BD-Modul da quasi nichts...
Dafür ist das Frontend (höchstwahrscheinlich) viel besser, und der TraceCache steht noch zur Diskussion.
Also ist es durchaus möglich dass bereits ein einzelner INT-Core eines BD-Modules in der Praxis bereits eine höhere IPC hat als ein K10.5 Kern erreicht. Mal völlig ungeachtet der Tatsache dass ein K10.5 theoretisch mehr Asuführungseinheiten für einen Thread zur Verfügung hat... (Was aber auch nur für INT-Code zutrifft, die FPU ist ein ganz anderes Kaliber...)
Nur mal so am Rande bemerkt...
LoRDxRaVeN
Grand Admiral Special
Ich habe grade im Cb-Forum einen ziemlich interessanten Thread gefunden, worin vom MSI Support behauptet wird, dass sich die Pläne bezüglich der Inkompatibilität von Zambezi zu AM3 (wieder) geändert haben sollen:
http://www.computerbase.de/forum/showthread.php?t=859956
http://www.computerbase.de/forum/showthread.php?t=859956
Ähm... geht denn das? - nach dem was wir bisher von den AM3+-Sockeln gesehen haben (1 loch mehr) dürfte eine AM3+ - CPU die dort einen Pin aufweist, nicht in ein AM3-Mobo passen. Da fehlt schlichtweg das entsprechende Loch im Sockel dafür... umgekehrt kann aber eine AM3-CPU sehr wohl in einen AM3+ - passen.
Die Kodierung anhand der Sockelbilder ist also genau so rum wie auch unser letzter Informationsstand zur Sockelproblematik aufzeigt. AM3-CPU in AM3+-Sockel geht, umgekehrt geht nicht.
Die Kodierung anhand der Sockelbilder ist also genau so rum wie auch unser letzter Informationsstand zur Sockelproblematik aufzeigt. AM3-CPU in AM3+-Sockel geht, umgekehrt geht nicht.
LoRDxRaVeN
Grand Admiral Special
Da wir noch von keinem einzigen Zambezi das PIN-Layout gesehen haben, muss es ja nicht so sein, wie es der Sockel (mit dem einen Loch mehr) nahelegen würde...
Evt. wäre auch ein Vorgehen ähnlich wie beim 940er und 920er denkbar. D.h. man könnte Zambezis bringen, welche AM3 und AM3+ kompatibel sind, aber auch welche, die nur in AM3+ eingesetzt werden können...
Evt. wäre auch ein Vorgehen ähnlich wie beim 940er und 920er denkbar. D.h. man könnte Zambezis bringen, welche AM3 und AM3+ kompatibel sind, aber auch welche, die nur in AM3+ eingesetzt werden können...
Zuletzt bearbeitet:
The G
Lt. Commander
Würde das stimmen wäre das natürlich klasse und eine Fortführung der bisherigen Politik. Wie sieht den die Sache im Zusammenhang mit dem MSI 890FXA-GD65 aus? Bei den ersten News wurde der AM3+ Support ja noch angezweifelt weil beim abgebildeten Sockel die Aussparungen nicht passen würden. Mit dieser Aussage von MSI kann das ja wieder zusammenpassen.
LoRDxRaVeN
Grand Admiral Special
Genau um dieses Board ging es ja in dem Thread/E-Mail-Verkehr --> also besser den gesamten Post beim verlinkten cb-Thread nachlesen
Natürlich geht das.
Wo ist mein Hammer?
Vielleicht gibt es auch dann endlich wieder neue Bilder auf Dau-Alarm.de
Dr@
Grand Admiral Special
Ich habe jetzt noch mal bei AMD nachgefragt. Mal gucken, ob ich eine Antwort bekomme.
Zu der MSI-Geschichte will ich nur noch folgendes sagen: Wir hatten noch etwas eMail-Verkehr, der aber nicht wirklich ergiebig war und eher noch weiter verwirrt hat. Mich würde mal interessieren, mit wem dieser eMail-Austausch auf CB gelaufen ist. Wenn es der gleiche Mitarbeiter bei MSI war, würde das für mich einiges erklären.
Zu der MSI-Geschichte will ich nur noch folgendes sagen: Wir hatten noch etwas eMail-Verkehr, der aber nicht wirklich ergiebig war und eher noch weiter verwirrt hat. Mich würde mal interessieren, mit wem dieser eMail-Austausch auf CB gelaufen ist. Wenn es der gleiche Mitarbeiter bei MSI war, würde das für mich einiges erklären.
gruffi
Grand Admiral Special
Nee, daran ist nichts widersprüchlich. Das obere steht unter dem Punkt "Full Performance From Each Core". Damit sind also die Integer Kerne gemeint. Und diese haben dedizierte Ausführungseinheiten. Hier muss also nichts geteilt werden wie bei SMT. Shared FPU weiter unten ist wiederum ein anderer Sachverhalt und sollte klar sein.Dann die widersprüchlichen Aussagen:
- In Zeile 2: no shared execution Units
- Weiter unten: Shared FPU
Der typische Lapsus des AMD Folienpraktikanten. Ein gutes Zeichen für die Echtheit der Folie.
Wo liegt eigentlich der Unterschied zwischen AVX 1.0 und 1.1? Intel scheint diese Abgrenzung nicht vorzunehmen.
Jedenfalls nicht anhand solcher Versionsnummer. Die tauchen bei den öffentlichen Folien im Software Network nicht auf.
Jedenfalls nicht anhand solcher Versionsnummer. Die tauchen bei den öffentlichen Folien im Software Network nicht auf.
SPawner
Fleet Captain Special
- Mitglied seit
- 25.08.2008
- Beiträge
- 292
- Renomée
- 4
Der typische Lapsus des AMD Folienpraktikanten. Ein gutes Zeichen für die Echtheit der Folie.
Ich würde eher die Valentinskarte + Schokolade einem Praktikanten zuordnen oder wer macht über 10 Jahre dort ein Praktikum? ^^
Zuletzt bearbeitet:
Wenn das so wäre, dann bräuchte man das CMT-Konzept nicht und könnte gleich aus dem 3-Fach-Front-End & 3-ALUs ein 2-Fach-Flex-Front-End mit 2-ALUs machen, wenn das 2-Fach-Fronted alleine die 2-ALUs zu fast 100% versorgen kann.
Ich glaube, in einem Takt bzw. in den nächsten paar Takten versorgt 3/4 oder gar 4/4 des Frontend den 1.Integer-Core und im nächsten Takt bzw. nächsten paar Takte versorgt das 3/4 oder 4/4 des Front-End dann den 2. Integer-Core.
Sonst hätte das Shared Resources bzw. Front-End ja keinen Sinn.
Aber eine Frage bleibt.
Wenn die ALU-Auslastung bei K10.5 schon 2,1 ALUs sein soll, dann frage ich mich, wie ein Bulldozer-Ingeteger-Core mit 2-ALUs dann überhaupt schneller als ein K10.5 sein kann, wenn die Integer-Cores beim Bulldozer mit (1,9 oder gar) 2,0 ALUs (fast) 100% ausgelastet wären?
- Status
Ähnliche Themen
