AMD FX-8xxx Bulldozer vs. Intel Core i5 und i7 - offizielle Benchmarks

[octacore]

Integerbench wäre ja interesant, falls wer da was sinnvolles(64bit multicore) kennt her damit.

Eidt: AIDA hat ja welche drin nur wie weit die "objektiv" sind ist mir immer suspekt...

 

[fdsonne]

Dann nenne mir doch mal ein paar Fakten, warum der Prozess aus technischer Sicht nicht iO sein soll. Mit Yields kannst du das nicht. Erstens, die sagen uns doch nur, wie fehleranfällig eine Kombination aus Design und Prozess ist. Und zweitens, bisher gibt es Gerüchte, dass nur Llano schlechte Yields haben soll, nicht aber Orochi oder Trinity. Das scheint also vielmehr ein Problem mit dem Llano Design zu sein und weniger mit dem Prozess. Dass der Prozess wiederum noch nicht optimal läuft, sollte klar sein. Das gibt GloFo ja sogar zu. Nur sind das völlig normale Optimierungsgeschichten zu Beginn einer neuen Fertigung und gewiss kein Grund, warum einige immer wieder behaupten, der Prozess sei so schlecht.

Warum verlangst du mir Fakten ab? Ich hab nirgend behauptet, es wäre so...
Ich habe nur gesagt, das ich es für gewagt halte, den Prozess als IO zu betrachten, und dazu eben die aktuellen Infos ranzuziehen. Denn die sagen darüber nüchtern gesehen nicht viel aus. Ich denke auch, es gibt hier keine Hop oder Top Aussage... Man wird irgendwo im Mittelfeld liegen. Nicht wirklich gut und nicht wirklich schlecht.

Na wenn du so rechnest, nehmen wir doch mal die Werte von Computerbase:

i7-2600, 3,4 GHz, 8 Threads: 6,7 (~0,25 pro Thread und pro GHz)
X6 1100T, 3,3 GHz, 6 Threads: 5,89 (~0,3 pro Thread und pro GHz)

Hell ya, der X6 ist IPC-King. Was regst du dich also auf, wenn Zambezi ähnlich gut ist? Merkst du was? Du betreibst hier eine ziemliche Milchmädchenrechnung.

Der 2500 i5 kommt übrigens auf ~0,41 pro Thread und pro GHz. Der i7 ist aber unterm Strich in jeder Lebenslage die schnellere CPU. Was zeigt, das solche Rechnungen ziemlich sinnfrei sind, wenn Techniken wie SMT zum Einsatz kommen, wo dann bei Volllast einer Einheit (in dem Fall eines Cores + SMT Part) eben die absolute pro Thread Leistung beeinträchtigt wird. Hättest du wenigstens noch erwähnt, das die absolute Gesamtleistung weiter steigt, wäre es ja OK.

 

[[HOT]]

Bulldozer ist aber mit 4 FPUs gegenüber 6 FPUs @X6 nicht gleich schnell.

Mein 1055T @4,2Ghz erreicht 7.41 Punkte, der FX8150 bei 4,2Ghz nur 6,9 Punkte, von gleich schnell kann man also nicht reden

Es ist Cinebench... ich glaube nicht, dass BD da überhaupt schon ein Profil hat. Der läuft auf Sandard, während es für K8/K10-Opteron und die Intels direkte Unterstützung gibt... Vor Cinebench14 wirds immer schlechte Ergebnisse geben, ähnlich wie bei Cinebench10 und dem K10 damals.

 

[fdsonne]

Es ist Cinebench... ich glaube nicht, dass BD da überhaupt schon ein Profil hat. Der läuft auf Sandard, während es für K8/K10-Opteron und die Intels direkte Unterstützung gibt... Vor Cinebench12 wirds immer schlechte Ergebnisse geben, ähnlich wie bei Cinebench10 und dem K10 damals.

