AMD gibt weitere Informationen zu Carrizo bekannt

iToms

Redakteur
Thread Starter
Mitglied seit
25.11.2011
Beiträge
2.016
<p><img style="margin: 10px; float: left;" alt="AMD Logo 2013" src="/images/stories/logos-2013/AMD_Logo_2013.jpg" height="100" width="100" />Mit der <a target="_blank" href="index.php/news/hardware/prozessoren/30335-amd-carrizo-kaveri-nachfolger-im-detail.html">Carrizo-APU</a> will der kalifornische Chipdesigner <a target="_blank" href="http://www.amd.com/de-de">AMD</a> aus <a target="_blank" href="http://here.com/37.3810748,-121.9924109,13,0,0,normal.day">Sunnyvale</a> 2015 die vierte Generation seiner Accelerated Processing Units, kurz: APU, ins Leben rufen. Nachdem 2011 Llano erstmals die Verschmelzung von CPU und GPU auf einem Die aus dem Hause AMD zeigte hat sich bis heute viel getan.</p>
<p>Bestanden die ersten APUs noch aus getrennten CPU- sowie GPU-Parts hat sich über die Jahre...<br /><br /><a href="/index.php/news/hardware/prozessoren/33436-amd-gibt-weitere-informationen-zu-carrizo.html" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich denke du kannst hier nicht wirklich von "echten" und "unechten" Kernen sprechen. Sind beides halt unterschiedliche Konzepte.

Aber Puma+ Kerne haben einen 'klassischen' Aufbau mit einer Integer-Einheit und einer FPU sowie dem ganzen Kladderadatsch drumherum. Lediglich der L2-Cache wird unter allen Kernen geteilt.
Puma+ ist auch nur eine Weiterentwicklung der 'Jaguar'-Kerne die auch in den aktuellen Konsolen zum Einsatz kommen.

Edit:

Huch, wo ist dein Post hin o_O
 
Wenn sie denn ENDLICH mal für FM2+ ne APU/CPU mit L3 Cache bringen würden... aber neeeein... man muss ja die vom Aussterben bedrohte AM3+ Plattform am Leben erhalten indem man ihr neben den 2+ Modul-CPUs auch noch den L3 Cache vorbehält... :wall:


Ich packs einfach nich. :shake:


Lg

Marti
 
Es wird sogar der L2 Cache beschnitten :

"Auch hat AMD augenscheinlich den L2-Cache der APUs halbiert, was zu etwa 23 Prozent kleineren Kernen führt."

Der offensichtliche Grund :

"AMD scheint mittlerweile die gesamte Entwicklung seiner Mikroprozessoren auf ein Ziel zu treiben: Effizienz"

AMD ist im High-End Bereich nicht mehr konkurenzfähig, also versuchen sie die APU's möglichst Energieeffizient zu designen.
Hoffentlich sammeln sie Erfahrungen damit, vielleicht wird Zen 2016 wiedermal beides. Schnell und sparsam.
 
I
Edit:

Huch, wo ist dein Post hin o_O

habe ich mich auch gerade gefragt :d

Und ja der Falx hat die sache von Pirate gut beantwortet.

Zen soll laut den jetzigen AMD statements Primär auch auf Effizienz getrimmt sein.

ich erwarte zwar einen kleinen IPC zuwachs gegenüber Bulldozer, aber keine Takterhöhung.
 
"Auch hat AMD augenscheinlich den L2-Cache der APUs halbiert, was zu etwa 23 Prozent kleineren Kernen führt."

Das ergibt allerdings wenig Sinn. Erstmal wissen wir nicht, ob sich diese 23% auf ein Modul mit oder ohne L2 beziehen. Wenn ohne L2 gerechnet wurde, können die 23% logischerweise nicht durch den halbierten L2 kommen. Aber selbst inklusive L2 geht die Rechnung nicht auf. Man darf nicht vergessen, Excavator wird gegenüber Steamroller sicherlich einiges ein zusätzlicher Logik mitbringen (ISA Erweiterungen, 256-bit FPU (?), aufgestockte Funktionseinheiten und Puffer, bessere Stromsparmechanismen, etc). Steamroller legte gegenüber Bulldozer um über 10% zu (236M vs 213M Transistoren). Nehmen wir mal an, Excavator wird weitere 10% gegenüber Steamroller drauflegen. Dann würde die Modulgrösse inklusive L2 bei gleicher Packdichte von 29,5 auf 32,5 mm² steigen. 1 MB L2 kostet bei Steamroller 5,4 mm². Blieben also immer noch 27,1 mm² übrig. Was lediglich etwa 8% kleiner als Steamroller wäre. Ein Grossteil der geringeren Fläche wird daher vermutlich nicht durch die Verkleinerung des L2, sondern durch HDL gewonnen. Selbst wenn die Transistorlogik mit Excavator um einen kleineren Prozentsatz oder gar nicht steigt, könnte man die Grösse trotzdem nicht alleine durch die Halbierung des L2 um 23% verringern.


Wenn sie denn ENDLICH mal für FM2+ ne APU/CPU mit L3 Cache bringen würden... aber neeeein... man muss ja die vom Aussterben bedrohte AM3+ Plattform am Leben erhalten indem man ihr neben den 2+ Modul-CPUs auch noch den L3 Cache vorbehält...
Was willst du denn mit L3? L3 ist was für Server. Consumerprozessoren brauchen keinen L3. Der nimmt nur unnötig Platz weg ohne nennenswerte Performancevorteile. Ein Taktupdate von 100-200 MHz bringt normalerweise mehr. Und vor allem bringt es in jeder Situation was. Mehr Cache bringt nur dann was, wenn eine Anwendung genau in diesem Bereich arbeitet. Also die Arbeitsdaten zu gross für das nächstkleinere Cachelevel sind, aber noch klein genug um nicht ständig auf den RAM zugreifen zu müssen. Verbesserungen wie HBM entschärfen die RAM Problematik in Zukunft sowieso. Bei 8 MB L3 in 28nm reden wir hier immerhin von 40-50 mm². Das ist nicht wenig.

