Zambezi - Fehler, Bugs, mangelnde Performance - Woran liegt es?

[Opteron]

@mocad_tom:
Hm, also den Vergleich zur Handverdrahtung finde ich unpassend. Ebenfalls Deinen ursprünglichen Vergleich zur Memory Disambiguity. Selbiges kann BD eben. Dass er trotzdem nicht ne Rakete ist liegt eben an anderen Sachen. Sei es jetzt an der längern Pipeline (was ich nicht glaube), oder halt doch irgendwie am synth. Design (was ich so pauschal auch nicht glaube), an was anderem, aber eben nicht an der Memory Disambiguity. Da gibts auch kein schlecht oder gut, sondern nur entweder oder. Entweder die Load/Store Logic kann Loads bei gewissen Situationen vor (unabhängigen) Stores ausführen, oder eben nicht.
Ok, "gewisse Situationen" sollte man da noch näher definieren, der K10 konnte das in wenigen Fällen auch schon, aber mir reicht in dem Fall die Expertise, dass BD auf Conroe-Niveau ist. Stand mal irgendwo in nem guten Artikel, eventuell bei realworldtech.

Allgemein zur Handverdrahtung:
Die hat eigentlich nur Auswirkungen auf Die-Fläche und ggf. auf den Taktspielraum. Auf die IPC mMn eher weniger, den die Logik ist ja schon definiert. Bobcat der wirklich komplett synthetisiert ist, schlägt sich ja auch verdammt gut, selbst gegen den handdesignten Atom. Nicht nur in Sachen IPC, wo man OoO gegen InO anführen könnten, sondern auch in Sachen Die-Fläche.
Kurz: Ist die Anfangsplanung gut, muss ein synt. Design gar nicht so schlecht sein.

BDs Planung war dagegen zu schlecht, was auch immer die Gründe waren. An der Memory Disambiguity liegts aber sicherlich nicht. Der Hund ist eher im Front-End begraben, die besten, breitesten Pipelines nützen nichts, wenn sie keine Daten bekommen.

Oder andersherum gesehen: Irgendeiner schrieb mal, dass BD eigentlich nur ein Prozessor wäre, der rundherum um die FPU entworfen wäre. Die FMA-FPU quasi als Kern, und der Rest nur so rangeklatscht. Da könnte was dran sein. Mit FMA-Code kann man sich über die Leistung ja nicht beschweren. Nur hilft uns das hier im Desktop herzlich wenig. Mit Glück gibts höchstens ne Handvoll Optimierungen in ATIs Grafiktreibern, ist ja immerhin die gleiche Firma, da könnte man sowas wenigstens erhoffen. Aber naja viel helfen wirds nicht.

 

[LoRDxRaVeN]

Der Hund ist eher im Front-End begraben, die besten, breitesten Pipelines nützen nichts, wenn sie keine Daten bekommen.

Ganz kurz: Siehst du (für dich) dies mittlerweile als gesichert an, dass das Hauptproblem im Front-End liegt, also dass dort IPC-Verluste im zweistelligen Prozentbereich begraben sind? Und wo siehst du das Hauptproblem im Front-End?

LG

 

[Duplex]

Der Nehalem hatte so viele Neuerungen(On-Die-Mem-Controller, Fabric für 4 Kerne, On-Die-L3), unterm Strich war er in Sachen IPC genau so schnell wie der Core2Duo, weil der einen saugeilen, saugroßen L2 mit winzigen Latenzen hatte (Brute-Force eben).

Nehalem hat 25-30% mehr IPC als der Core2, also deutlich schneller und nicht gleich schnell, Core2 & Shanghai waren bzgl. IPC ähnlich.

Erst der Schritt von Nehalem zu Sandy hat mal richtig gezeigt, was einige hundert israelische Leute in ihren 60-Stunden-Wochen mit Handverdrahten so alles hinbekommen.

Das ist falsch, der Schritt von Nehalem auf Sandy war kleiner als Core2 > Nehalem
Sandy Bridge punktet nur durch der kleineren 14 Stage Pipeline & Fullspeed Cache, Sandy Bridge ist bei gleichem Takt 10-15% schneller als Nehalem.
.
EDIT :
.