Der Vergleich hinkt aber etwas... Damals bei den alten Cinebenchen wurden ja quasi die Befehlserweitungen ala SSE usw. von den AMD CPUs gar nicht genutzt.
Der BD bringt doch aber nichts SSE technisches mit, was man nicht vorher schon hatte und was in Cinebench von Vorteil ist!?
Dazu kommt, das es doch damals auch Tests gab, wo man das mehr oder weniger nur am CPU Hersteller festmachte. Durch ändern des Herstellers in einen anderen bei selbiger CPU, gabs mehr Punkte. Dieses Defizit sollte doch derzeit auch behoben sein!?

 

[scully1234]

Es ist der gleiche Node, 32 nm. 32 nm ist Full-Node, 28 nm ist Half-Node.

Wer hat denn hier was anderes behauptet?

Erste Testchips (nicht SRAM) in 28 nm hat man übrigens auch schon vor fast 2 Jahren gezeigt.

Was hat das

but they could be advanced SOCs based on ARM designs

Mit einem hochkomplexen Grafikchip gemein der bereits sein Tape Out hinter sich hat wie geschehen bei TSMC?

Denk nur nicht immer die Leute um dich herum wären völlig Gaga

Also entweder du kommst nun mit nem Sample der Radeon 7xxx angeflattert oder Bulldozer im Half Node(lach) oder trittst weiter im Fettnapf herum

Denn weder das eine noch das andere wird in nächster Zeit in dieser Strukturgröße kommen vom Dresdner Werk,dazu sind die Probleme bei 32nm viel zu dominant und tangieren selbst den 45nm Prozess

 

[Opteron]

Zitat von mr.dude
Würde mich nicht wundern, wenn bei Cinebench R10 AMD Prozessoren auch nur einen x87 Codepfad bekommen.

Dort wo AMD´s Prozessoren nicht gut abschneiden ist natürlich der Code schuld, selbst wenn man Superpi mit hauseigenen früheren Modellen abgleicht, klar.
Nimm doch mal cinebench R11.5, da siehts auch nicht besser aus.
Für dich scheinen nur die cherry picked Benchmarks von AMD von bedeutung zu sein.
Oder Excel....

Er hat schon recht, kann jeder mit Perfmonitor selbst nachprüfen. Die 32bit binary läuft nur mit x87, die 64b allerdings mit SSE2, da das dort der default ist. Komischerweise läuft BD mit CB10 besser. Möglicherweise sind da bei CB11.5 ein paar AMD K10 Optimierungen kontraproduktiv. Bei CB10 könnte dagegen der SSE2 Pfad für den P4 aktiv sein, und deshalb auf 16kB L1 optimiert sein, würde ja perfekt passen ^^
Aber das kann auch gut an 1000 anderen Sachen liegen. Warten wir einfach mal CB14 oder so ab (die sind mittlerweile bei Release 13, und da steht kein BD mit dabei).

 

[[HOT]]

Der Vergleich hinkt aber etwas... Damals bei den alten Cinebenchen wurden ja quasi die Befehlserweitungen ala SSE usw. von den AMD CPUs gar nicht genutzt.
Der BD bringt doch aber nichts SSE technisches mit, was man nicht vorher schon hatte und was in Cinebench von Vorteil ist!?
Dazu kommt, das es doch damals auch Tests gab, wo man das mehr oder weniger nur am CPU Hersteller festmachte. Durch ändern des Herstellers in einen anderen bei selbiger CPU, gabs mehr Punkte. Dieses Defizit sollte doch derzeit auch behoben sein!?

Das stimmt so nicht. Cinebench10 unterstützt natürlich auch SSE(2) für K7 und K8. Jedoch offenbar nicht die 128Bit FPU des K10. Unklar ist jetzt noch, ob der K10 damals wirklich einen x86-Standardpfad nutzte oder das K8-Profil. Cinebench11 ist jetzt ähnlich. Man muss bedenken, dass Cinema4D offenbar handoptimierte Codepfade oder CPU-Profile für die einzelnen Prozessorgenerationen mitbringt. Es kann sein, dass BD den K10-Codepfad nutzt und damit nicht zurecht kommt. Auf jeden Fall eignet sich Cinebench so garnicht um neue CPU-Generationen zu vergleichen.
Allein die schlechten Werte und die Probleme in der Vergangenheit sollten schon darauf hindeuten, dass man diesen Benchmark mit Vorsicht genießen muss.

 

