News Erste Details zu AMDs Zen-Prozessoren
- Ersteller Onkel_Dithmeyer
- Erstellt am
Alter Sack
Lt. Commander
Das Fertigungsproblem begleitet AMD schon seit Jahrzehnten. Das sollten sie schon beim Design mit einrechnen
(bei Bulldozer wurde dieser Malus leider vergessen).
Die letzten erfolgreichen AMD Designs kamen alle mit wenig Takt aus (Athlon XP, Athlon64). ...man darf hoffen.
(bei Bulldozer wurde dieser Malus leider vergessen).
Die letzten erfolgreichen AMD Designs kamen alle mit wenig Takt aus (Athlon XP, Athlon64). ...man darf hoffen.
MacroWelle
Captain Special
- Mitglied seit
- 15.02.2008
- Beiträge
- 236
- Renomée
- 1
Weil die Größe des L3 dann zu der Angabe im Post passen würde. Falls diese korrekt ist, wohlgemerkt.
Im Beitrag steht aber 8 MB.
Wobei ich gerade noch mal in den Beitrag geschaut habe und dort finden sich 5 Cache-Zusammensetzungen, aber nur 4 Core Counts, wobei bei den Core Counts der 24-Kerner fehlt. Also ist die Tabelle von P3Dnow falsch, da muss statt "8 / 32" für den Cache "12 / 64" stehen.
Außerdem stellt dies für mich die Plausiblität bzw. Aussagekraft des Beitrags bei Anandtech in Frage, weil unter "Core Counts" CPUs ohne Berücksichtigung von Deaktivierungen genannt sind, gleichzeitig ist aber ein 4-Kerner dabei. AMD hat klar gesagt, dass ein nativer 4-Kerner erst mit den APUs nächstes Jahr kommt.
mmoses
Admiral Special
Erstens: um in der Oberklasse mitzuspielen, müssten die vorher das Image drehen was drei bis vier Jahre dauern dürfte, soviel Atem hat AMD weiss Gott nicht mehr!
Zweitens: . auch wenn der Abstand verkürzt wird, hat Intel immer noch einen deftigen Fertigungsvorteil und lässig genug in der Kriegskasse um da nochmal im Gewaltmarsch nachzulegen!
Drittens: Ist der Vierkerner für 65Watt avisiert!
..... im Artikel ging es um ein Engeneering Sample bis zum Verkauf geht da noch a Bisserl was
Der einzige Weg der funktionieren kann wäre also, der Vierkerner (CPUonly) ringt mit dem i5-6500 und zieht bei massivemultithread diesem lässig davon...
Der Achtkerner bringt mehr ist aber nicht richtig mit den Nobel-i5 und den i7 vergleichbar
Besonders interessant werden dann die APUs, welche richtig von DDR4 profitieren 8) eben auch die Lowleveler BristolRidge die wohl auf 45Watte justiert für EinfachPC (& Büro) die Waffe sein werden
Mmoe
Wobei ich mir kaum vorstellen kann, dass er das schafft. Selbst der Beitrag bei Anandtech unterstellt den 4 Kerner mit 65W 2,8GHz bis 3,2GHz, der i5-6400 für 170€ hat 2,7GHz bis 3,3GHz, die IPC bei Zen dürfte noch ein Stück unter der von Skylake liegen und so viel bringt SMT dann bei den meisten Anwendungen auch nicht, um das auszugleichen. Das könnte allenfalls in ausgewählten Benchmarks die sehr gut auf SMT reagieren klappen, in der Breite der Anwendungen aber wohl nicht.
Zu BristolRidge gab es auf der Computex folgende Spekulation von wccftech:eben auch die Lowleveler BristolRidge die wohl auf 45Watte justiert für EinfachPC (& Büro) die Waffe sein werden
WindHund
Grand Admiral Special
Nein sie beinhaltet den Takt, sonst würde übertakten ja keine Mehrleistung bringen.
3GHz soll der Allcore Turbo sein, die 2.8GHz sind demnach für AVX und FMA Code.
Intel hat dafür inzwischen auch ein extra P-State eingeführt, welches unter dem Standard Takt geht bei AVX und FMA Programm Code. (oder die Mainboard Hersteller)
Eine CPU mit Taktgleichstand zu vergleichen ist zwar interessant, aber das System welches Herunter getaktet wird ist im Nachteil, weil es mehr kann "out of the box".
Fab8
Commander
- Mitglied seit
- 15.07.2012
- Beiträge
- 187
- Renomée
- 2
Das Thema hatten wir schon im Naples Thread, im Prozessorgeflüster war im Bild 1GbE und im Text stand 4x 10GbE. Seattle kam bereits mit 10GbE das hate man von dort relativ einfach übernommen. Mal sehen was für die Desktop Zens übrig bleibt, wichtig das bei den Server Zens mindestens 10GbE mit an Board ist.
Zuletzt bearbeitet:
mmoses
Admiral Special
So hab ich es geschrieben und gemeint....
Summit hängt in Schlagweite in der Breite dran, bringt aber in Einzeldisziplinen zwei Drittel.mehr... Bristol liegt preislich bei den i-Pentium und kleinen i3, liegt aber besonders bei der Grafik weit weit vorn...
IPC steht für Instructions Per Clock, kann also nicht den Takt beinhalten bzw. durch mehr Takt gesteigert werden, im Gegenteil fällt bei steigendem Takt sogar eher, weil die mehr Taktzyklen auf den Rest wie z.B. das RAM warten muss. Bei Betrachtung einer CPU Architektur wird nur die Leistung mit einem Thread betrachtet und die z.B. die Zeit gemessen die die CPU braucht um eine bestimmte Befehlsfolge abzuarbeiten. Natürlich hängt das Ergebnis auch von der Befehlsfolge ab, da ja nicht alle Befehle gleich lange brauchen um verarbeitet zu werden. Daher kann man im Grunde eine unterschiedliche IPC für jede unterschiedliche Befehlsfolge ermitteln. Hat man nun z.B. 1 Milliarde Befehle und die CPU hat 2GHz Takt und braucht eine Sekunden, so hat sie 0,5 Befehle pro Takt verarbeitet, also eine IPC von 0,5 und wenn eine zweite CPU mit 3GHz Takt dafür auch eine Sekunden braucht, so hat die zweite CPU dann nur eine IPC von 0,33.
Was Du mit der Mehrleistung meinst, ist nicht die IPC, sondern die tatsächliche Leistung die sich wieder aus IPC * Takt ergibt. Wenn man schon mitreden will und solche Grundlagen nicht kennt, sollte man sie wenigstens bei Wikipedia nachschlagen.
Den Vergleich bei gleichen Taktraten macht man ja eben auch nicht um die reale Leistung einer CPU zu bewerten, sondern die Effizienz ihrer Architektur.Eine CPU mit Taktgleichstand zu vergleichen ist zwar interessant, aber das System welches Herunter getaktet wird ist im Nachteil, weil es mehr kann "out of the box".
WindHund
Grand Admiral Special
@Holt
Ja das ist die Theorie, ich schau ab un zu auch mal nach in der Praxis: http://abload.de/img/ipc_peak_ocl_2ejsrv.jpg
IPC ist sogar von der Software abhänging, kann also je nach Architektur angepasst werden.
Ich denke das muss man Studieren um es im ganzen Umfang zu verstehen.
Sofern mehr IPC auch mehr Leistung bringt, scheinbar 40% bei 16T@3GHz (Pro Single Core) passt es.
Ja das ist die Theorie, ich schau ab un zu auch mal nach in der Praxis: http://abload.de/img/ipc_peak_ocl_2ejsrv.jpg
IPC ist sogar von der Software abhänging, kann also je nach Architektur angepasst werden.
Ich denke das muss man Studieren um es im ganzen Umfang zu verstehen.
Sofern mehr IPC auch mehr Leistung bringt, scheinbar 40% bei 16T@3GHz (Pro Single Core) passt es.
Das ist aber auch eine "Binse" und steckt im "I" von IPC. Es hängt halt durchaus davon ab, ob ich jetzt FPU-Befehle, AVX- oder den "normalen" Integer-Code durch die CPU jage.
Daher steht bei Wiki ja auch "es handelt sich in der Regel um einen Mittelwert". In deinem Diagramm müsstest Du den jetzt erst noch bilden.
Holt aber schon recht: Wenn ich immer denselben (Benchmark-)Code hernehme und bei unterschiedlichen Takt durch dieselbe CPU jage, erhalte ich Werte, die nur vom Takt abhängen.
Gesetzt den Fall, eine andere CPU kann dieselben Takte und hat denselben Befehlssatz, kann ich das Spiel mit dieser wiederholen und dann beide Architekturen vergleichen. So hat P3D ja auch mal schön die "Bulldozer-Evolution" dargestellt.
In der Praxis AMD vs. Intel muss man eben aufpassen, da beide CPUs i.d.R. nicht über genau diesselben Befehlssätze verfügen, kann ich "nur" eine Schnittmenge testen.
Aber wie schon öfters gesagt: Real-Life Code nutzt sowieso kaum spezifische Befehlserweiterungen aus.
cyrusNGC_224
Grand Admiral Special
Man kann auch einfach NOPs laufen lassen, die kann jede x86 CPU
Musst aber schon sagen, ob Single-Byte NOP oder Multibyte-NOP.Man kann auch einfach NOPs laufen lassen, die kann jede x86 CPU
(jetzt höre ich aber auf mit dem OT hier)
WindHund
Grand Admiral Special
Danke, user Input ist natürlich trotzdem Willkommen!
Oben Links im Bild wird der Mittelwert abgebildet Skalierung bis 4 i/c ~ 2.5 i/c mit Single Core Code.
Ich hätte jetzt eher so was wie eine horizontale Linie im Diagramm erwartet. Aber gut, nehmen wir dann halt die "0.3 i/c", die drüber stehen als Mittelwert über alles an.Danke, user Input ist natürlich trotzdem Willkommen!
Oben Links im Bild wird der Mittelwert abgebildet Skalierung bis 4 i/c ~ 2.5 i/c mit Single Core Code.
Und was ist der "Single Core Code" jetzt genau?
WindHund
Grand Admiral Special
Ähm, ja ne Linie wirst da nicht hinbekommen ist ja mit variablen Takt und Energie Management sowie Booost!
0.3 i/c sind im idle das ist kurz nach dem der Single Core Test beendet wurde also Memory Operations.
Welche genau müsste ich Nachfragen, jedenfalls gefällt es mir wenn alle Kerne beim laden des Spiele Levels genutzt werden!
Wer misst misst Mist, das ist ja nichts neues und ich frage mich wirklich wie ein SW Tool die Anzahl der Instruktionen auslesen will, die andere Programme unter Windows ausführen. Dazu kommt, dass der Scheduler die Threads ständig über die Kerne verteilt und wenn man das nicht verhindert einen Thread ständig auf einen anderen Kern verschiebt, die Kerne selbst mit ständig wechselnden Taktraten arbeiten, sofern man das nicht auch unterbindet, etc. pp. also würde so einem Tool nicht sehr weit über den Weg trauen.
Außerdem finde ich Perfmon2 nur als Linux Tool, aber keine Windows Portierung. Man kann sowas z.B. mit MinGW durchaus unter Windows zum Laufen bringen, nur ist die Frage wie genau man dann die Systemaufrufe vergleichen kann, je näher man an das System geht, umso schwerer ist eine Portierung und so ein Tool müsste schon sehr, sehr nahe am System sein um wirklich die Befehlsfolgen zu kennen die andere Programme abarbeiten. Perfmon2 enthält ja nicht umsonst eine Kernel-patch und den wird man unter Windows kaum einsetzen können.
Das ist doch klar und hängt damit zusammen, dass eben die Befehl unterschiedlich viele Zyklen für die Ausführung brauchen, das hatte ich doch auch geschrieben: "Daher kann man im Grunde eine unterschiedliche IPC für jede unterschiedliche Befehlsfolge ermitteln."
Das sowieso, weil es eben aussagt wie viele Instruktionen eine CPU bei einer bestimmten Anzahl an Taktzyklen verarbeitet und je mehr das sind, umso schneller ist ein Programm abgearbeitet.
Nochmal, die IPC wird i.d.R. pro Kern betrachtet, wobei auch das nur unzureichend ist, da nicht jede CPU bei Multithreded Anwendungen gleich gut über mehr Kerne skaliert, was aber auch wieder von der Befehlsfolge abhängt und da bremsen sehr häufig RAM Zugriffe, die Cache- und Memorycontroller haben da einen großen Einfluss wie gut die Skalierung über die Kerne ist, aber eben auch so Dinge wie, ob die Daten auf denen die Algorithmen arbeiten noch in den Cache passen oder nicht. Wenn auf jedem Kern nun eine Algorithmus mehrfach über jeweils 10MB Daten läuft, dann ist es relativ egal ob diesem Kern nun 1,5, 2 oder 2,5MB Cache zur Seite stehen, die Daten müssen immer wieder aus dem RAM kommen und da speilt eine CPU mit Quad-Channel RAM dann eine mit Dual Channel an die Wand. Arbeiten die gleichen Algorithmen nun nur mit 2,5MB Daten, so legt die CPU deren Kerne so viel Cache haben scheinbar plötzlich den Riemen auf die Orgel und hat auf einmal einen gewaltigen Vorteil gegenüber solchen CPUs wo jeder Kern weniger als diese 2,5MB Cache zur Verfügung hat, selbst wenn die Architektur gleich ist. Die Xeon-D haben z.B. nur 1,5MB/s L3 Cache pro Kern und sonst die gleichen Broadwell Kerne wie ein Xeon E5 bei dem pro Kern 2.5MB L3 Cache vorhanden sind. Reduziert man nun die Daten über die eine Schleife geht weiter auf 1,5MB, so kann auch der Xeon-D den Riemen auf die Orgel legen weil die langsamen Speicherzugriffe wegfallen. Man muss also nicht einmal die Befehlsfolge ändern um unterschiedliche IPC zu ermitteln, es reichen zuweilen auch unterschiedliche Parameter um zu unterschiedlichen Ergebnisse zu kommen.
Kann man machen, nur ist das dann in der Praxis einfach nicht aussagekräftig, weil eben nichts dabei gemacht wird und eine CPU die nichts tut, braucht eigentlich kein Mensch. Man will ja die IPC ermitteln um zu wissen wie schnell eine CPU ein bestimmtes Problem abarbeiten kann.Man kann auch einfach NOPs laufen lassen, die kann jede x86 CPU
Wo jetzt? Da wo gerade 0.3 steht? Nun moderne CPU schaffen durchaus bei bestimmten Befehlsfolgen mehr als eine Instruktion pro Cycle.Oben Links im Bild wird der Mittelwert abgebildet Skalierung bis 4 i/c ~ 2.5 i/c mit Single Core Code.
cyrusNGC_224
Grand Admiral Special
Genau deswegen und wegen der von dir noch aufgeführten Punkten ist eine IPC eigentlich auch noch so aussagekräftig, wie manche das gerne hätten. Man müsste, um eine IPC zu messen zu können die mit anderen CPUs vergleichbar ist, immer eine definierte Befehlsfolge auf diesen laufen lassen und zeitlich vermessen. Nur mit diesem Binärschnipsel könnte man dann die gewünschten CPUs vergleichen.
Die IPC dient praktisch nur als Aussage für die Betrachtung und Vergleich von CPUs und Architekturen. Wäre die Angabe allumfassend aussagekräftig, könnte man sich jegliche Benchmarks auch sparen, denn wären IPC*Takt immer gleich die Leistung, nur ist es eben nicht so simple. Das war es mal so ganz am Anfang bei den ersten CPUs, als die noch keine Caches hatte und das RAM auch im Verhältnis so schnell war, dass darauf ohne Verzögerungen zugegriffen werden konnte. Da konnte man aus der Dokumentation ablesen wie viele Taktzyklen die jeweiligen Befehle gebraucht haben und so war es dann auch. Heute nutzt es nichts wenn dokumentiert ist das z.B. ein Speicherzugriffe 2 Takt braucht, wenn die Daten nicht im Cache stehen sondern vom RAM geladen werden müssen, gehen schnell mal Hundert Takt für die Wartezeit drauf und je höher der CPU taktet, umso mehr Takt muss sie warten.
Helle53, ok und ich glaube man kann auch die real ausgeführten Takte auch auslesen, damit ist es ja auch einfach die IPC zu ermitteln.
Ähnliche Themen