Ganz kurz: Siehst du (für dich) dies mittlerweile als gesichert an, dass das Hauptproblem im Front-End liegt, also dass dort IPC-Verluste im zweistelligen Prozentbereich begraben sind? Und wo siehst du das Hauptproblem im Front-End?

Das wird man evtl. bei Kaveri (Steamroller) feststellen können, wenn AMD im Modul einen 2. Decoder einbaut & das Wright Trough Cache Design verbessert gibt es bestimmt spürbar mehr CPU leistung als Trinity´s CPU Part.

 

[Opteron]

Ganz kurz: Siehst du (für dich) dies mittlerweile als gesichert an, dass das Hauptproblem im Front-End liegt, also dass dort IPC-Verluste im zweistelligen Prozentbereich begraben sind? Und wo siehst du das Hauptproblem im Front-End?

Jo wir hatten uns hier im Thread doch vor ein paar Seiten mehr oder minder auf den µOp-Cache als "Silver-Bullet" geeinigt, plus eventuell noch nen größeren WCC. Was anderes kanns eigentlich fast nicht mehr sein.

Wenn man sieht, dass der Conroe mit dem ersten µOp-Puffer/Loop-Detektor und Memory Disamb. (Ich kürz das mal ab sofort als "MD" ab) schneller oder zumindest gleichauf mit den K10 waren, die den Vorteil eines IMC hatten, dann bleibt bei nem Bulldozer mit ebenfalls IMC und MD nicht mehr viel übrig.
Ja die Pipes sind nur noch 2fach, statt 3fach, aber erstens bringt das sowieso nicht soooviel und zweitens wurden dafür die Scheduler-Fenster viel größer. Alleine das müsste es eigentlich ggü. den 3fach Pipes eigentlich schon rausreißen.
Einzige andere Baustelle außer dem µOp Cache ist der kleine L1-WT-Cache, deswegen oben der Tipp mit dem größeren WCC.
Zu mehr sind wir eigentlich nicht gekommen, abgesehen von der schlechten Softwareversorgung mangels FMA-Software, aber das ist dann eben ein Softwareproblem.

Man kanns auch andersherum, aus Intel-Sicht, sehen. Was hat Intel seit dem Conroe den Großartiges geändert? Sie haben beim Nehalem eigentlich nur den IMC nachgerüstet, Hyperthreading eingebaut sowie die Cachehierarchie etwas geändert. Dann bei Sandy dem Loop-Detektor noch nen ähnlich gestrickten riesen-µOp-Puffer *zusätzlich* zur Seite gestellt, und den L3-Cache wieder auf Kerntakt-Niveau hochgetaktet. Jetzt bei IvyBridge: Eigentlich Stagnation, nur Feintuning/Shrink.

Innovationen wachsen nunmal nicht auf Bäumen und der letzte große Wurf war neben einem IMC in der letzten Zeit eigentlich nur ein Loop-Detektor / µOp-Puffer und eben MD.

ALso selbst von 2 Seiten betrachtet, muss es wirklich größtenteils der µOp-Puffer sein, zusätzlich ein paar Prozent aufgrund des L1-Caches. Wenigstens die paar Prozente L1-IPC-Nachteil sollte man aber durch nen höheren Takt wettmachen können.

 

[Duplex]

Die 3Fach Pipes sind afaik durchschnittlich 10% schneller als die 2Fach Pipes, 10% sind 10%.
Und der K8/K10 hat 4x soviel L1D Cache als BD, wenn man das Frontend von BD betrachtet (shared Frontend), dann hat AMD insgesamt einen Rückschritt bei 8 Logisches Prozessoren gemacht.

Frontend > Uop Cache > Decoder
>> Cache Design
28nm Fertigung >>> 4,5Ghz oder 5 Module

AMD hat noch genug Reserven übrig, hauptsache die neuen Teams bauen keine scheisse

 

[Opteron]

Die 3Fach Pipes sind afaik durchschnittlich 10% schneller als die 2Fach Pipes, 10% sind 10%.

Jo und nu rechne mal noch die OoO-Tiefe mit ein. Beim K10 maximal 8Takte pro Pipe, beim BD max 40 Takte für beide Pipes. Viel Spass.
Kurz: Teilbetrachtungen sind bei komplexen Gebilden wie Mikroprozessoren die flasche Methode. Damit kommt man nicht weiter.

 

[Duplex]