[fdsonne]

Das stimmt so nicht. Cinebench10 unterstützt natürlich auch SSE(2) für K7 und K8. Jedoch offenbar nicht die 128Bit FPU des K10. Unklar ist jetzt noch, ob der K10 damals wirklich einen x86-Standardpfad nutzte oder das K8-Profil. Cinebench11 ist jetzt ähnlich. Man muss bedenken, dass Cinema4D offenbar handoptimierte Codepfade oder CPU-Profile für die einzelnen Prozessorgenerationen mitbringt. Es kann sein, dass BD den K10-Codepfad nutzt und damit nicht zurecht kommt. Auf jeden Fall eignet sich Cinebench so garnicht um neue CPU-Generationen zu vergleichen.
Allein die schlechten Werte und die Probleme in der Vergangenheit sollten schon darauf hindeuten, dass man diesen Benchmark mit Vorsicht genießen muss.

Sicher?
Ich meine mich zu erinnern, das es was mit SSE zu tun hatte...
Und mr.dude schrieb oben sogar ähnliches. Zumindest bezogen auf die x86 Ausführung.

Aber sei es drum, ich bin immernoch der Meinung, jedes Produkt was auf den Markt kommt, muss sich in erster Linie erstmal mit den Anwendungen an der Konkurenz messen, die auch am Markt sind.
Was später mal irgendwann durch Patches, neue Versionen usw. kommt, ist nicht im Detail vorraussehbar und somit abzuwarten. Kann ja quasi nur besser werden.

 

[Schaffe89]

Er hat schon recht, kann jeder mit Perfmonitor selbst nachprüfen.

Das mag ja sein, dass der Code eventuell nicht passt.
Trotzdem zeigt Cinbench nur eines und zwar geringere IPC im Vergleich zum Vergängermodell. Man kann sowas nicht immer auf den Code schieben.
Spielebenchmarks wären mal eine tolle Sache.
Wie fdsonne sagt, zählt das hier und jetzt und wenn das wieder nicht passt, dann isses halt schade drum.

AMD´s Prozessoren skalieren im R11.5 etwas besser wie im alten Cinebench.
Aber auch nicht um weltbewegende Prozentwerte.

 

[Opteron]

Das stimmt so nicht. Cinebench10 unterstützt natürlich auch SSE(2) für K7 und K8.

Siehe oben, die 32b Binary leider nicht
War aber mal sinnvoll, früher war x87 Code@AMD auch schneller als SSE.

Das mag ja sein, dass der Code eventuell nicht passt.
Trotzdem zeigt Cinbench nur eines und zwar geringere IPC im Vergleich zum Vergängermodell. Man kann sowas nicht immer auf den Code schieben.

Tja Code ist aber halt ne wichtige Sache. Geh in nen X-beliebigen Laden und versuch mit nem archiviertem DM Schein zu zahlen. Entweder gehts gar nicht mehr (3Dnow Fall), oder er wird angenommen, aber nur mit Nachteilen wie schlechter Umtauschkurs+extra Bearbeitungsgebühren (Kompatibilitätsfall).

Die Zeiten ändern sich halt, Euros sind Gang und Gäbe, aber Cinebench ist eins der wenigen Programme die anscheinend auf AMD handoptimiert waren. Wenn die dort z.B. auf den 64kB L1 Caches optimiert haben, dann gute Nacht@BD.

Ja es ist langweilig immer über den Code zu maulen, aber in dem Code sind nunmal die Instructions, die die Instructions Per Cycle beeinflussen.

 

[Duplex]

Vielleicht sollte man wegen Cinebench erstmal auf eine neue Version warten, dann wird man sehen was Bulldozer alles besser als der Vorgänger kann, ich kann mir vorstellen das Bulldozer mit optimierten Code in Cinebench besser als der Vorgänger abschneiden wird

@Schaffe89
Ich glaube es reicht, du solltest dich nicht zu oft bzgl. IPC wiederholen in 2 Wochen sind wir etwas schlauer...

 

[Opteron]

