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

[Complicated]

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

Ich weiss gar nicht wie oft ich das schon geschrieben habe in Foren - da wird die denkbar schlechteste Software dafür verwendet CPUs zu testen, nur weil man die Auflösung runterschraubt. Und dann wird immer wieder über GPU-Limits, CPU-Limits, PCIe-Limits philosophiert auf Basis von Tests wo die Software(Spiele) das größte Limit darstellt.

Spieletestester testen keine Hardware, sondern lediglich welche Spiele am besten auf bestimmter Hardware laufen. Das ist aber nun mal nicht das am meisten genutzte Szenario von CPUs - das zeigt sich daran wieviel Stückzahl an Highend GPUs verkauft werden.

 

[boxleitnerb]

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.

Stur und abblockend, das beschreibt dich perfekt. Bei jeder Nachfrage zu Quellen und Beweisen wird abgeblockt. Und du hast immer noch nicht gelernt, eigene Formulierungen zu benutzen.
Und davon abgesehen lügst du: Du würdest NIE behilflich sein, weil du es gar nicht willst oder gar nicht kannst.

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.

Passt der gültige Einwand nicht, wird mit Hinweis auf OT abgeblockt. Notiert.

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.

Natürlich ist das eine Spitze. Geh mal zu irgendjemandem hin und sage ihm, er wäre nicht "normal" (ergo "abnormal") oder nenne ihn einen "Freak" der wird sich freuen. Abgesehen davon ist Spielen heutzutage völlig normal und weit verbreitet, siehe den Umsatz der Spieleindustrie und die Verkaufszahlen von Spielen. Spiele gehören genauso dazu wie alles andere. Ich würde sogar behaupten, es spielen viel mehr Leute als solche, die Videoschnitt betreiben, Programme kompilieren, Serveranwendungen laufen lassen etc.

Zum Rest:
Deine Ausführungen ändern immer noch nichts an der Systemperformance. Wenn du glaubst, der deutliche Performanceunterschied in Spielen fernab des GPU-Limits liegt nicht an der CPU und dass ein (Groß?)teil der Performance in deren Umfeld (Hardware wie Software) "verloren" geht, bitte sehr. Das wäre aber ein extremes Armutszeugnis für AMDs Treiberentwickler und Chipsatzdesigner, denn die haben dann den schwarzen Peter in der Tasche und diese Bremsen all die Jahre lang nicht lösen können.

Mal ernsthaft:
Dass Intel-Systeme meist deutlich schneller sind abseits der Grafiklimits (ich schreibe bewusst nicht CPU-Limit) ist unbestritten. Irgendeine Ursache MUSS es ja haben. Und dann sollte man doch meinen, dass sich irgendjemand damit beschäftigt, um hier für mehr Tempo zu sorgen. Du kannst jetzt über theoretische Ursachen bis zum St.Nimmerleinstag spekulieren, das schafft das Problem aber nicht aus der Welt.

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.

Spiele werden aber mit einbezogen, sprich AMD sieht es im Gegensatz zu dir als legitim an, auch in Spielen IPC zu messen. Was laut dir ja aufgrund der angeblichen vielen externen Einflüsse ja unmöglich/Unsinn/... ist. Ergo stehst du mit deiner Ansicht alleine da.

Ich weiss gar nicht wie oft ich das schon geschrieben habe in Foren - da wird die denkbar schlechteste Software dafür verwendet CPUs zu testen, nur weil man die Auflösung runterschraubt. Und dann wird immer wieder über GPU-Limits, CPU-Limits, PCIe-Limits philosophiert auf Basis von Tests wo die Software(Spiele) das größte Limit darstellt.

Spieletestester testen keine Hardware, sondern lediglich welche Spiele am besten auf bestimmter Hardware laufen. Das ist aber nun mal nicht das am meisten genutzte Szenario von CPUs - das zeigt sich daran wieviel Stückzahl an Highend GPUs verkauft werden.

Nein, es werden nicht CPUs getestet, auch wenn das fast immer umgangsprachlich so genannt wird. Ich kann schließlich nicht eine CPU auf den Tisch legen und die läuft dann alleine. Wenn mr.dude bei einem Recht hat, dann ist es, dass es um das System als Ganzes geht, einzeln funktioniert keine Komponente. Allerdings ist das vielbesungene CPU-Limit auch meistens ein solches, denn in solchen Fällen bewirkt eine reine Kerntakterhöhung der CPU (ansonsten wird NICHTS an Hardware und Software geändert) schon eine (nahezu) 1:1 Erhöhung der fps. Oder eine Erhöhung der Threadzahl. Nenn es von mir aus "System-ohne-Grafikeinfluss-Limit" oder wie es sonst beliebt. Ändert am Ergebnis nunmal nichts.