Ja deswegen haben sich auch die Entwickler auf das 2+2 Design geeinigt, langfristig sollte das für eine ausreichende skalierung genügen. (Falls SMT später noch eingebaut wird, dann wirds man evtl. ändern, wobei ich diesen Ansatz für unwahrscheinlich halte) Durch einen uop Cache & 2. Decoder erreicht man für den Nachfolger eine bessere Modul skalierung als der Vorgänger, deshalb sollte ein halfnode Prozess bei Steamroller erstmal ausreichen.

 

[sompe]

Nehalem hat 25-30% mehr IPC als der Core2, also deutlich schneller und nicht gleich schnell, Core2 & Shanghai waren bzgl. IPC ähnlich.

Das waren bei ca. gleichen Grundtakt und Office/Multimedia eher durchschnittliche 20% und das inkl. HTT und Taktsteigerung per Turbo. Bei Spielen fiel er gar zurück.
http://www.computerbase.de/artikel/...l-core-i7-920-940-und-965-extreme-edition/25/
Den größten Sprung bekam er offenbar von der Verdoppelung der logischen Kerne per HTT und dem IMC.

Der Rest kam später per optimierter Software, ein Punkt der beim Bulli vermutlich mehr oder weniger wegfallen wird.

 

[boxleitnerb]

Schaut man auf aktuelle Spielebenchmarks, kommen die 30% schon hin.

 

[sompe]

Schau mal auf den letzten Absatz... *g*

 

[boxleitnerb]

Ich denke vielmehr, in den damaligen Tests waren die Grafikkarten nicht stark genug
Mit einer 9800GTX hat man auch damals niemanden mehr hinterm Ofen hervorgelockt. Heutige Karten sind viel schneller die CPUs im Vergleich dazu haben eher mäßig zugelegt.

 

[Byce]

Hallo

zunächst möchte ich sagen, dass ich beruflich aus einer ganz anderen Ecke komme und mich nur hobbymäßig vorallem mit Technologie und Funktionsweise von Hardware beschäftige.
Ich habe gerade zwei Gedanken und wollte mal fragen ob sowas überhaupt möglich ist, bzw ob es was bringen würde:

Gedanke 1: Wäre es möglich den Decoder im Frontend ähnlich wie bei den Shadern der Fermichips mit einem Hotclock - also dem doppelten Takt - zu betreiben? Könnte man damit die Integerkerne besser auslasten? (abgesehen von der sehr Frequenz mit der dieser arbeiten müßte)

Gedanke 2: Funktioniert es, dass beide Integer Kerne eines Moduls ihre Berechnungen asyncron durchführen, also nicht zum selben "Clock" sondern quasie mit einem Abstand von einem halben "Clock". Könnte man dadurch die Latenzen verkürzen, die bei einer Abhängigkeit von zwei Threads, welchen auf den beiden Integern eines Moduls verteilt sind, entstehen?

Grüße, Byce

 

[sompe]

@boxleitnerb
Und warum sind die Core2 dann schneller?
Das Hauptproblem war damals SMT in Verbindung mit der Kernverteilung des Windows Schedulers und die Anzahl der genutzten Kerne.....siehe das gute Abschneiden der Core 2 Dualcore Modelle. Die Größte Mehrleistung erzielte er bei Multicore Anwendungen durch das SMT. Ein Schelm der da Parallelen zum Bulli sieht.

 

[boxleitnerb]

4% würde ich jetzt nicht unbedingt als schneller ansehen, das fällt ja schon fast unter Messfehler. In aktuellen Reviews gibts durchaus auch Werte ohne SMT und Turbo, selbst so kommen dann auch die 30% hin.

 

[sompe]

Anderer Test mit ähnlichem Ergebnis....schau dir mal die Konvertierungsergebnisse bei iTunes an.
http://www.computerbase.de/artikel/...l-core-i7-920-940-und-965-extreme-edition/17/
Der i7-965 XE ist nur 4-8 % schneller als der QX9770, welcher mit gleichem Grundtakt läuft aber der etwas höher getaktete E8600 überholt den Quad, wodurch der test nur 1-2 Kerne genutzt haben kann.
Schaut man sich dann noch den Test vom Turbo Mode im Detail an und bedenkt das dessen Taktsteigerung bei den meisten Programmen ca. 4% brachte dann schaut das Ergebnis für die IPC selbst alles andere als prickelnd aus.
Nicht umsonst sah ds Gesammtergebnis mit gerade einmal +7% für den i7-965 XE alles andere als gut aus.