Der Cache der Jaguar CU ist eigentlich fast optimal für Consumerprozessoren. 2 MB shared L2 pro 4-Thread Cluster. Das könnte ich mir auch für zukünftige Performancedesigns auf K12/Zen Basis vorstellen. Für das Transistorbudget eines grossen L3 nehme ich lieber mehr Kerne (CUs) / bessere Funktionalität. Da könnte man zB locker eine APU mit 3 statt 2 Modulen designen, die trotzdem noch kleiner und damit kostengünstiger herzustellen wäre.
 
Ich glaube nicht das HBM dazu führt das Cache an bedeutung verliert, eher im Gegenteil.
Der Cache ist dazu da, latenzen beim Speicherzugriff zu minimieren. HBM wird einen hohen Durchsatz mitbringen durch die breite Anbindung, aber durch den geringeren Takt erwarte ich da absolut keine Wunder was die Latenz angeht.
Wenn L3 cache in Consumerprozessoren überflüssig ist, was willst du denn dann mit mehr Kernen? Die sind in meinen Augen wenn das erste Argument zählt noch überflüssiger.
 
Je näher der Speicher an der CPU, desto niedriger die Latenz. Das hat mit Takt nix zu tun.
 
Zuletzt bearbeitet:
Natürlich hängt die Latenz mit dem Takt zusammen.
Die Latenz misst man in Zeit nicht in Zyklen. Wenn ich also optimalen Speicher hätte der jeden Takt gelesen oder beschrieben werden könnte und den betreibe ich mit 1Hz dann ist meine Latenz 1 Sekunde.
Egal wie nah oder weit weg von der CPU. Ich kenne die finalen HBM specs nicht, aber ich meine da waren mal Gerüchte mit einem Takt von 500MHz oder so.
Das bedeutet nicht zwangsläufig eine schlechtere Latenz als DDR speicher der ja einige Taktzyklen braucht. Aber HBM ist halt erstmal vor allem eine breite Speicherarchitektur. Ich wäre sehr überrascht, wenn die Latenzen auch deutlich besser wären als bei Klassischem RAM weil der Fokus in der Entwicklung erstmal auf der Bandbreite lag.
Selbst wenn HBM bessere Latenzen bieten sollte als klassischer RAM bezweifel ich doch stark, dass die so viel besser ausfallen, das man auch nur ansatzweise in die Nähe von den Latenzen vom Cache käme und man mit kleineren caches keine Performance beeinträchtigung mehr hätte. Ich würde mich freuen wenns so wäre, aber ich kanns mir einfach nicht vorstellen.
 
Ich glaube nicht das HBM dazu führt das Cache an bedeutung verliert, eher im Gegenteil.
Für L1 und L2 stimmt das sicherlich. L3 wird bei Client Lösungen aber an Bedeutung verlieren. Intel braucht den ja auch nur, weil deren L2 mit 256 KB relativ winzig ist. Oder anders formuliert, wer einen bereits recht grossen L2 hat, mindestens 1-2 MB, profitiert kaum noch von L3 in typischen Client Apps. Da ist das Transistorbudget anderweitig einfach besser investiert. Je mehr Cache Level, desto grösser auch die Komplexität. Das möchte man gerade bei kostengünstigen Lösungen möglichst vermeiden. Und da GPUs auch immer mehr L2 bekommen, werden auch die iGPUs kaum noch von grösseren On-Die shared Caches profitieren können, sondern in Zukunft vielmehr am Tropf von Stacked Memory hängen.

Der Cache ist dazu da, latenzen beim Speicherzugriff zu minimieren.
Ja, aber die Latenzen des L3 sind bei AMD ja auch nicht gerade besonders niedrig. Typische Client Apps kommen mit vergleichsweise wenig Cache problemlos aus, so dass das meiste sowieso schon mit L2 abgefangen wird. Das ist bei Servern wie gesagt nochmal eine andere Geschichte. Und für speicherhungrige Apps wie Packer oder Transkodierer reicht dann selbst der L3 nicht mehr aus, so dass diese sowieso in den RAM zurückfallen. Da bringt die niedrigere Latenz des L3 gar nichts. Mehr Cache Level sind dann eher ein Hindernis und können die Performance sogar verschlechtern. Bevor ein Datensatz wieder gelesen wird, wurde er längst von einem anderen überschrieben. Cachen ist an der Stelle dann sinnlos und kostet nur unnötig Zeit. Genau deshalb gibt es für x86 zB nicht-temporäre Instruktionen, wo man direkt in den RAM schreiben kann ohne den Umweg Cache.

HBM wird einen hohen Durchsatz mitbringen durch die breite Anbindung, aber durch den geringeren Takt erwarte ich da absolut keine Wunder was die Latenz angeht.
Klar wird der Takt nicht so hoch ausfallen. Aber alleine die kürzeren Signalwege sollten für deutlich bessere Latenzen sorgen. L3 ist ja normalerweise auch nicht an den Kerntakt gebunden und läuft mit weniger Takt. Sandy Bridge war da eher eine Ausnahme. HBM1 soll die Latenz gegenüber DDR3 um Faktor 2 verbessern, HBM2 gar um Faktor 3,33. Wenn man mal die Werte von Tools wie AIDA64 als Referenz nimmt, dann liegt der Latenzunterschied zwischen L3 und DDR3 im Moment bei Faktor 5-10. Mit HBM2 läge der Unterschied gerade mal noch bei Faktor 2-3. Das macht bei der tatsächlichen Performance in Anwendungen kaum noch einen Unterschied.