Ob/wie sehr/wie oft Software ein Limit darstellt, ist doch für jemanden, der keinen Einblick in die Engineentwicklung hat, gar nicht ersichtlich. Zumal es wirklich schlecht optimierte Spiele gibt, wo durch ein Update die Performance stark erhöht werden konnte (Skyrim pre 1.4) und sicher auch solche, wo die Programmierer schon fast alles rausgeholt haben. Pauschal zu sagen "Die Software ist Schuld", ist nicht zielführen und auch nicht richtig.
Im Hinblick auf Limits: Wenn ich z.B. ein Spiel habe, dass schlecht für mehrere Threads optimiert ist (weil die Problemstellung es vielleicht in diesem Fall gar nicht erlaubt) und bei dem ein einziger Thread maximal belastet wird, habe ich natürlich ein Limit, nämlich in dem Fall die pro-Thread-Leistung. Man zieht sich hier gerne an Begrifflichkeiten auf und sicherlich ist die Nomenklatur selten korrekt, aber was als Grundaussage gemeint ist, ist eigentlich immer klar: Mehr Grafikleistung bringt hier gar nichts, es liegt an der CPU. Ob jetzt damit Takt, IPC oder Threadzahl gemeint ist, hängt dann vom Einzelfall ab, wobei Systeme mit CPUs, denen allgemein eine höhere IPC zugesprochen wird, auch in Spielen abseits des Grafiklimits deutlich mehr Leistung (fps) pro CPU-Takt generieren.

Zum zweiten Abschnitt kann ich nur auf meine Ausführungen weiter oben hinweisen. Spiele sind weit verbreitet, unzählige Millionen spielen am PC. Die Verkaufszahlen von Highend-GPUs haben in diesem Kontext doch gar nichts zu melden.

 

[Dr@]

Du kannst jetzt über theoretische Ursachen bis zum St.Nimmerleinstag spekulieren, das schafft das Problem aber nicht aus der Welt.

Ich muss Dich enttäuschen: Wir befinden uns hier in einem sehr theoretischen Thread. Die Ausgangsbasis ist klar und muss nicht ständig wiederholt werden. Der erste BD ist nicht das Gelbe vom Ei und hat eine - im Vergleich zur Konkurrenz - mickrige IPC. <-- Diese Aussage ist absichtlich hart und pauschal.

Das Thema ist hier, woran es liegt. Es liegt dabei in der Natur der Sache, dass die Diskussion theoretisch geführt werden muss, da wir ja schlecht einen simulierten BD zur Hand nehmen können, um an ein paar Stellschrauben zu drehen. Ziel des Threads ist es auch nicht, dass Problem aus der Welt zu schaffen. Das kann schlicht und ergreifend von den Mitgliedern dieses Forums gar nicht geleistet werden.

Ich möchte im übrigen darum bitten, weitere persönliche Anfeindungen sein zu lassen.

 

[mocad_tom]

Sorry es tut mir leid, ich stehe leider grad Arbeitsmässig so unter der Fuchtel.

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.

Anders. Ich hoffe ich mache jetzt nicht das Spiel, das ich bei anderen so hasse(Bullshit-Bingo und aus dem Weg hüpfen) - also sprich es an, wenn es so ist.
Bei Prozessoren gilt eben nicht: "Viel hilft viel"
Ich war immer der Meinung, dass der extrem niedriglatenzige und gleichzeitig große L2 des Core 2 Duo einfach "King" ist (brute force). Sie sind aber quasi auch an ein Designlimit gegangen. Man konnte den großen L2 nicht mehr höher Takten, ohne zusätzliche Cache-Pipeline-Stages (die Cache-Pipeline ist ja auch als Pipeline zu verstehen, vergleichbar der normalen Prozessor-Pipeline) ein zubauen(futsch sind die niedrigen Latenzen).
Nun hat man im Nehalem einen Kompromiss gemacht (eine klare Design-Decision):
L2 wird (deutlich) kleiner, gleichzeitig erhöhe ich das Out-Of-Order-Window sowohl in der Prozessor-Pipeline, als auch in der Cache-Pipeline (es gibt also auch mehr "spekulative Cache-Zugriffe"). Wenn man sich auf Realworldtech den Artikel durchliest, ist man der Meinung wow - der muss ja minimum doppelt so schnell sein.
http://www.realworldtech.com/nehalem/4/
Tatsächlich und das schreibst du ja auch schon, verläuft sich die Steigerung etwas im Sande. Und das selbe Problem haben wir ja auch im BD.

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.

Ich sags mal so:
In Nehalem war ziemlich viel neu trotzdem hat man es geschafft in Benchmarks nicht soo schlecht auszusehen(nicht zuletzt auch deswegen, weil man immer die Benchmark-Ersteller bezirzt hat). Wenn man aber unter die Haube geschaut hat, hatte ich den Eindruck, dass der Core 2 Duo besser mit "Rotz-Code" zurechtkam. Sandy Bridge hat diesen Nachteil behoben.