Im laufe der Zeit wurde natürlich stärker auf diese Architektur optimiert und die Anzahl der genutzten kerne nahm zu, wodurch der i7 natürlich weiter zulegen konnte aber genau das wird ja immer wieder für den Bulli vehement abgestritten.

 

[boxleitnerb]

Dass IPC eine Größe ist, die von der Software abhängig ist, ist klar. Ich bin aber ziemlich sicher, dass wenn man damals gescheit getestet hätte, auch gleich entsprechende Ergebnisse rausgekommen wären (jetzt in Spielen, Anwendungssoftware ist nicht so mein Gebiet, da kann und will ich nicht mitreden):

35%:
http://www.pcgameshardware.de/CPU-H...5-XE-Nehalem-CPUs-im-Benchmark-Test-665169/3/

25% (920 vs 9550 gleicher Takt):
http://www.3dcenter.org/artikel/intel-core-i5-750-lynnfield-review/benchmarks-far-cry-2

33% (wie oben):
http://www.3dcenter.org/artikel/intel-core-i5-750-lynnfield-review/benchmarks-gta-iv

 

[y33H@]

Wie bereits erwähnt, Nehalem war nach dem Core 2 der größe IPC-Sprung.

 

[gruffi]

Und das mit Bulddozers Modulbauweise im Zusammenhang mit HSA ist meiner Meinung nach immer noch unclever. Wenn ich serielle Aufgaben von einer CPU ausführen lassen will und parallele von einer GPU, dann brauche ich CPU-Kerne mit möglichst hoher SingleThread Leistung.

Wieso das? Und warum soll die Modulbauweise nicht gut für HSA sein? Irgendwie wirfst du mir hier zu viele Sachen durcheinander, wo ich keinen direkten Zusammenhang sehe.

Da wir uns im Bereich des sinkenden Grenzertrags bewegen kann es einfach nicht heissen:
"Nö, das kann der BD doch auch."
Ja er kann es auch - aber SCHLECHT.
Er erkauft es sich durch eine längere Pipe.

Längere Pipeline im Vergleich zu was? Die Länge der Bulldozer Integer-Pipeline liegt im Bereich von Nehalem/SB. "Erkauft" trifft es da nicht wirklich.

Irgend ein AMD-ehemaliger hat sich doch bei BD offen zu Wort gemeldet und angeprangert, dass bei BD zu viel synthetisch erzeugt wird.

Der hat da aber vermutlich nur ins Blaue geraten, ohne konkrete Kenntnisse. Als es in die heisse Designphase von Orochi ging, war da doch gar nicht mehr an Bord. Man sieht auch am Orochi Die Shot, dass da nicht viel synthetisiert ist. Der Ex-Mitarbeiter hat wohl einfach alles über einen Kamm geschert, ohne zu differenzieren. Bobcat ist stark synthetisiert, Bulldozer eher nicht.

Man schimpft doch, dass der BD-Core so riesig ist (flächenmäßig) im Vergleich zum Sandy und dabei hat der Sandy eine höhere Leistung

Wenn du mit BD-Core ein Modul meinst, das nimmt sich kaum was. BD Modul und SB Kern sind fast gleich gross. Das BD Modul ist minimal grösser. Hat allerdings auch etwas Logik an Bord, die SB nicht hat, wie SSE4a, FMA, XOP, etc. Und wenn du beides auslastest, also jeweils 2 Threads auf BD Modul und SB Kern, dann ist SB nicht schneller.

Nehalem hat 25-30% mehr IPC als der Core2

Vielleicht bezogen auf den gesamten Prozessor, inklusive SMT. Pro logischem Prozessor waren das optimistisch gesehen nur irgendwas um die 10-15%. Einiges wurde diesbezüglich in Tests auch "verwässert", da Nehalem zum ersten mal Turbo mitbrachte. Und Spielebenchmarks interessieren bei Vergleichen von Architekturen wie üblich natürlich nicht. Zu stark ist der Einfluss von GPU, Treiber, I/O, etc.

 

[y33H@]

Ich habe gehört, bei manchen Leuten und Webseiten liegt der Fokus auf Spielen, ergo ist die IPC für eine nicht zu verachtende Anzahl an Menschen hier sehr interessant.

 