Vielleicht sollte man wegen Cinebench erstmal auf eine neue Version warten, dann wird man sehen was Bulldozer alles besser als der Vorgänger kann, ich kann mir vorstellen das Bulldozer mit optimierten Code in Cinebench besser als der Vorgänger abschneiden wird

Meine Rede:

Warten wir einfach mal CB14 oder so ab (die sind mittlerweile bei Release 13, und da steht kein BD mit dabei).

;-)

 

[Schaffe89]

Ich glaube es reicht, du solltest dich nicht zu oft bzgl. IPC wiederholen

Du kennst ja mr.dudes Ausweichtaktiken.
Aber ja du hast recht ;-).
Warten wir einfach ab.

Ja es ist langweilig immer über den Code zu maulen, aber in dem Code sind nunmal die Instructions, die die Instructions Per Cycle beeinflussen.

Schon klar.
Aber ob der nun mit aktuellem Code oder etwas veraltetem läuft macht das Kraut im Schnitt auch nicht fett.

 

[Opteron]

Schon klar.
Aber ob der nun mit aktuellem Code oder etwas veraltetem läuft macht das Kraut im Schnitt auch nicht fett.

Wissen wir noch nicht, warten wirs mal ab. Nichts ist so alt wie die Software von gestern ^^

Es kursiert z.B. ja auch noch die ominöse Win Scheduler Geschichte, für ein paar Pünktchen bis ~5% wäre das sicherlich auch was wert.

 

[mr.dude]

Du kennst ja mr.dudes Ausweichtaktiken.

Klar, mach ruhig andere für DEINE Polemik und Märchen verantwortlich.

 

[TP]

Kann mir die IPC Geschichte mal einer erklären? Wenn der BD mit 4 Kernen in etwa die gleichen Ergebnisse erziehlt wie der alte 6 Kerner muss die IPC doch erheblich besser geworden sein oder hab ich hier nen Denkfehler?! Im Takt nehmen die sich ja nichts.

 

[Nighteye]

Kann mir die IPC Geschichte mal einer erklären? Wenn der BD mit 4 Kernen in etwa die gleichen Ergebnisse erziehlt wie der alte 6 Kerner muss die IPC doch erheblich besser geworden sein oder hab ich hier nen Denkfehler?! Im Takt nehmen die sich ja nichts.

jop so siehts aus.

3 ghz single core schneller als 4 ghz single core = bessere ipc

mit der anzahl der kerne hat das nie was zu tun.

wenn ein 2 kerner schneller oder gleichschnell wie ein ein 4 kerner ist, muss das aber nicht zwangsweise mit ipc zu tun haben, da es software bedingt sein kann, das der 4 kerner nicht schneller ist.

 

[Athlon-64]

Kann mir die IPC Geschichte mal einer erklären? Wenn der BD mit 4 Kernen in etwa die gleichen Ergebnisse erziehlt wie der alte 6 Kerner muss die IPC doch erheblich besser geworden sein oder hab ich hier nen Denkfehler?! Im Takt nehmen die sich ja nichts.

Ja, denn 4 Bulldozer "Kerne" sind nicht vergleichbar mit 4 Phenom Kernen. Ein Bulldozer Modul beinhaltet beispielsweise 2 Integer Einheiten.

mfg

 

[mr.dude]

Kann mir die IPC Geschichte mal einer erklären? Wenn der BD mit 4 Kernen in etwa die gleichen Ergebnisse erziehlt wie der alte 6 Kerner muss die IPC doch erheblich besser geworden sein oder hab ich hier nen Denkfehler?! Im Takt nehmen die sich ja nichts.

Orochi hat zwar 4 physische Kerne (Compute Units). Dann müsste man aber auch nur 4 Threads laufen lassen, auf jeder Compute Unit einen, und zB mit Deneb vergleichen, um zu sehen, wie sich die IPC geändert hat. Wenn man Orochi voll auslastet (8 Threads), dann greift CMT. Und dann soll die Skalierung bei etwa 80% liegen. Das mit vollwertigen Kernen bezüglich IPC zu vergleichen, bringt keine sinnvollen Ergebnisse.

 