Ein vergleichbares Problem haben wir doch jetzt mit Bulldozer auch wieder.
Der K10.5 kommt eigentlich recht gut mit "Rotz-Code" zurecht. Der Bulldozer kommt raus und muss sich gegen Sandy ordentlich schlagen. Sandy ist ein Allesfresser, Bulldozer stolpert oft genug (@Opteron wo spürt man da MemDisambiguation?)

Ich will es so ausdrücken:
Nehalem hat spekulatives MemDisambiguation - es half - rein von der Rohleistung müsste er aber abgehen wie Schmidts Katze - das tat er aber nicht

Sandy Bridge hat spekulatives MemDisambiguation - der geht ab - mMn aber deshalb, weil sie die Pipeline kürzen konnten.

Bulldozer hat spekulatives MemDisambiguation - er krankt aber am Nehalem-Syndrom. Auf dem Papier wäre er ein Monster ... zuviel verläuft im Sande.
Bulldozer hatte halt einfach das Problem, dass er mit Sandy konkurrieren musste

Wo bleibt endlich der befreiende BulldozerV2 - der müsste aber eine kürzere Pipeline haben.

Sandy konnte entstehen, weil Intel voll im Saft stand. AMD kann sich mMn einen so riesen Schritt, wie er nötig wäre, gar nicht mehr leisten.

Nehalem auf Sandy war einfach manisch-akribische Hand-/Wert-Arbeit.
Das Team in Isreal hat sich dicke Bonus-Schecks abgeholt (verdientermaßen).
Sandy hatte zwar diesen bescheuerten Chipsatz-Bug, aber im Sandy-Kern habe ich keine großen Bugs vernehmen müssen. MMn ein Indiz mehr, dass dort so vieles so glatt gelaufen ist.

 

[gruffi]

Wo bleibt endlich der befreiende BulldozerV2 - der müsste aber eine kürzere Pipeline haben.

Wieso? Ich sehe hierfür keinen plausiblen Grund. Bulldozer hat eine Integer-Pipeline von 15 Stufen. Das scheint sich recht nahe am aktuellen Optimum zu orientieren. Schau dir doch mal alle x86 Architekturen der letzten 3-4 Jahre an. Alle im Bereich von 14-16 Stufen. K8/K10 hatte mit 12 Stufen weniger, ist aber nicht mehr konkurrenzfähig. Nein, auch gegenüber Bulldozer nicht.

Und wenn man sich die Infos zu Steamroller und der High Densitiy Bibliothek so anschaut, dann hat die veränderte Pipeline von Bulldozer wohl mehr Gründe als einfach nur mehr Takt.

Spoiler

Bei jeder Nachfrage zu Quellen und Beweisen wird abgeblockt. Und du hast immer noch nicht gelernt, eigene Formulierungen zu benutzen.

Dass ich dir bei deiner inakzeptablen Haltung und ständigen Anfeindungen nicht helfen werde, habe ich hoffentlich unmissverständlich klar gemacht. Da sind jetzt Beschwerden unangebracht. Das hast du mit deinem unsäglichen Zerreden von Anfang an, wahrscheinlich weil du lange genug mit Halbwissen in den falschen Kreisen eingelullt wurdest, selbst zu verantworten. Und du hast immer noch nicht gelernt, auf Spitzen zu verzichten.

Und davon abgesehen lügst du: Du würdest NIE behilflich sein, weil du es gar nicht willst oder gar nicht kannst.

Schon klar. Ach Junge, werde erwachsen. Ich bin jedem behilflich, der sachlich übers Thema und mit angemessenem Ton diskutieren gelernt hat. Davon sehe ich bei dir nichts. Ausserdem würde ich vorsichtig sein, andere unberechtigt als Lügner zu bezeichnen. Solche Diffamierungen können schnell nach hinten losgehen.

Passt der gültige Einwand nicht, wird mit Hinweis auf OT abgeblockt. Notiert.

Gültige Einwände werden nicht abgeblockt. Fakt ist, es war kein gültiger Einwand, da off-topic. Daher nicht von Belang. EOS.

Natürlich ist das eine Spitze. Geh mal zu irgendjemandem hin und sage ihm, er wäre nicht "normal" (ergo "abnormal") oder nenne ihn einen "Freak" der wird sich freuen.

Natürlich war es keine Spitze und auch nicht so gemeint. Man sollte vielleicht auch mal auf Satzzeichen achten. Die Anführungszeichen stehen nicht umsonst dort. Und Freak braucht hier niemand falsch zu verstehen. Jeder, der hier unterwegs ist, ist nun mal ein hardwareorientierter Freak. Ich bin da keine Ausnahme. Das ist keine Beleidigung oder Herabwürdigung. Also spare dir diese schon wieder völlig unnötigen und haltlosen Anschuldigungen. Erst recht, wo ich dir das klipp und klar so sage, sollte man das auch akzeptieren können.

Deine Ausführungen ändern immer noch nichts an der Systemperformance.