Schau dir mal Designs wie Deneb und Propus an. Durch den Wegfall des L3 konnte Propus ein Drittel an Fläche sparen. Bei gleichem Takt war Deneb aber kaum schneller. Gerade mal 1-2% in Anwendungen (ein paar mehr Prozent in Spielen). Und dabei hatte Propus lediglich 512 KB L2. Selbst wenn Excavator den L2 gegenüber Steamroller halbiert, so ist das immer noch doppelt so viel wie bei K10. Zumindest bezogen auf einen Thread.

Wenn L3 cache in Consumerprozessoren überflüssig ist, was willst du denn dann mit mehr Kernen?
ZB 3 statt 2 Module ermöglichen mir im Notfall 50% mehr Performance (real vielleicht nur 35-40% aufgrund geringerer Taktraten um die TDP zu halten). Ein grosser L3 bringt maximal vielleicht gerade mal 5-10%. Da brauche ich ehrlich gesagt nicht zweimal überlegen, was mir lieber ist.
 
Ich schreibe jetzt mal ohne nachzuschlagen mit dem halbwissen was im Hinterkopf schlumemrt.
Soweit ich mich korrekt erinnern kann ist bei einigen der AMD Prozessoren mit mehreren Cores Aufgabe des L3 cache die L2 caches zu synchronisieren. Gibt es überhaupt eine CPU von AMD für mehr als 4 Threads ohne L3 cache?

Wenn HBM tatächlich die Latenzen verringern könnte wäre das großartig, zumindest wenn man HBM als RAM Ersatz benutzen könnte Oder zumindest als weitere caching stufe mit erheblich größerer Kapazität als die Caches auf der CPU. Aber ich bin mitlerweile etwas skeptisch geworden bei der Einführung neuer Techniken. Das revision 1 von irgendwas so richtig einschlägt und in allen Teilbereichen deutlich besser ist als die Vorgänger ist halt selten geworden. Und HBM verspricht irgendwie im moment mit viel Bandbreite, hohe energieffizienz und dann auch noch geringe Latenzen schon recht viel für eine Technik die für Grafikkarte und Beschleunigerkarten wie die Xeon Phi entwickelt wurde. Das genau diese neue Technologie innerhalb kürzester Zeit L3 Caches verdrängt wage ich zu bezweifeln.

Ich nehme übrigens deutlich lieber 5-10% performancezuwachs (ohne Taktsteigerung und signifikant höherer Wärmeentwicklung) manchmal als 50% oder 30-40% nie.
1. Hast du im consumer bereich wie du ihn nennst ja scheinbar keine Software die extrem multithreaded ist. 4 Threads auszulasten gelingt glaube ich nur selten.
Und 2. ist es mit einem Modul mehr nicht getan. Bei mehr als 2 Modulen wird es halt kompliziert. Plötzlich gibts halt keinen shared L2 mehr weil das mit 3 Modulen kompliziert wird. Du musst den ganzen Kram dranfrickeln der bei den >4core CPUs Platz kostet und kosten verursacht.

Schau dir doch mal an was bei den aktuellen Xeons anders ist als bei den Desktop CPUs. Es ist das Speicherinterface und das Caching das kostet enorm Platz und Energie. Und der ganze Aufwand nur um ein paar cores mehr zu versorgen. Das machen die ja nicht zum spass, es ist einfach notwendig.

Man kann den Platz einfach sparen und damit billigere APUs bauen. Man kann auch die GPU ausbauen aber einfach mehr Cores dranklatschen halte ich für Platzverschwendung.
Da bist du mit größeren Caches besser bedient.
 
Soweit ich mich korrekt erinnern kann ist bei einigen der AMD Prozessoren mit mehreren Cores Aufgabe des L3 cache die L2 caches zu synchronisieren. Gibt es überhaupt eine CPU von AMD für mehr als 4 Threads ohne L3 cache?
Ja, zB die CPUs in den Konsolen. Die Frage sollte eher lauten, gibt es eigenständige Clientdesigns mit L3? Alle AMD CPUs mit L3 waren bisher Serverdesigns (Barcelona, Shanghai, Istanbul, Orochi oder aktuell Seattle). Clientdesigns mit L3 waren lediglich Derivate davon. Eigenständige Clientdesigns hatten nie einen L3.

Ich nehme übrigens deutlich lieber 5-10% performancezuwachs (ohne Taktsteigerung und signifikant höherer Wärmeentwicklung) manchmal als 50% oder 30-40% nie.
Also ich habe mittlerweile mehrere Szenarien, wo selbst 4 Kerne an ihre Grenzen stossen. Die Anwendungsfälle für mehr als 4 Threads sind auf jeden Fall vorhanden. Und L3 bedeutet ja auch nicht, dass du 5-10% mehr bekommst, die du sonst nicht hättest. L3 und die dafür notwendige Kontrolllogik braucht neben jeder Menge Transistoren auch Energie. Ein Budget was man zB in mehr Takt oder bessere IPC investieren kann, was genau so viel bringt oder im Schnitt sogar mehr. Zusätzliches Transistorbudget für mehr Kerne hat man dann aber trotzdem noch.

1. Hast du im consumer bereich wie du ihn nennst ja scheinbar keine Software die extrem multithreaded ist.
Die brauchst du auch nicht. Multitasking reicht schon aus, um mehrere Kerne an ihre Grenzen zu bringen. Wenn ich zB grössere Projekte kompiliere, mit Hunderten oder gar Tausenden von Übersetzungseinheiten, dann bin ich über jeden Kern mehr froh, der seinen eigenen Compiler-Prozess ausführen kann. Und das gilt für andere Aufgaben genauso, zB mehrere Bild- oder Musikdateien parallel umzuwandeln. Auch für Spieler ist Multitasking ein nicht zu unterschätzendes Thema, zB bei Streaming oder Multiboxing.