[madpenguin]

AMD Zambezi news, info, fans ! - Page 165

Sorry wenn ich diesen Thread dafür benutze, aber es sind Teile eines "offiziellen" Tests, bzw. Meinungen dazu. Muß ehrlich gestehen, daß ich es lächerlich finde, daß alle BD Threads bis auf diesem geschlossen sind. Man sollte User bannen, welche nur trollen und nicht den Thread schließen.

BTT: der obigen Post beschreibt ein von uns allen bekanntes Problem des BD, für welchen es jedoch scheinbar doch einen MS patch gibt (hoffentlich keine Ente)

 

[DonBanana]

Der dort besprochene Patch ist allerding Linux-only und wird dort wohl auch nicht zur Anwendung kommen:

AMD FX-8150 Bulldozer finally tested - Page 16

I want to draw everyone's attention to the fact that the patch people are suddenly talking about is for Linux ONLY and it WILL NOT address Windows-based performance. In addition, the Linux community has determined the "patch" itself is pretty much a hack job that could negatively impact system stability and in-app performance. So, it should not even be discussed at length at this point in time.

 

[Mondrial]

Ihr könnt diese Links auch den MODs schicken, die werden dann entscheiden, ob der Bulldozerthread wieder geöffnet wird oder ob der Link evtl. angefügt wird.

Wenn hier nun wieder eine Diskussion mit dem leider mittlerweile üblichen Spam und Gebashe entsteht, ist hier sicher auch schnell zu.

 

[madpenguin]

Der dort besprochene Patch ist allerding Linux-only und wird dort wohl auch nicht zur Anwendung kommen:

AMD FX-8150 Bulldozer finally tested - Page 16

Danke dir....Leeghoofd klang sehr erfreut darüber, daß es scheinbar einen Patch gibt und da er einen BD scheinbar testet, habe ich geglaubt es könnte noch was werden (10% in single und mehr im multi-threaded Bereich). Schade.

@Mondrial
Wußte ich nicht. Werde ich das nächste Mal machen. Ich möchte nur Infos über BD anführen, welche nicht hier gepostet wurden.....und mich über andere links oder Infos über BD informieren

 

[DonBanana]

Schau am besten im XS rein, hier wird ja nichts mehr zugelassen. Kann man das Forum gleich schließen, wenn hier nur zensiert oder geschlossen wird.

 

[ChrisTucker2004]

finde es auch einfach nur lächerlich und wie im Kindergarten direkt ganze Threads zu schließen wegen Leuten die sich nicht benehmen können.

BTT: Mal sehen was übermorgen alles auf uns wartet. NDA fällt bald.

 

[y33H@]

Orochi hat zwar 4 physische Kerne (Compute Units). Dann müsste man aber auch nur 4 Threads laufen lassen, auf jeder Compute Unit einen, und zB mit Deneb vergleichen, um zu sehen, wie sich die IPC geändert hat.

AMD sieht vor, dass vier Threads nur auf zwei Modulen [also vier "Kernen" *SCNR*] laufen. Die IPC liegt laut Leaks deutlich unterhalb eines Phenom II und meilenweit hinter Sandy Bridge.

 

[k3im]

Okay, BD wird vielleicht nicht der Knaller den sich "alle" erhofft haben.
Zumindest nicht der 8150. Das hier allerdings....

finde ich mehr als schlecht. Wer erstellt denn solche Diagramme?
13% mehr Punkte (ausgehend vom BD) für den 2600K aber eine mehr als eine doppelt so große Säule.

Sowas zeugt nicht gerade von keine Ahnung was.

 

[Larkin]

Böse Zungen würden behaupten AMD macht ähnliches bei ihren eigenen Folien ...ist halt so skaliert.

Die traurigste Folie ist aber:

 

[boxleitnerb]

Äh, hast du die Folien gesehen, die angeblich von AMD kommen? Da war das noch viel schlimmer. Ist doch auch wurscht, wie hoch die Balken sind - die Zahlen stehen dabei. Man kann sich auch künstlich aufregen.

 

[k3im]

Aber doch nicht soooooo extrem?!? Oder doch?