Und ich kann nur nochmal sagen, dass es hier gar nicht um Systemperformance geht. Aber schön zu sehen, wie du weiterhin das Thema des Threads ignorierst und off-topic Diskussionen mit off-topic Kontext rechtfertigst.

Wenn du glaubst, der deutliche Performanceunterschied in Spielen fernab des GPU-Limits liegt nicht an der CPU ...

Ja, das glaube ich aufgrund von technischen Analysen, abseits bunter Balkendiagramme. Und was anderes habt ihr bisher auch nie bewiesen. Bzw liegt der Unterschied nicht nur an der (Kern-)Architektur, sondern vor allem am I/O Subsystem. Es gibt genügend Vergleiche, die das untermauern und zeigen, dass Intel hier seit Nehalem bessere Latenz- und Durchsatzwerte hat. Die auf Intel ausgerichtete Softwareoptimierung tut natürlich ihr Übriges. Hört sich abgedroschen an. Ist aber nun mal ein nicht zu ignorierender Fakt.

Dass Intel-Systeme meist deutlich schneller sind abseits der Grafiklimits (ich schreibe bewusst nicht CPU-Limit) ist unbestritten. Irgendeine Ursache MUSS es ja haben. Und dann sollte man doch meinen, dass sich irgendjemand damit beschäftigt, um hier für mehr Tempo zu sorgen. Du kannst jetzt über theoretische Ursachen bis zum St.Nimmerleinstag spekulieren, das schafft das Problem aber nicht aus der Welt.

Oder man redet sich künstlich Probleme herbei, wo gar keine sind. Tatsache ist, dass die Unterschiede bei praxisnahen Einstellungen weitaus geringer, teils vernachlässigbar sind. Und ob man nun einen vielleicht 1-2% grossen Nischenmarkt noch beliefert oder nicht, kann sowieso keine Problemlösung sein.

Spiele werden aber mit einbezogen, sprich AMD sieht es im Gegensatz zu dir als legitim an, auch in Spielen IPC zu messen.

Ich habe nie gesagt, dass das nicht legitim wäre. Schon gar nicht, wenn man es auch so deklariert. Du erfindest schon wieder Märchen. Der Vorwurf an euch war, dass ihr allgemein von IPC redet und das dann ausschliesslich mit Spielen begründet. Und das macht Null Sinn und macht ja auch AMD nicht. Deine Ansicht teilt also niemand.

 

[Opteron]

SDer K10.5 kommt eigentlich recht gut mit "Rotz-Code" zurecht. Der Bulldozer kommt raus und muss sich gegen Sandy ordentlich schlagen. Sandy ist ein Allesfresser, Bulldozer stolpert oft genug (@Opteron wo spürt man da MemDisambiguation?)

Kein Wundern, wenn Du nur ne IPC von ~1,0 hast, blockieren sich die Instruktionen mangels Masse sowieso nicht so doll. Sprich, wenn woanders die Hütte brennt nützt Dir Dein eigener MD-Feuerlöscher nicht viel.

Ich will es so ausdrücken:
Nehalem hat spekulatives MemDisambiguation - es half - rein von der Rohleistung müsste er aber abgehen wie Schmidts Katze - das tat er aber nicht

Tipp: Schau mal auf den L3-Takt bzw. dessen Latenz.

Sandy Bridge hat spekulatives MemDisambiguation - der geht ab - mMn aber deshalb, weil sie die Pipeline kürzen konnten.

Ne Du, das lag zu 50% am L3-Takt, zu 40% am dicken µOp-Cache und 10% Rest. Ich hab hier nen Nehalem mit übertakteten L3 (Kern 4,0, L3:3,6) ... der geht auch ganz gut, in den AIDA Speicherbenches lieg ich da auch schön vor nem Sandy@Stock. Bei gleichem Takt ist das L3-Cache Designs des Nehalems etwas besser als Sandys Ringbusdesign.

Noch ne Info: Beim Coremark, der v.a. für Mobilprozessoren verwendet wird schneidet ein SandyB Quad besser als ein Westmere Hex-core ab, da der Coremark so klein ist, dass er komplett in den µOp-Cache passt. Da für den keine 16Byte Grenzen gelten feuert der dann quasi doppelt so schnell die OPs ab, als der normale Decoder.

Wieso? Ich sehe hierfür keinen plausiblen Grund. Bulldozer hat eine Integer-Pipeline von 15 Stufen. Das scheint sich recht nahe am aktuellen Optimum zu orientieren. Schau dir doch mal alle x86 Architekturen der letzten 3-4 Jahre an. Alle im Bereich von 14-16 Stufen. K8/K10 hatte mit 12 Stufen weniger, ist aber nicht mehr konkurrenzfähig. Nein, auch gegenüber Bulldozer nicht.