4 Threads auszulasten gelingt glaube ich nur selten.
Selbst wenn das so ist, ich nehme lieber in diesen wenigen Fällen bis zu 50% mit als in wenigen cachelastigen Fällen bis zu 10% oder so, die man vielleicht noch messen kann, aber sowieso nicht merkt. Wobei mit den oben erwähnten 40-50 mm² für einen 8 MB L3 sogar zwei zusätzliche Excavator Module (2x 22,7 mm²) machbar wären. Bei gleichem Takt also sogar bis zu 100% gegenüber Carrizo bzw bei geringerem Takt immer noch deutlich über 50% drin wären.

Und 2. ist es mit einem Modul mehr nicht getan. Bei mehr als 2 Modulen wird es halt kompliziert. Plötzlich gibts halt keinen shared L2 mehr weil das mit 3 Modulen kompliziert wird.
Wieso das? Ich sehe nichts, was da kompliziert werden soll. Shared L2 gibt es auch mit 3 Modulen. Kann es sein, dass du hier was verwechselst? Shared L2 gibt es pro Modul, nicht pro 2 Module.

Schau dir doch mal an was bei den aktuellen Xeons anders ist als bei den Desktop CPUs. Es ist das Speicherinterface und das Caching das kostet enorm Platz und Energie.
Erstmal ist das ein schlechter Vergleich, da die Xeons Quad-Channel unterstützen und damit per se schon aufwändiger sind. Typische Clientprozessoren unterstützten bisher maximal Dual-Channel. Zudem verfügen Serverprozessoren über Features, die Clientprozessoren nicht benötigen, wie ECC. Aber genau das untermauert meine Aussagen doch. Aufwändiges Caching kostet Energie und Platz. Diese Ressourcen sind bei Clientprozessoren nur begrenzt vorhanden. Deshalb sollte man den Cache möglichst kompakt halten. Also nur wenige Stufen und moderate Kapazität, damit die Geschwindigkeit nicht zu stark leidet. Schneller Cache ist bei Clientprozessoren wichtiger als viel Cache.

Wenn ich freies Transistor-/Energiebudget hätte, würde ich die Entwicklung eines Kerns immer wie folgt priorisieren, Takt > IPC > Cache. Mehr Takt bringt praktisch immer was. Der skaliert nahezu linear. Mehr IPC ist sehr anwendungsabhängig, skaliert also sehr unterschiedlich, zeigt aber trotzdem auf die meisten Anwendungen Auswirkungen. Mehr Cache hingegen ist nicht nur sehr anwendungsabhängig, sondern bringt oft einfach kaum messbare Verbesserungen.
 
... Und HBM verspricht irgendwie im moment mit viel Bandbreite, hohe energieffizienz und dann auch noch geringe Latenzen schon recht viel für eine Technik die für Grafikkarte und Beschleunigerkarten wie die Xeon Phi entwickelt wurde. Das genau diese neue Technologie innerhalb kürzester Zeit L3 Caches verdrängt wage ich zu bezweifeln.

Naja, im endefekt spart man sich einfach nur das DDR3 interface beim Speicher. Denn vom internen Aufbau nehmen sich die Speichermodule (bis auf das gestapelte, um platz zu sparen nichts). Die Daten werden in Bänken gespeichert, die wie tabellen in Zeilen und Spalten geordnet sind, bei beiden wird der Speicher Zeilenweise ausgelesen und bei DDR3 wird er dann eben "seriell" an die CPU gesendet, während er bei HBM eben parallel übertragen wird.
Und genau der DDR3 Schritt fällt nun weg. Das ganze geht aber halt nur, wenn der Speicher mit auf dem DIE sitzt, denn 1k+ pins nur für den Speicher aus der CPU zu führen ist kaum möglich. Und das ganze kommt halt eben erst jetzt, da es früher einfach nicht möglich war, den Speicher klein genug zu fertigen um ihn in ausreichender Menge auf dem DIE unter zu bekommen.


Wenn ich freies Transistor-/Energiebudget hätte, würde ich die Entwicklung eines Kerns immer wie folgt priorisieren, Takt > IPC > Cache. Mehr Takt bringt praktisch immer was. Der skaliert nahezu linear. Mehr IPC ist sehr anwendungsabhängig, skaliert also sehr unterschiedlich, zeigt aber trotzdem auf die meisten Anwendungen Auswirkungen. Mehr Cache hingegen ist nicht nur sehr anwendungsabhängig, sondern bringt oft einfach kaum messbare Verbesserungen.

Takt alleine Macht aber auch nicht glücklich. Eine gesunde mischung aus allem ist der Schlüssel zum erfolg. Takt kostet Strom, IPC bringt ohne Takt nix und macht den Kern nur komplexer und Cache bringt ohne schnellem Kern nichts....
 
Versteh ich nicht. hiding.gif
 
Mr. Dude: L3 braucht man bei so ziemlich jedem Spiel was die Physik auf der CPU berechnet... (also quasi alle außer PhysX Games)... Ob das Metro, Stalker, WoT oder sonstwas ist... Überall ziehen selbst alte FX 4XXX CPUs den APUs/CPUs auf Bulldozer Basis davon... Deshalb braucht man L3.

Du wirst jetzt damit kommen von der wegen "die paar Prozent Leistung"... Genau das sind aber meist die paar Prozent die fehlen...

Lg Marti
 
Zuletzt bearbeitet:
Intels CPUs beweisen derzeit das Gegenteil.
Tatsächlich? Intels CPUs takten im Moment also nur mit 1-2 GHz oder so? Da muss mir doch glatt was entgangen sein.