[gruffi]

"Hier" sicherlich nicht. P3D ist schliesslich keine Seite, die auf Spiele fokussiert ist. Genauso wenig werden CPU Architekturen normalerweise für Spiele entwickelt. Und Nehalem schon mal gar nicht. Der wurde ja vom Entwicklerteam aus Oregon gebastelt, welche vor allem für Intels Servergeschichten verantwortlich sind. Und dort lag auch der Fokus von Nehalem.

Das ist hier aber alles off-topic. Hier geht's um Bulldozer. Also würde ich vorschlagen, ihr stellt die IPC Diskussionen zu Nehalem ein.

 

[gruffi]

Es wurde hinlänglich gezeigt und bewiesen. Von Leuten, die sich wesentlich besser mit der Materie auskennen als du und ich. Es ist ja nicht mein Problem, wenn du das beharrlich ignorierst.

Ich finde es eher erstaunlich, dass einige Leute nie müde werden, ständig irgendwelche absurden IPC Differenzen basierend auf Spielen zu proklamieren. Vor allem in solchen Threads, wo man allgemein über Architekturen diskutiert und Spiele überhaupt keine besondere Relevanz haben.

Kleiner Tipp, wenn ihr Spielefreaks in Zukunft von IPC redet, nennt es doch richtig, also "IPC in Spielen". Und wenn sich "normale" Leute über IPC unterhalten, dann braucht ihr auch nicht euren Senf dazugeben, weil eben nicht IPC in Spielen gemeint ist.

 

[sompe]

Dass IPC eine Größe ist, die von der Software abhängig ist, ist klar. Ich bin aber ziemlich sicher, dass wenn man damals gescheit getestet hätte, auch gleich entsprechende Ergebnisse rausgekommen wären (jetzt in Spielen, Anwendungssoftware ist nicht so mein Gebiet, da kann und will ich nicht mitreden):

35%:
http://www.pcgameshardware.de/CPU-H...5-XE-Nehalem-CPUs-im-Benchmark-Test-665169/3/

25% (920 vs 9550 gleicher Takt):
http://www.3dcenter.org/artikel/intel-core-i5-750-lynnfield-review/benchmarks-far-cry-2

33% (wie oben):
http://www.3dcenter.org/artikel/intel-core-i5-750-lynnfield-review/benchmarks-gta-iv

Da hast du dir ja ein paar schöne Tests rausgesucht.

Der zweite Test (Far Cry 2) nutzt offensichtlich mehr als 2 (E8500 vs. Q9550) oder gar mehr als 4 Kerne (i7-920 mit und ohne HTT) und es kommt eine Szene zum Einsatz die aufgrund vieler Computergegner auf CPU Last ausgelegt ist. Das er schneller ist wenn die zusätzlichen virtuellen Kerne auch wirklich genutzt werden bestreitet ja auch keiner.
Des weiteren kam der zweite und dritte Test 10 Monate nach dem Start des Nehalem raus...viel Zeit für Software Optimierungen, dessen Wirkung auch keiner bestreitet.

Beim ersten Test wurden sehr GPU schonende Grafikeinstellungen genutzt dessen Praxisrelevanz für micht immer etwas fraglich ist. Wer stellt sowas freiwillig bei der Hardware ein...?
Beim World in Conflict Test steht der QX9770 dem i7-965 in den min FPS (wird ja immer wieder als Indiz der CPU Begrenzung genannt) in nichts nach, erst wenn SMT abgeschaltet wird kann der i7 hier punkten.
Bei dessen Far Cry 2 scheint man mit dem i7 in einem Limit fest zu hängen, da zwischen den i7 Modellen kaum ein Unterschied besteht.


Jetzt also nochmal meine konkrete Frage.
Warum muss sich der Bulli sofort mit der aktuellen Software behaupten können wärend man dem Nehalem offensichtlich Zeit für Softwareanpassungen einräumt und warum spricht man dem Bulldozer Design die Relevanz genau der Benchmark Ergebnisse ab bei denen selbst der Nehalem bei Erscheinen erst Punkten konnte? (Multicore Tests)
Erste Tests mit FMA haben ja schon gezeigt das hier viel Rechenleistung durch die Software brach liegt und er damit mit Intels SB durchaus auf augenhöhe liegt, wärend man von AVX deutlich weniger als Intel profitiert. Ich bin mir allerdings auch relativ sicher das wir die Einpflegung von FMA4 in die normale Software nicht allso schnell erleben werden, denn bekanntlich unterstützt das noch nicht einmal der Nachfolger des IB....wie so viele Befehlserweiterungen die AMD einführen wollte.
Ich für meinen Teil schätze anhand des ht4u Tests das bereits durch den fehlenden FMA Support dem Bulldozer Design bereits ca. 20% Rechenleistung pro Kern flöten gehen.

 