Noch zum Thema Pipeline: Bin mal gespannt, ob AMD es beim Steamroller dann wie beim Jaguar macht und eine zusätzliche Stufe für den µOp-Cache einführt, oder es irgendwo anders unterbringt. Nachdem man auch mit 1er Zusatzstufe noch schön unter 20 ist, geh ich eher von ner zusätzlichen Stufe aus. Geht ja auch am einfachsten

 

[LoRDxRaVeN]

Aus dem bereits irgendwo hier im Spekulations-Forum verlinkten Artikel von Toms Hardware fand ich folgenden Abschnitt bzw. dem Titel dieses Threads außerst interessant:

‘Technologisch gesehen, auf Transistorebene, gab es das Problem der Unvereinbarkeit’, sagt Macri. ‘Was bei CPUs für hohe Geschwindigkeiten sorgt, verbrät bei einer GPU zu viel Leistung. Umgekehrt bremst das, was GPUs schnell macht, CPUs aber dramatisch aus. Wir mussten daher zuerst einmal versuchen, CPU und GPU auf einen Die zu packen. Wir verfügten über einen schnellen Transistor, der kombiniert mit niederohmigen Metallverdrahtungen ideal für CPUs ist, und über einen mäßig schnellen Transistor, der sich in Kombination mit sehr dünnen und dicht gepackten Metallverbindungen gut für GPUs eignet. Die Seitenansicht des Metallverdrahtungs-Stacks einer GPU sieht wie der Buchstabe T aus. Bei einer CPU sieht er wie der Buchstabe Z aus. Der eine Stack hat einen kleineren Widerstand, der andere eine höhere Packungsdichte. Wir wussten, dass wir beide Designs auf einem einzigen Die unterbringen mussten, denn der Markt belohnt faule Kompromisse nicht, wie zum Beispiel eine langsame CPU oder eine GPU, die zu viel Strom verbraucht oder performancemäßig die Zügel schleifen lässt. Wir mussten beide Designs sehr gut unterstützen. Wir haben diese Barriere sofort gesehen.’

Man stelle sich den Druck auf dem Team vor. Auf dem Spiel stand ein Umsatzvolumen in Milliardenhöhe und die Zukunft der Firma. Das Team fand schließlich heraus, dass der damals übliche 45 nm-Prozess so eine Hybridlösung nicht unterstützen konnte. Er war einfach zu stark in Hinsicht auf die CPU optimiert. In der Folge begann man sich Gedanken zu machen, wie man den im Forschungsstadium befindlichen 32 nm-Silicon-on-Insulator-Prozess so tunen kann, dass er für beide Anwendungsgebiete gut funktioniert. Der 32 nm-Prozess, der heute bei AMD zum Einsatz kommt, beruht überwiegend auf dem Design des Fusion-Teams.

http://www.tomshardware.de/fusion-hsa-opencl-Geschichte-APU,testberichte-241088-4.html

Welches Faktenwissen da dahinter steckt, wäre natürlich äußerst interessant. Sollte es der Realtität entsprechen, ist zumindest ein Teil der "mangelnden Performance von Zambezi" den APUs geschuldet, bzw., dass der 32nm Prozess nicht mehr rein auf die Bedürfnisse einer reinen CPU hin optimiert werden konnte. Aber leider (?!) liest sich der Text ein wenig wie eine Geschichte
Es wurde ja schon mal vor einigen Monaten irgendwo berichtet, dass Llano deshalb solche Probleme hat, da wenn man gute Yields seitens des GPU-Parts erreicht, sich diese des CPU-Parts verschlechtern und umgekehrt. Das passt mMn ganz gut zusammen mit dem Text.

 

[Crashtest]

Folgendes:
AMD hatte ES von Bulldozer und auch Fusion in 45nm SOI - beides ging nicht gut!

Bereits beim Sandtigerprojekt merkte man bei AMD, dass 45nm SOI nicht für das Ziel geeignet seinen -> 32nm wurde hier und da ein wenig angepasst ...

Bei diesem Kompromis, 32nm SOI, mussten leider einige CPU-Verbrauchsoptimierungen dran glauben, jedoch solls bei 28nm SOI behoben sein ...

Kurz:
32nm SOI ist nicht das gelbe vom EI, 28nm solls richten

 

[FredD]

wo kommen die 28nm SOI nun wieder her?
hierher wohl kaum http://www.globalfoundries.com/technology/28nm.aspx

 

[y33H@]

AMD hatte ES von Bulldozer und auch Fusion in 45nm SOI - beides ging nicht gut!

Quelle? btw ist 28 nm bulk und nicht SOI.

 

[Ramius]

Wieso? Ich sehe hierfür keinen plausiblen Grund. Bulldozer hat eine Integer-Pipeline von 15 Stufen. Das scheint sich recht nahe am aktuellen Optimum zu orientieren. Schau dir doch mal alle x86 Architekturen der letzten 3-4 Jahre an. Alle im Bereich von 14-16 Stufen. K8/K10 hatte mit 12 Stufen weniger, ist aber nicht mehr konkurrenzfähig. Nein, auch gegenüber Bulldozer nicht.