Mr. Dude: L3 braucht man bei so ziemlich jedem Spiel was die Physik auf der CPU berechnet...
Du brauchst L3 definitiv nicht. Du wolltest vielleicht sagen, L3 beschleunigt Physik auf der CPU. Aber selbst das darf mehr als bezweifelt werden. Physik braucht keine Unmengen an Daten, die gecached werden können. Physik braucht vielmehr schnelle Berechnungen und schnelle Sprungvorhersage. Und das scheinen Benchmarks wie 3DMark Physics auch zu bestätigen. Da gibt's kaum einen Unterschied zwischen FX4 und A10 bei gleichem Takt.

Überall ziehen selbst alte FX 4XXX CPUs den APUs/CPUs auf Bulldozer Basis davon...
Nein, tun sie nicht. Du lässt dich vielleicht von Modellen mit unterschiedlichen Taktraten täuschen. Das sind wie gesagt idR maximal ein paar Prozent. Nichts was einen solch riesigen L3 bei Clientprozessoren rechtfertigen würde.

Du wirst jetzt damit kommen von der wegen "die paar Prozent Leistung"... Genau das sind aber meist die paar Prozent die fehlen...
Nicht wirklich. Wegen 5-10% werden aus unspielbaren FPS nicht plötzlich spielbare oder umgekehrt. Dazu braucht es schon andere Grössenordnungen.

Mal abgesehen davon frage ich mich, wann auch der letzte endlich mal kapiert, dass CPUs nicht exklusiv für Spiele gemacht werden. Schau dir den Schnitt über alle möglichen Anwendungen an. Da bleibt nicht viel an Mehrperformance mit L3 übrig.
 
Tatsächlich? Intels CPUs takten im Moment also nur mit 1-2 GHz oder so? Da muss mir doch glatt was entgangen sein.

Die ULV Prozessoren sind Konkurrenzlos im mobile Segment und im Desktop sind sie niedriger getaktet als die Bulldozer.
 
Mr. Dude: L3 braucht man bei so ziemlich jedem Spiel was die Physik auf der CPU berechnet... (also quasi alle außer PhysX Games)... Ob das Metro, Stalker, WoT oder sonstwas ist... Überall ziehen selbst alte FX 4XXX CPUs den APUs/CPUs auf Bulldozer Basis davon... Deshalb braucht man L3.

Du wirst jetzt damit kommen von der wegen "die paar Prozent Leistung"... Genau das sind aber meist die paar Prozent die fehlen...

Lg Marti
Bei exklusiven 8MByte + 8 MiB = 16MByte (1024 vs 1000)
Min FPS sind ebenfalls GPU lastig mit Ultra Einstellungen: http://abload.de/img/shipping-thiefgame_2074kwt.jpg
 
Zuletzt bearbeitet:
OMG was für ein Unsinn alles hier... HBM hat weniger Latenz, da er kürzere Signallaufzeit hat, punktum. Latenz wird bei mehr Takt einfach durch Wartezyklen angepasst, bleibt aber insgesamt gleich. Takt hat mit Latenz nur insofern was zu tun, als das der Takt hoch genug sein muss, um die Latenz zu erreichen, genau deshalb ist HBM so getaktet, wie er getaktet ist. Der anvisierte Takt ermöglich grade die niedrigste zu erreichende Latenz ohne Wartezyklen einlegen zu müssen.
 
Zuletzt bearbeitet:
OMG was für ein Unsinn alles hier... HBM hat weniger Latenz, da er kürzere Signallaufzeit hat, punktum. Latenz wird bei mehr Takt einfach durch Wartezyklen angepasst, bleibt aber insgesamt gleich. Takt hat mit Latenz nur insofern was zu tun, als das der Takt hoch genug sein muss, um die Latenz zu erreichen, genau deshalb ist HBM so getaktet, wie er getaktet ist. Der anvisierte Takt ermöglich grade die niedrigste zu erreichende Latenz ohne Wartezyklen einlegen zu müssen.

Perfekt !

Nie wieder APU ohne HBM :d
 
Mal abgesehen davon frage ich mich, wann auch der letzte endlich mal kapiert, dass CPUs nicht exklusiv für Spiele gemacht werden. Schau dir den Schnitt über alle möglichen Anwendungen an. Da bleibt nicht viel an Mehrperformance mit L3 übrig.

Mal abgesehen davon frage ich mich widerrum, wann auch der letzte Kapiert das wir hier im HWluxx sind und es hier halt nicht nur um Server und NAS sowie Multimediasysteme, sondern eben auch um Gamingrechner geht und auch low-Budget Systeme.


Genau für sowas wäre eben nen Athlon perfekt geeignet als Allrounder WENN er denn L3 hätte. Ich hab die letzten beiden Generatrionen, also Richland und Kaveri, versucht nen Mini-AMD System auf die Beine zu stellen was so ziemlich alles ohne Probleme packt...

GPU Seitig war das überhaupt kein Ding... R9 270X oder R9 285 haben sehr gute Dienste erwiesen... aber an der CPU hat es gehapert... mITX gibts aber nur in FM2(+) - ergo musste es die Mainstream Plattform werden.


Damit fingen die Probleme allerdings auch an - aber was erzähle ich denn hier... man testet ja nur unwesentlich. Die 5-10% kannst du dir übrigens Situationsbedingt aus dem Kopf schlagen, Worst-Case Beispiel WoT:


Mit nem FX 4350 @4,5Ghz gegen nen Athlon X4 760k @4,5Ghz ist man auf Perlenfluss @Maximalen Settings (GPU: Sapphire R9 285 Dual-X, Speicher: AMD R9 2400 2x4Gb) im minFPS Bereich von 42 Vs. 27... und wenn das nur 5-10% sind, dann weiß ich auch nicht weiter. Ähnlich sieht es auch bei Mechwarrior Online aus, nur habe ich da eben keine Konkreten Ergebnisse im Kopf weil das ursprünglich eigentlich als Eigeninteresse-Test gedacht war.


Lg

Marti
 