[Opteron]

Noch zum Thema Flaschenhälse, sieht so aus, als ob wir (und unsere Quellen) richtig lagen:

http://www.planet3dnow.de/vbulletin/showthread.php?t=407457

Da wird eigentlich alles angegangen. Größerer L1I Cache, (höchstwahrscheinlich ein Loop-Puffer), dezidierte Dekoder, deutlich verbessertes L1-Store. Passt. Steamroller kann kommen. Zur weiteren Diskussion hat complicated gerade auch noch nen frischen Thraed aufgemacht:

http://www.planet3dnow.de/vbulletin/showthread.php?t=407458

 

[boxleitnerb]

Es wurde hinlänglich gezeigt und bewiesen. Von Leuten, die sich wesentlich besser mit der Materie auskennen als du und ich. Es ist ja nicht mein Problem, wenn du das beharrlich ignorierst.

Ich finde es eher erstaunlich, dass einige Leute nie müde werden, ständig irgendwelche absurden IPC Differenzen basierend auf Spielen zu proklamieren. Vor allem in solchen Threads, wo man allgemein über Architekturen diskutiert und Spiele überhaupt keine besondere Relevanz haben.

Kleiner Tipp, wenn ihr Spielefreaks in Zukunft von IPC redet, nennt es doch richtig, also "IPC in Spielen". Und wenn sich "normale" Leute über IPC unterhalten, dann braucht ihr auch nicht euren Senf dazugeben, weil eben nicht IPC in Spielen gemeint ist.

Dazu hab ich in all den Jahre niemals einen Link gesehen von dir. Daher: Einwand abgelehnt.
An der Systemperformance ändert das aber so oder so nix. Deshalb und weil Board, CPU und die Treiber für diese beiden Komponenten untrennbar für den Betrieb zusammengehören, ist die Diskussion eh hinfällig, denn die Ergebnisse stehen ja in unzähligen Tests im Netz fest. Auch in hohen Auflösungen.

Zu deinem kleinen "Tipp":
Das kann ich genauso zurückgeben. Wenn ihr "normalen" (muss die Spitze sein?) Leute euch über IPC oder CPU-Leistung unterhaltet, ist das genausowenig allgemeingültig. Wer sagt mir denn z.B., ob der Bulldozer unter Linux im gcc nicht deshalb so schnell ist, weil er nicht einen besonderen Chipsatztreiber benutzt? Oder weil die SSD mit reinspielt? Oder weil ihm nicht-im-Prozessor-sitzende I/O einen Vorteil gibt? Das geht auch so herum, mein Lieber! Auslastungsnachweise bitte.

Außerdem sieht das AMD selbst anders als du. Aus den P3D-News zu Steamroller:

Unter dem Strich soll somit eine Steigerung von +30% Ops pro Cycle herauskommen. Geht man großzügiger-weise von einem x86 zu µOp-Verhältnis von 1:1 aus, könnte man im (aller)besten Fall dann auch von einer IPC Steigerung um diesen Betrag ausgehen. AMD gibt an diese Steigerung bei einem Applikationsmix aus "digital media", "productivity" und Spielen berechnet zu haben.

Da hast du dir ja ein paar schöne Tests rausgesucht.

Danke

Der zweite Test (Far Cry 2) nutzt offensichtlich mehr als 2 (E8500 vs. Q9550) oder gar mehr als 4 Kerne (i7-920 mit und ohne HTT) und es kommt eine Szene zum Einsatz die aufgrund vieler Computergegner auf CPU Last ausgelegt ist. Das er schneller ist wenn die zusätzlichen virtuellen Kerne auch wirklich genutzt werden bestreitet ja auch keiner.
Des weiteren kam der zweite und dritte Test 10 Monate nach dem Start des Nehalem raus...viel Zeit für Software Optimierungen, dessen Wirkung auch keiner bestreitet.