Und wenn man sich die Infos zu Steamroller und der High Densitiy Bibliothek so anschaut, dann hat die veränderte Pipeline von Bulldozer wohl mehr Gründe als einfach nur mehr Takt

Je länger die Pipeline ist, desto stärker verzögert ein fehlinterpretierter Branch-Befehl die Weiterverarbeitung des Programmes, da alle Pipelines und Puffer geleert werden müssen.

Deshalb ist auch eine der wichtigsten Verbesserungen beim Steamroller die verbesserte Branchprediction.

Die High Desitiy Bibliothek soll aber erst beim Nachfolger von Steamroller eingesetzt werden. Zudem führt der Einsatz dieser Bibliothek zu einer geringeren Taktfrequenz.

 

[Dr@]

Zudem führt der Einsatz dieser Bibliothek zu einer geringeren Taktfrequenz.

Das ist zu pauschal formuliert.
Der Einsatz führt zu einer geringeren theoretisch maximalen Taktfrequenz. --> Muss nicht bedeuten, dass die Steamroller-Kerne in realen Produkten mit geringeren Taktfrequenzen arbeiten werden als heutige FX-Modelle. Da spielt dann ja vor allem eben auch die Leistungsaufnahme und die sich daraus ergebende Abwärme eine wichtige Rolle.

 

[Crashtest]

Also laut http://www.globalfoundries.com/technology/advanced_tech.aspx gibts 28/32nm SOI - während 20/22nm noch entwickelt wird ...

Steamroller (CPU) nicht APU soll in 28nm SOI laut hier nicht zu bez. PDFs .... mal sehen in 5 Monaten wissen wir mehr (oder auch schon eher)

 

[hot]

[...]

Das ändert doch nichts daran, dass dude Recht hat. Mit Spielen misst man alles: I/O-Performance, Grafiktreiberperformance, Betriebssystemschwächen in DX usw. aber man misst damit eben nicht die pure Leistung eines Prozessorkerns. Man misst, wie ein Haufen mehr oder weniger optimierter Programme auf der CPU laufen, was aber kaum überschaubar ist. Außerdem bin ich der Meinung, dass man mit puren FPS-Tests die tatsächliche Spieleleistung garnicht wirklich misst. I/O ist viel wichtiger als immer propagiert wird und da wirds dann auch selbst bei meiner Erfahrung mit Sandy-E recht schnell eng (z.B. Skyrim mit Texturepacks und Mods). Da ist es dann einfach egal, ob man einen K10 oder einen Sandy/Ivy hat, der Durchsatz ist durch andere Schwachstellen limitiert. Das gilt auch für andere große Streamer wie Crysis2 oder Diablo3 - hier bringt eine beliebige SSD erheblich mehr als jede noch so tolle CPU.
Ein K10 beispielsweise wirkt bei fast keinem Spiel was ich kenne wirklich limitierend. Gut, die Rundenzeiten bei Civ5 sind auf einem K10-4-Kerner merkbar schlechter als auf einem Sandy, beim Thuban spielts aber dann schon fast keine Rolle mehr, weil das Spiel massiv multithreaded ist. Ansonsten fallen mir noch eher Sachen wie Paradox-Titel ein, die eh schlecht optimiert sind (oder besser waren. Die neue Engine, die bei CK2 erstmals zum Einsatz kommt ist erstmals technisch wirklich gut).

 

[y33H@]

Wenn man Skyrim mit Mods spielt, sind da sehr viele Sachen dabei, die u.a. den Polycount hochtreiben - und damit den CPU mehr belasten. Die Aussage "einfach egal, ob man einen K10 oder einen Sandy/Ivy hat" ist gerade bei Skyrim schlicht falsch *klick mich*

Bei 4 GB Speicher ist I/O in Spielen nahezu egal, es zählen CPU und Grafikkarte. Ist letztere sehr flott oder verringert man das Grafik-Limit, kann man sehr schön CPUs austesten. Selbst 100 MHz Speedbumps.

 

[aylano]

Bereits beim Sandtigerprojekt merkte man bei AMD, dass 45nm SOI nicht für das Ziel geeignet seinen -> 32nm wurde hier und da ein wenig angepasst ...

Bei diesem Kompromis, 32nm SOI, mussten leider einige CPU-Verbrauchsoptimierungen dran glauben, jedoch solls bei 28nm SOI behoben sein ...

Kurz:
32nm SOI ist nicht das gelbe vom EI, 28nm solls richten