Zuletzt bearbeitet:
Nicht wirklich. Wegen 5-10% werden aus unspielbaren FPS nicht plötzlich spielbare oder umgekehrt. Dazu braucht es schon andere Grössenordnungen.

Mal abgesehen davon frage ich mich, wann auch der letzte endlich mal kapiert, dass CPUs nicht exklusiv für Spiele gemacht werden. Schau dir den Schnitt über alle möglichen Anwendungen an. Da bleibt nicht viel an Mehrperformance mit L3 übrig.

Wie wäre es mit gemessenen 30-40%?
Test: Was bringt bei AMD der L3-Cache? (Teil 2) (Seite 2) - ComputerBase

Ist zwar schon was älter, aber die Relationen dürften sich nicht unbedingt extrem verschoben haben... Insofern hat Pirate85 durchaus recht, dass gerade bei Games der L3 Cache ne ganze Menge bringt.
Das zeigen unterschwällig auch andere Messungen bei anderen CPUs. Wo der shared L2 Cache der Core2 CPUs in Form der E2xxx CPUs bedeutend Performance kostete, selbst bei stark OCed Modellen.

Aber ja, ich stimme dir dahingehend durchaus auch zu, das die Anwendungsfront nicht nur aus Games besteht. Für mich ist eher die Frage, wo hat AMD überhaupt noch nennenswert Anteile, wenn nicht an der Gamerfront? Mit den APUs zielt man auch teilweise auf Games ab um mal ein Beispiel zu bringen. Und gerade auch in Foren wie diesem werden gern auch AMD CPUs/APUs für LowBudget Spiele PCs empfohlen.
Was reine Anwenderkisten angeht, da sehe ich AMD lange schon nicht mehr als Konkurenz. Die Nachteile überwiegen einfach den Vorteilen. Und Features wie HSA respektive die GPU einer APU können lange nicht ihre Stärken ausspielen aufgrund von mangelndem Support auf der Anwendungsseite. Über den Punkt der benötigten Basisleistung sind wir ebenso länger schon für einfache Büro und Officerechner drüber raus, was hinten über bleibt sind dann KO Kriterien wie der Verbrauch bzw. absolute Peak-Leistungen bzw. der Preis. Nur belegt AMD mit ihren Modellen dort auch nicht mehr nur noch die Spitzenplätze. Gerade mit den APUs macht man sich selbst Konkurenz wo die einzigen beiden Kriterien pro APU der niedrigere Platzbedarf und womöglich der niedrigere Verbrauch sind. Ansonsten fährt man mit der Kombo X4 auf FM2+ + dGPU das eindeutig bessere P/L. Oder halt i3 mit SMT + dGPU, wenn man mehr Wert auf ST-Performance legt.

Heist unterm Strich, wenn man den AMD Modellen nun den L3 wegkürzt, werden unterm Strich vielleicht nicht massiv viele Prozente an Performance verloren gehen über alle Anwendungsbereiche gesehen. Aber auch wenige Prozentpunkte sind im Grunde schon zu viel, wenn es um den Vergleich mit der Konkurenz geht, denn die Lücke klafft jetzt schon Kriterienübergreifend teils stark auseinander.



Zum Topic:
Carrizo macht für mich nicht unbedingt den Eindruck, als will man damit die Leistungswerte massiv weiter nach oben schrauben muss ich ehrlich sagen. Auch die spekuliert massiv eingekürzte TDP scheint diese Annahme zu bestätigen.
Was durchaus interessant wird, ist das Thema GPU. Wenn man aufgrund neuer Speichertechnologien den Bandbreitenflaschenhals eliminieren kann, kann das ganze durchaus aufgehen. Für mich als Anwender stellt sich nur die Frage nach den Kosten und vor allem die Frage nach den Möglichkeiten? -> ich will keine fest verlöteten APUs auf dem Board. Und ich will auch keine fest verlöteten Speicherbausteine auf dem Board.
-> warscheinlich ist noch nicht ganz klar, wie das ganze im Desktop aka FM2+ (oder dessen Nachfolger) ausschauen wird... Weswegen davon hier auch nicht die Rede zu sein scheint... Für Notebooks definitiv ne interessante Sache, wenn AMD endlich mal ein paar anständige Partner findet, die auch brauchbare Notebook Modelle auf den Markt schicken. Soll heißen, ohne irgendwelche unsinnigen Nachteile.
 
Die 5-10% kannst du dir übrigens Situationsbedingt aus dem Kopf schlagen, Worst-Case Beispiel WoT:

Mit nem FX 4350 @4,5Ghz gegen nen Athlon X4 760k @4,5Ghz ist man auf Perlenfluss @Maximalen Settings (GPU: Sapphire R9 285 Dual-X, Speicher: AMD R9 2400 2x4Gb) im minFPS Bereich von 42 Vs. 27... und wenn das nur 5-10% sind, dann weiß ich auch nicht weiter.

Wie wäre es mit gemessenen 30-40%?
Test: Was bringt bei AMD der L3-Cache? (Teil 2) (Seite 2) - ComputerBase

Ist zwar schon was älter, aber die Relationen dürften sich nicht unbedingt extrem verschoben haben... Insofern hat Pirate85 durchaus recht, dass gerade bei Games der L3 Cache ne ganze Menge bringt.

Ja Krass... Bin ich froh noch nen Echten Bulldozer zu verwenden und keine APU :d

Echt schade das AMD den Steamroller oder Excavator nicht mehr als 4 Modul CPU mit L3 bringt.

so ein 4 Modul Excavator + L3 @ 4,5 ghz wäre völlig aussreichend für WOT und alle anderen games auf dem markt.
 