Ich bezog mich auf die 44fps, also ohne HT. Das Ergebnis mit HT habe ich in der Rechnung nicht einbezogen. Sorry, das hat gefehlt.
Hier ein deutlich früherer Test mit GTA 4 mit demselben Ergebnis:
http://www.pcgameshardware.de/CPU-H...weit-vor-Core-2-Quad-im-CPU-Benchmark-671956/

Far Cry 2 zum Release:
http://www.anandtech.com/show/2658/19

Schon 15%, und das bei nur mittleren Details und dem "Ranch"-Benchmark statt dem "Action"-Benchmark - letzterer hat Gefechte mit der KI, geht also weniger auf die Grafikkarte. Hätte anandtech gleich dies gebencht, wären hundertprozentig auch 25+% rausgekommen.

Beim ersten Test wurden sehr GPU schonende Grafikeinstellungen genutzt dessen Praxisrelevanz für micht immer etwas fraglich ist. Wer stellt sowas freiwillig bei der Hardware ein...?
Beim World in Conflict Test steht der QX9770 dem i7-965 in den min FPS (wird ja immer wieder als Indiz der CPU Begrenzung genannt) in nichts nach, erst wenn SMT abgeschaltet wird kann der i7 hier punkten.
Bei dessen Far Cry 2 scheint man mit dem i7 in einem Limit fest zu hängen, da zwischen den i7 Modellen kaum ein Unterschied besteht.

Wer sowas einstellt? Jemand, der in einem Shooter gerne die 60fps hat. Mit höherer Auflösung und AA/AF hätte die 4870 alle CPUs zusammengerückt und der Leser wüsste nicht, dass er mit CPU A 60fps erreichen kann mit CPU B nicht. Einstellungen runterdrehen ist kein Verbrechen, weißt du?
Zudem könnte er ja auch eine GTX280 oder mehrere davon haben. Auch für so jemanden wäre der Informationsgehalt des Tests dann Null. Es wäre doch arg schade, wenn man mit solchen realistischen aber unsinnigen Einstellungen den Lesern "vorschreibt", wieviel fps sie "brauchen" oder welche Grafikkarte sie verbaut haben "dürfen". Ich hoffe, du verstehst.

Von min FPS hab ich noch nie was gehalten. Ein einzelner Wert, mag er auch noch so reproduzierbar sein, ist für mich nicht relevant. Dass SMT in Spielen oft leicht bremst, ist hinlänglich bekannt.
Beim FC2 Benchmark bei PCGH erkennt man klar das GPU-Limit. Schwache Grafikkarte, anspruchslose Szene. Sowas liest man leider viel zu oft. Wie das Spiel in anspruchsvolleren Bereichen performt, eben bei Kämpfen (siehe Action Scene), darüber sagt dieser Test gar nix.

Jetzt also nochmal meine konkrete Frage.
Warum muss sich der Bulli sofort mit der aktuellen Software behaupten können wärend man dem Nehalem offensichtlich Zeit für Softwareanpassungen einräumt und warum spricht man dem Bulldozer Design die Relevanz genau der Benchmark Ergebnisse ab bei denen selbst der Nehalem bei Erscheinen erst Punkten konnte? (Multicore Tests)
Erste Tests mit FMA haben ja schon gezeigt das hier viel Rechenleistung durch die Software brach liegt und er damit mit Intels SB durchaus auf augenhöhe liegt, wärend man von AVX deutlich weniger als Intel profitiert. Ich bin mir allerdings auch relativ sicher das wir die Einpflegung von FMA4 in die normale Software nicht allso schnell erleben werden, denn bekanntlich unterstützt das noch nicht einmal der Nachfolger des IB....wie so viele Befehlserweiterungen die AMD einführen wollte.
Ich für meinen Teil schätze anhand des ht4u Tests das bereits durch den fehlenden FMA Support dem Bulldozer Design bereits ca. 20% Rechenleistung pro Kern flöten gehen.

Eine berechtigte Frage.
Der Konkurrenzdruck für den Bulli war/ist größer als damals für den Nehalem. Zu der Zeit hatte Intel schon mit den C2Q "die Hosen an", man war also nicht darauf angewiesen, einen Befreiungsschlag zu führen wie AMD 2011. Zudem war Nehalem ja durchaus auch bei Standardsoftware deutlich schneller als der Vorgänger, nur eben nicht überall. Beim Bulli sieht das etwas anders aus.

 

[gruffi]

Dazu hab ich in all den Jahre niemals einen Link gesehen von dir.

GIDF. Lernt erstmal, für neue Erkenntnisse aufgeschlossen zu sein und zeigt, dass ihr euch wirklich mit der Materie auseinandersetzen wollt. Dann werde ich auch gerne behilflich sein, Tipps zu geben. Bei eurer sturen und abblockenden Haltung sehe ich jedenfalls keine Veranlassung dafür. Daher: Einwand für den Einwand abgelehnt.

An der Systemperformance ändert das aber so oder so nix. Deshalb und weil Board, CPU und die Treiber für diese beiden Komponenten untrennbar für den Betrieb zusammengehören, ist die Diskussion eh hinfällig, denn die Ergebnisse stehen ja in unzähligen Tests im Netz fest. Auch in hohen Auflösungen.

Um Systemperformance geht's hier auch nicht. Vielleicht liest du dir nochmal Überschrift und Startbeitrag des Threads durch. Hier geht es explizit um Zambezi bzw die erste Generation der Bulldozer Architektur.

Zu deinem kleinen "Tipp":
Das kann ich genauso zurückgeben. Wenn ihr "normalen" (muss die Spitze sein?) Leute euch über IPC oder CPU-Leistung unterhaltet, ist das genausowenig allgemeingültig. Wer sagt mir denn z.B., ob der Bulldozer unter Linux im gcc nicht deshalb so schnell ist, weil er nicht einen besonderen Chipsatztreiber benutzt? Oder weil die SSD mit reinspielt? Oder weil ihm nicht-im-Prozessor-sitzende I/O einen Vorteil gibt? Das geht auch so herum, mein Lieber! Auslastungsnachweise bitte.

Was soll an "normalen" eine Spitze sein? Damit waren die Leute gemeint, die eben keine Spielfreaks sind. Vielleicht solltest du mal ein bisschen "normaler" werden und nicht überall Spitzen hineininterpretieren. Und doch, wenn man sich im Kontext der Architektur über IPC unterhält, dann ist das allgemeingültig. Und die Beispiele mit Linux sind natürlich totaler Quark. Das weisst du aber selber. IPC innerhalb der (Kern-)Architektur muss man sich so vorstellen, dass man sämtliche äusseren Einflüsse eliminiert und dann schaut, was übrig bleibt. Wird mit gängigen Testsystemen natürlich nie 100% nachstellbar sein, da man immer äussere Einflüsse hat (RAM, HDD, etc). Mit normalen Anwendungen sind diese aber auf ein Minimum reduzierbar, so dass man brauchbare Ergebnisse erhält. Festplattenzugriffe kann man zB ausblenden beim Zeitnehmen. RAM- und Cache-Zugriff, also Teile des I/O Systems, kann man über die Worksize steuern. All das ist bei Spielen gar nicht oder nur begrenzt möglich. Man kann nun mal nicht einfach RAM und PCIe ausblenden. Genauso wenig lässt sich die GPU vollständig ausblenden. Man kann zwar die Auflösung runterschrauben, das ändert aber am Code nichts. Kommunikation zwischen CPU, GPU, Treiber, Eingabegeräten, I/O usw findet trotzdem statt und sorgt immer wieder für Wartezyklen, gerade CPU-seitig. Und deswegen sind Spiele einfach denkbar ungeeignet, um Schlüsse zur generellen IPC der Architektur herzuleiten. Entweder ihr begreift das endlich mal oder lasst es bleiben. Das wurde nun schon etliche male erläutert. Wenn ihr das partout nicht akzeptieren wollt und immer wieder zerredet, dürft ihr auch von eurem Diskussionspartner nichts erwarten. So ein Verhalten ist einfach nur destruktiv und unvernünftig.

Außerdem sieht das AMD selbst anders als du.

Nö, die sehen das kein bisschen anders als ich. Die schreiben ja, im Gegensatz zu euch, wenn ihr immer allgemein über IPC schwadroniert, ganz konkret hin, worauf sich diese IPC Angabe bezieht. Und dass sie sich ausschliesslich auf Spiele bezieht, steht schon mal gar nicht dort.