Kurz gesagt aus meiner Sicht.
45nm SOI wurde nicht für eine APU (GPU-SOI + CPU-SOI) erforscht und entwickelten --> nix da für APU funktionieren
32nm SOI wurde teils für APU "entwickelt". D.h. 32nm wurde nicht im Labor für APU-erforscht, aber in der Fabrik-Entwicklung vorsuchte man die Labor-Forschungs-Ergebnisse auf die APU "zu biegen" bzw. anzupassen. --> non optimalo funktionieren
Eigentlich sollte erst bei 20nm eine ausgereifte Fertigung für die APU zu verfügung stehen, da dieser auch schon in Labor in diese APU-Richtigung erforscht/berücksichtigt wurde.

Bei 28nm wäre ich mir nicht so sicher, ob dieser schon für die APU entwickelt/berücksichtigt wurde.
1) kommt 28nm von Seitens Bulk, wo grundsätzlich GPU berücksichtigt wurde und bisher nie Hochfrequenz-CPUs.
2) Ist die Globalfoundries-Angabe für 32/28 SOI nicht überzeugten, dass wirklich 32/28nm-SOI zu Verfügung steht. Wobei ich mich in diesem Fall gerne irren möchte.
GF hatte erst vor kurzem 28nm-FD-SOI lizenziert. Aber das hat sich bei meinen begrenzten Wissenshorizont nicht nach einer Nutzung von Hoch-Frequenz-CPUs angehört. Abgesehen, dass mir diese Nutzungs-Möglichkeit von dem vor kurzem lizensierten 28nm-FD-SOI für den Vishera-Nachfolger etwas kurz vorkommt.

AMD hatte ES von Bulldozer und auch Fusion in 45nm SOI - beides ging nicht gut!

Bulldozer @ 45nm kann genauso an K10-B erinnern, wo man ewig lange Bugfixes machte und kaum Zeit für Performance-Optimierungen hatte.
Ein bischen Performance-Optimierungen hatte man damals für K10-B3, was gleich immer +300 Mhz hatte. Für K10-C2 gabs noch mehr Zeit für Performance-Optimierungen und da gabs gleich +400 Mhz sowie ein großes Taktsteigerungs-Potential, was in den nächsten 2 Quartalen mit weiteren +400 Mhz genutzt wurde.

 

[LoRDxRaVeN]

Also laut http://www.globalfoundries.com/technology/advanced_tech.aspx gibts 28/32nm SOI - während 20/22nm noch entwickelt wird ...

Interessante Tabelle - danke!

Wenn man Skyrim mit Mods spielt, sind da sehr viele Sachen dabei, die u.a. den Polycount hochtreiben - und damit den CPU mehr belasten. Die Aussage "einfach egal, ob man einen K10 oder einen Sandy/Ivy hat" ist gerade bei Skyrim schlicht falsch *klick mich*

Also mit solchen Tests habe ich immer meine leichten Probleme. Wie würden denn die Frames aussehen, wenn ich beim CPU-Test statt der (High-End) GTX680 irgendetwas aus dem Bereich HD7800 verbaut habe? Liefern dann die SB und IB immer noch nennenswert mehr FPS?
Du verstehst sicher was ich meine. Es haben sicher mehr eine (eher) Mainstreamkarte, als eine 400 Euro Karte. Tests mit "realitischeren" Hardwarekonfigurationen gibts gefühlsmäßig eher selten, was aber mMn wichtiger wäre, als Test mit High-End Basis (die bei diesem GPU und CPU Test vorliegt)...

 

[y33H@]

Im CPU-Limit, also etwa in einem Starterfeld von Project Cars oder bei sehr vielen Einheiten in Starcraft 2, siehst du ähnliche Resultate. Tests mit "realistischeren" Hardware-Konfigurationen sind bei sauberen CPU- und GPU-Tests eigentlich nicht nötig (kosten aber extrem viel Zeit), da die Schnittmenge diese Informationen ergibt - ein bisschen Transferleistung ist halt nötig. Am Ende hat man Budget X für alle oder eine Komponente und CPU-Test ohne Grafiklimit ist die perfekte Kaufberatung.

 

[gruffi]

Spoiler

Bei 4 GB Speicher ist I/O in Spielen nahezu egal

I/O ist wesentlich mehr als RAM. Dazu zählen zB auch Interrupts und Busse wie PCIe. I/O ist daher alles andere als egal für die Performance. Wie stark der Einfluss ist, hängt dann von den Settings ab. Selbst der Uncore Bereich der CPU gehört teilweise zu I/O. Man sollte das und die Kerne differenzieren, wenn man über die Kernarchitektur diskutiert.

 

[Bobo_Oberon]

... Bei 28nm wäre ich mir nicht so sicher, ob dieser schon für die APU entwickelt/berücksichtigt wurde.
1) kommt 28nm von Seitens Bulk, wo grundsätzlich GPU berücksichtigt wurde und bisher nie Hochfrequenz-CPUs.
2) Ist die Globalfoundries-Angabe für 32/28 SOI nicht überzeugten, dass wirklich 32/28nm-SOI zu Verfügung steht. Wobei ich mich in diesem Fall gerne irren möchte.
GF hatte erst vor kurzem 28nm-FD-SOI lizenziert. Aber das hat sich bei meinen begrenzten Wissenshorizont nicht nach einer Nutzung von Hoch-Frequenz-CPUs angehört. Abgesehen, dass mir diese Nutzungs-Möglichkeit von dem vor kurzem lizensierten 28nm-FD-SOI für den Vishera-Nachfolger etwas kurz vorkommt. ...

So grottig kann GlobalFoundries 28nm Produktkorb gar nicht sein, wenn Qualcomm neben TSMC nun schnell auch weitere Fonudries Aufträge für 28nm SoC-Mobilfunkchips vergeben hat. Dabei war UMC (hört hört!!!) und eben auch die Dresdner* Chipfertiger

MFG Bobo(2012)


* = im Auftrag der arabischen Herren aus Abu Dabi

 

[aylano]

Ich dachte bei Hochfrequenz-CPUs an 4Ghz-CPUs, wie sie bei x86 @ Turbo üblich sind.
Nicht an 1-2 Ghz-SoC. Irgendwie habe ich so SoC mit bis zu 2,4 Ghz (oder gar fast 3,0 Ghz) mit 28nm-Bulk in Erinnerung, die bessere Werte als TMSC aufwiesen.
Aber das sagt eben alles noch nicht aus, ob GF-28nm für APU deutlich besser ausbalanziert ist als 32nm-SOI. Und wissen tun wir es wahrscheinlich eh erst bei 20nm.

Es wäre logisch, wenn 28nm (voraussichtlich Bulk) besser wäre als 32nm, da sonst AMD kaum 28nm nutzen würde. Aber eigentlich muss es nicht. Denn AMD hätte genauso vorteile, wenn 28nm-Bulk genauso Energie-Effizienz wäre wie 32nm-SOI, aber wegen 28nm-Bulk deutlich Flächen-Effizienter, was geringere Die-Kosten bedeutet.

 

[LoRDxRaVeN]

Es wäre logisch, wenn 28nm (voraussichtlich Bulk) besser wäre als 32nm, da sonst AMD kaum 28nm nutzen würde. Aber eigentlich muss es nicht. Denn AMD hätte genauso vorteile, wenn 28nm-Bulk genauso Energie-Effizienz wäre wie 32nm-SOI, aber wegen 28nm-Bulk deutlich Flächen-Effizienter, was geringere Die-Kosten bedeutet.

Wo sich aber natürlich die Frage stellt, wie gut der neue Prozess anläuft und sich entwickelt. Wenn die Fehleranfälligkeit höher ist wie beim doch schon seit einiger Zeit laufenden 32nm Prozess, ist es ja nichteinmal zwangsweise billiger...
Ohne Zahlen zu kennen, ist das alles beschissen zu beurteilen

 

[Complicated]

Deshalb ist auch eine der wichtigsten Verbesserungen beim Steamroller die verbesserte Branchprediction.

Naja soweit ich das verstehe haben aktuelle CPUs bei der Branch Prediction eine Trefferquote um die 98% - zumindest laut Wiki-Artikel:
http://de.wikipedia.org/wiki/Branch_Prediction#Funktionsweise

Die dynamische Sprungvorhersage geschieht zur Laufzeit durch eine elektronische Verschaltung innerhalb der CPU. Sie benutzt verschiedene Techniken zur Erzeugung einer Vorhersage. Ihre Vorhersagegenauigkeit liegt bei bis zu 98 %. Die einfachste Methode spekuliert anhand der Sprungrichtung: Sprünge im Programmcode zurück sind in der Regel Schleifen, die oft mehrfach durchlaufen werden, sodass bei dieser prophylaktisch die Pipeline mit dem zurückliegenden Code gefüllt wird.

Da die "Missprediction" um 30% reduziert wurde, würde dies eigentlich kaum Auswirkung haben - von 98% auf 98,6 % verbesserte Trefferquote liest sich halt weniger spektakulär.

 

[LoRDxRaVeN]

Hmm, und woher hast du, dass diese bis zu 98% auf aktuelle x86 CPUs zutrifft? Ich muss aber zugeben, dass ich jetzt aber nicht alles gelesen habe.

Nachtrag:

Entnimmst du das dem Abschnitt:

Das Verfahren findet z. B. im AMD Athlon und Pentium III Anwendung.[1]

?

 

[Lynxeye]

Anand hatte dazu mal einen Artikel.

Die 98% sind je nach Code schon zu erreichen. Von den reinen Zahlen hört sich 30% von 2% nach nicht gerade viel an. Allerdings muss bei jedem falsch vorhergesagtem Sprung die komplette Pipeline geleert werden, welche beim BD ja länger ist als beim K10. Dazu kommen dann noch falsch geladene Daten durch den Prefetcher und schon kann so ein kleines bisschen falsch liegen zu größeren Performaceeinbußen führen.