2 vollständige Module inkl. Link (L3 Cache = Link) würden schon reichen... so müssen sie alles für sich Berechnen und über den Bus kommunizieren (L2 ist nur für jeweils 1 Modul, Sprich bei 2 Modulen hat man 2x L2 Cache, gemeinsam genutzte Daten müssen somit 2x gespeichert und über den Bus kommuniziert werden), via L3 wäre das unnötig da sie Daten gemeinsam Abrufen könnten (der L3 würde beide direkt miteinander verbinden bzw würden gemeinsam genutzte Daten direkt im L3 abgelegt werden können).


Denke auch das macht u.a. den Leistungsunterschied aus.

Edit: da könnten Sie von mir aus sogar den L2 reduzieren wie sie es ja jetzt machen.
 
Zuletzt bearbeitet:
Bei WoT, was ja nicht sooo wirklich MT optimiert ist, könnte es was bringen im Windows Taskmanager die Anwendung auf ein Modul festzupinnen (sprich auf die ersten beiden Threads, oder eben die beiden letzten Threads)
Denn dazu kommt, das das OS häufiger auch die Anwendungen zwischen den Threads hin und her schubst. Ohne gemeinsame Cachebasis lässt man dabei Performance liegen, weil Daten neu geladen werden müssen.

Ich hab das damals mal ausgetestet mit SuperPI auf nem Dual Xeon Dualcore System. Was im Ganzen einem Core2Quad entsprach, nur das es eben wirklich zwei CPUs waren. Aufgrund des hin und her schubsens des Lastthreads zwischen den physischen CPUs entstand Querkommunikation (wenn man es so nennen kann), die massiv Leistung kostete. Da waren teils 10+% an Leistungsverlust zu sehen im Vergleich zum Festpinnen auf eine CPU, nur weil das OS den Lastthread zwischen beiden CPUs hin und her geschoben hat.


Aber das bringt am Ende auch nur etwas Punkte. Das Grundproblem wird dabei nicht unbedingt gelöst... Den AMD CPUs fehlt obenrum einfach die Performance. Auch Sachen wie Mantle nutzen dann nicht mehr viel, wenn die CPU deckelt.
Und jetzt, wo die GPU Treiber auch über die CPU Breite anfangen zu skalieren, zählt das am Ende sogar noch um so mehr.

Ich hätte mir von AMD so ne Art PS4 APU gewünscht. Sprich nen Dual Puma, aber ohne GPU unter einem Deckel. Von mir aus auf AM3+ bzw. für FM2+. Ne Dual Dualchannel Anbindung wie für G34 im Opteronbereich und in Sachen Fertigung eher etwas Luft für Taktspielraum als das Limit an möglicher Packdichte. Aber ich glaube sowas werde ich in den nächsten Jahren so oder so nicht sehen :(
 
Aber das bringt am Ende auch nur etwas Punkte. Das Grundproblem wird dabei nicht unbedingt gelöst... Den AMD CPUs fehlt obenrum einfach die Performance.

Finde ich nicht. Wie Stark ein Steamroller mit L3 wäre, wissen wir ja nicht, aber defenetiv zwischen Nehalem & Sandy bridge. Kombiniert mit 4-5 ghz Takt ist das schon voll ok.

Excavator könnte IPC technisch auch wieder 7,5-15% drauflegen, wer weiß.
 
Ich hätte mir von AMD so ne Art PS4 APU gewünscht. Sprich nen Dual Puma, aber ohne GPU unter einem Deckel. Von mir aus auf AM3+ bzw. für FM2+. Ne Dual Dualchannel Anbindung wie für G34 im Opteronbereich und in Sachen Fertigung eher etwas Luft für Taktspielraum als das Limit an möglicher Packdichte. Aber ich glaube sowas werde ich in den nächsten Jahren so oder so nicht sehen :(

+1 - genau das... und da hätte man "lediglich" das Package ändern müssen, die Architektur und die Fertigung dafür gibts ja schon...



Bzgl. WoT: Das behält soweit schon den Lastthread auf einer CPU bzw. auf zweien, wobei aber nun gerade mit 2-Modul Athlons das Problem mit dem L3 Cache kritisch ist - Meinetwegen wird die Anwendung selber auf Core 0 realisiert (Modul 1 Integer 1) und die "Physik" auf Core 2 (Modul 2 Integer 3) - soweit schon mal gut weil die FP Unit eines Moduls mit ziemlicher Sicherheit mit beiden Threads völlig überfordert wäre (IPC Seitig), aber da nun die Anwendung und der Physikteil nunmal untereinander Abhängig sind muss jegliche Kommunikation außerhalb des L2 Caches über den Bus --> Arbeitsspeicher laufen... dort dürfte die ganze Performance flöten gehen. :shake:


€dit: Merkt man bei WoT auch sehr gut auf Maps mit viel Bebauung bei AMD CPUs, geht im Sichtbereich viel kaputt geht die GPU Last runter und die CPU Last nagelt sich irgendwo bei 75-80% Fest ---> Absolutes CPU Limit.

Das er nicht auf 100% hoch geht halte ich z.b. ebenfalls für ein Indiz das die Cores sich untereinander nich versorgen können - die Auslastung geht nicht auf 100%.


Leider habe ich kein AMD System mehr, speziell keines im FM2+ Bereich - sonst würde ich beide Lastthreads mal auf Modul 1 legen... selbst da dürfte die Auslastung niemals 100% erreichen, weil der FP Scheduler voll läuft bevor beide Integer Ausgelastet sind.
 
Zuletzt bearbeitet:
Die ULV Prozessoren sind Konkurrenzlos im mobile Segment
Mal abgesehen davon, dass keiner von ULV Prozessoren gesprochen hat, selbst diese sind nicht konkurrenzlos. Bieten quasi kaum Mehrperformance zB gegenüber Cat. Und das bei höheren Kosten. Konkurrenzlos im mobilen Segment ist maximal Intels Contra Revenue Programm.


Mal abgesehen davon frage ich mich widerrum, wann auch der letzte Kapiert das wir hier im HWluxx sind und es hier halt nicht nur um Server und NAS sowie Multimediasysteme, sondern eben auch um Gamingrechner geht und auch low-Budget Systeme.
Die Leute im Forum hier entwickeln aber keine CPUs. Das ist dir schon bewusst, oder? CPUs werden von Firmen entwickelt, die den gesamten Markt berücksichtigen. Und da machen Spieleworkloads nur einen kleinen Teil aus. Aber wie gesagt, selbst wenn da in der Vergangenheit ein paar mehr Prozent mit grossen Caches rausgesprungen sind, auch die Software hat sich weiterentwickelt, siehe Mantle. Spiele rechtfertigen grosse und teure Caches nicht mehr. Erst so Sachen wie HBM sind wieder interessant, weil wir dann nicht mehr von nur ein paar MB sprechen, sondern von GB. Mit denen man deutlich schneller als mit RAM arbeiten kann. Der Core2 kam mit 2-4 MB shared L2 auch sehr gut zurecht. Bei Intel hielt der grosse L3 ja auch nur wegen Nehalem Einzug. Der bekanntlich mit Fokus auf Server entwickelt wurde. Genauso wie AMDs Barcelona davor.

Genau für sowas wäre eben nen Athlon perfekt geeignet als Allrounder WENN er denn L3 hätte.
Nein. Zu teuer, zu wenige Vorteile. Der Athlon ist ein hervorragender Allrounder mit dem Cache den er besitzt. Man sollte lediglich weiter an der Architektur feilen. 2-4 MB L2 sind für 4 Threads ausreichend.

Mit nem FX 4350 @4,5Ghz gegen nen Athlon X4 760k @4,5Ghz ist man auf Perlenfluss @Maximalen Settings (GPU: Sapphire R9 285 Dual-X, Speicher: AMD R9 2400 2x4Gb) im minFPS Bereich von 42 Vs. 27...
Eine Schwalbe macht bekanntlich keinen Sommer. Die Unterschiede können durch alles mögliche hervorgerufen werden. Es unterscheidet sich ja nicht nur der Cache, sondern die gesamte Plattform ist eine andere. Woher willst du also wissen, ob es alleine am Cache liegt? Hast du konkrete Ingame Speicherdurchsätze, die das belegen können? FPS reichen für eine aussagekräftige Analyse nun mal nicht aus, wenn die Unterschiede so deutlich sind. Übrigens, es bringt gar nichts, sich jetzt irgendwelche Rosinen rauszupicken. Damit kann man doch nicht den Schnitt aller Fälle widerlegen. Schau dir alles mögliche an. IdR 5-10%, mehr ist es nicht. Daran ändern auch Ausreisser mit deutlich über 10% nichts.

Leider habe ich kein AMD System mehr, speziell keines im FM2+ Bereich - sonst würde ich beide Lastthreads mal auf Modul 1 legen... selbst da dürfte die Auslastung niemals 100% erreichen, weil der FP Scheduler voll läuft bevor beide Integer Ausgelastet sind.
Du kannst solch eine Auslastung sowieso nicht messen. Bzw ist mir kein gängiges Tool bekannt, das das könnte. Da kann man maximal auf Profiler zurückgreifen. Die haben Optionen für unterschiedliche Scheduler. Auslastung wird normalerweise nur zwischen Gesamtzyklen und verarbeiteten Zyklen gemessen. Da gibt's keine Unterscheidung zwischen Integer und FP. Und Wartezyklen können durch alles mögliche verursacht werden und nicht nur weil der eine Scheduler auf den anderen warten muss.


Wie wäre es mit gemessenen 30-40%?
Wir reden hier über den 2 MB L2 von Bulldozer und nicht über den deutlich kleineren L2 vom K10.

Aber ja, ich stimme dir dahingehend durchaus auch zu, das die Anwendungsfront nicht nur aus Games besteht. Für mich ist eher die Frage, wo hat AMD überhaupt noch nennenswert Anteile, wenn nicht an der Gamerfront?
Ach, plötzlich. Wird von euch ansonsten nicht ständig gepredigt, dass AMD für Spiele nichts taugt? Demnach sollten sie dort doch keine nennenswerte Anteile mehr haben, richtig?

Was reine Anwenderkisten angeht, da sehe ich AMD lange schon nicht mehr als Konkurenz.
Sind sie aber. Vergleiche doch mal aktuelle X4/A10 mit i3. Nur weil AMD im Moment keine 3- und 4-Moduler auf aktueller Technik rausbringt, um was vergleichbares zu i5/i7 im Portfolio zu haben, was sowieso nicht jeder braucht, heisst das doch nicht, dass sie grundsätzlich keine Konkurrenz mehr in Anwendungen sind.

Heist unterm Strich, wenn man den AMD Modellen nun den L3 wegkürzt, werden unterm Strich vielleicht nicht massiv viele Prozente an Performance verloren gehen über alle Anwendungsbereiche gesehen. Aber auch wenige Prozentpunkte sind im Grunde schon zu viel, wenn es um den Vergleich mit der Konkurenz geht, denn die Lücke klafft jetzt schon Kriterienübergreifend teils stark auseinander.
Was heisst wenn? Dir ist schon bewusst, dass AMDs APUs noch nie L3 hatten? Und das aus guten Gründen, die ich bereits mehrfach erläutert habe. Wo soll da was weggestrichen werden? Lediglich der L2 scheint mit Excavator halbiert zu werden. Sofern der aber schneller arbeitet, also mehr Durchsatz und weniger Latenz, muss das kein Nachteil gegenüber dem aktuellen L2 sein. Bisher war es ja auch nicht so, dass die Grösse ein Problem gewesen wäre, sondern vielmehr die Schreibrate. Eventuell hat man nun endlich auch mal daran gearbeitet. Mit Steamroller wurde ja schon die Leserate deutlich verbessert.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh