News AMD Tech Day: Ryzen-2000-CPUs ab April, Threadripper 2000 ab Sommer

[DonL_]

Das wird sich laut dem Senior Product Manager James Prior auch beim Sockel AM4 nicht ändern. Das bedeutet, dass aktuelle Ryzen-Mainboards mit einem BIOS-Update in der Lage sein werden, die neuen Prozessoren zu verwenden, auch bei späteren Generationen. Laut Prior will AMD den Sockel AM4 als Plattform für seine Mainstream-Prozessoren sogar noch bis ins Jahr 2020 verwenden.

http://www.gamestar.de/artikel/amd-zen-2-bleibt-mit-sockel-am4-kompatibel,3323056.html

Hört sich nicht danach an, das man für ZEN 2 (Ryzen 3) neue Mainboards braucht. Dazu haben sie berichtet das ZEN 2 fertig ist und es schon erste Tape outs gab, also können sie das schon sehr genau abschätzen, was 2019 passieren wird, insoweit stellt sich der Mensch ja nicht hin und erzählt Märchen!

 

[HaZweiOh]

Stimmt. Und da bereits PCIe 3.0 aktuell nicht benötigt wird, dauert es wohl bis 2020, bis man es vermissen würde. Dann nimmt PCIe 4.0 die Rolle des heutigen 3.0 ein.

 

[Bärenmarke]

Vielleicht haben wir aber auch bei Ryzen 2 vs Zen 2 aneinander vorbeigeredet. Ich hab oft Ryzen 2 geschrieben und meinte den Refresh, viele aber auch Zen 2.

Gut das kann natürlich sein, dann wollen wir das mal noch gelten lassen ;-)
Aber gerade in manchen Games wirst du eine Mehrleistung von mehr wie 5% sehen. Ist denke ich das selbe wie bei dem Schritt zu Vishera, da hat AMD auch Wort gehalten. Man sollte es nur nicht pauschalisieren

 

[Inxession]

erachte ich als Sinnlos, da wird sich nicht viel tun, denke das es erst wieder sinn macht bei Zen3 zu wechseln

Welcher Hardwarekauf, macht denn wann überhaupt Sinn?

Als Bastler kauft man wenn man will.

Ob es nun viel Sinn macht oder nicht, man will es haben

 

[werpu]

Konntest du bei Intel doch auch.

AMD wird Intel mit dem Update wohl richtig gefährlich werden können. Sollten 10% mehr Leistung nausspringen dann wird des scho reichen um sich an die Spitze zum setzen.

Und wenn Zen 2 scho fertig ist, dann beibt der Druck auf Intel erhalten.

AMD wird Intel sowieso schon gefährlich zumindest seitdem OS Updates auf Intel eingeschoben werden mussten die die IO Performance in die Knie brachten. Ich kenne schon die ersten Reports von Leuten, die genau aus diesem Grund von einem i8700k System auf ein Ryzen System gewechselt sind (3 Fache compilationsdauer + zähe vms war dann doch nicht so der bringer nach dem Meltdown update)

 

[Unnu]

AMD wird Intel sowieso schon gefährlich zumindest seitdem OS Updates auf Intel eingeschoben werden mussten die die IO Performance in die Knie brachten. Ich kenne schon die ersten Reports ...

OT: Ja, wir auch. Unser DataCenter-Verantwortlicher sammelt gerade Benchmarks der "Vor-Meltdown-Ära". Er rechnet mit bis zu 50% mehr Last auf den CPUs, da auch bei uns viel auf VMs läuft. D.h. wir werden wohl weitere Kisten dazu stellen müssen.

BTT: Ick freu' mir! Da das mit dem neuen System 2017 nix wurde, blicke ich ganz entspannt auf 2018 und hoffe zusätzlich auf eine etwas bessere Vega-Verfügbarkeit und alles ist eitel Sonnenschein. Und zur Refinanzierung Mine ich dann noch ein bisschen rum.

 

[Raucherdackel!]

Welche ARM wären das, die für Meltdown anfällig sind?

Zum Beispiel die Snapdragon 808 und 810. Und sehr wahrscheinlich auch die ganzen Kraits und Kryos, weil das Qualcomm Eigenentwicklungen sind, zu denen ARM schonmal gar nix sagen kann. Ebenso werden Samsungs Exynos mit ziemlicher Sicherheit auch betroffen sein, weil es nämlich keinerlei Statement von denen gibt. Wären sie nicht betroffen, würden sie es ja sofort sagen. So halten sie die Füße still und hoffen, dass keiner nachfragt.


Edit: Für mich ein Grund mehr, diese Firmen zu meiden und auf MediaTek zu setzen, obwohl die ziemlich faul mit ihren Treibern sind - was aber eigentlich (!) keinerlei Auswirkungen auf Updates hat. Da liegt das faule Ei bei Google, und nicht bei Mediatek...

 

[user2357]

Hallo Leute,

mal eine Frage zu der stets und ständig verwendeten Bezeichnung IPC - wofür steht denn eurer Meinung nach das C? - gerade auf den letzten Seiten 13 und 14.

Bin eher interessierter Laie, was die Abgründe von Prozessorarchitektur angeht, aber mit dieser Information (mittig, Tabelle beim zweiten Vorkommen von "Issue Width") an der Hand geht es doch um Instruktionen pro (Takt-)Zyklus. Wie Smartcom5 in #249 auch schon bemerkte.
Instruktionen pro Takt, die je nach Möglichkeit parallel von den vorhandenen funktionalen Einheiten abgearbeitet werden können. Die IPC ist also eher eine recht niedrige Ganzzahl, wie der Tabelle aus dem Link zu entnehmen ist. Hier sind an sich keine prozentualen Steigerungen möglich, da die IPC eine feststehende Kerngröße der Architektur darstellt. Hat der Kern nur zwei integer-Einheiten, lassen sich nur zwei integer-Instruktionen pro Takt abarbeiten.
Woran meiner Meinung nach eher gefeilt werden wird, ist die Minimierung der Leerzyklen, in denen die funktionalen Einheiten brachliegen, weil beispielsweise auf den Cache gewartet wird. Da wären wir dann wieder bei IPS, also Instructions Per Second, siehe #249 - da würde ich auch mit prozentualen Steigerungen mitgehen
Hätte beispielsweise die Infinity Fabric zwischen den CCX eine eigene vom RAM-Controller unabhängige Takt-Domäne, ließe sich die Latenz zwischen den L3-Caches der CCX gegebenenfalls einfacher durch Taktsteigerungen der Fabric minimieren - außerdem müsste es nicht unbedingt der Uber-4 GHz RAM sein um diesen "Flaschenhals" zu entschärfen. Aber wer weiß - die Fabric hat sicherlich mehr als nur die eine Stellschraube Takt.

 

[Krautmaster]

Smartcom5 überimmt die Auflösungsarbeit da sicher gern. Hat ja vorher schon bewiesen wie unglaublich viel ihm an der Richtigstellung hinsichtlich IPC / IPS liegt.

 

[HaZweiOh]

Er hatte aber auch Recht: IPC ist halt nicht Single Thread Leistung, sonst hieße es ja "Instructions per clock at the wall"

 

[user2357]

Wozu die Häme? - es wurde doch in einer Tour falsch verwendet.

 

[xexex]

Die IPC ist also eher eine recht niedrige Ganzzahl

Nein!

Eine CPU benötigt für die meisten Operationen mehr als einen Takt, es kann also in den wenigsten Fällen eine Ganzzahl sein.

Mal auf Wikipedia verwiesen.

These numbers are NOT the IPC value of these CPUs
https://en.wikipedia.org/wiki/Instructions_per_cycle

 

[user2357]

Ok, laut wikipedia "average number of instructions executed for each clock cycle" ließe auch eine Steigerung im Prozentbereich zu. Ich war davon ausgegangen, dass es sich um den Idealfall handelt, dass alle funktionalen Einheiten in einem Taktzyklus mit einer Instruktion bedient werden. Gut, dass wir drüber geredet haben!

 

[Rambo5018]

Hat ja vorher schon bewiesen wie unglaublich viel ihm an der Richtigstellung hinsichtlich IPC / IPS liegt.

Ganz ehrlich, da sehe ich nichts Verwerfliches dran. Gerade wenn der Begriff derart häufig gebraucht wird wie hier im Forum ist es doch eine schöne Sache wenn sich jemand um die Aufklärungsarbeit bemüht. Man kann ja nicht ewig sagen "es weiß ja jeder was gemeint ist".
Irgendwann weiß es dann keiner mehr so recht und eine sinnvolle Diskussion ist unmöglich weil im Endeffekt alle aneinander vorbeireden.

Hier wird gerade auch wieder mal instructions per clock und mal instructions per cycle genannt. Also finde ich es umso schöner wenn das aufgeklärt wird.

Außerdem bin ich mir ziemlich sicher das Holt sehr wohl begreift was IPC ist.

Das wollte ich auch nicht anzweifeln.

 

[Krautmaster]

Er hatte aber auch Recht: IPC ist halt nicht Single Thread Leistung, sonst hieße es ja "Instructions per clock at the wall"

sag ich das Gegenteil?

Ergänzung (9. Januar 2018)

Ganz ehrlich, da sehe ich nichts Verwerfliches dran. Gerade wenn der Begriff derart häufig gebraucht wird wie hier im Forum ist es doch eine schöne Sache wenn sich jemand um die Aufklärungsarbeit bemüht.

ich weiß, etwas Sarkasmus war dabei. Aber auch nur weil es schon fast etwas zuviel des Guten war. Jetzt müssen wir also IPC, IPS, sowie das ganze bezogen auf Multi und Singlethread unterscheiden.

Außerdem bin ich mir ziemlich sicher das Holt sehr wohl begreift was IPC ist.

Von IPS hab ich jetzt noch nie was gehört

IPS oder auch I/s= Instructions per Second → Instruktionen je Sekunde
Letzteres wird oft synonym für die Single-thread-Performance herangezogen

Ka auf welcher Quelle sich diese Aussage stützt, rein von der "Instructions per Second" ist eigentlich? Ich mein klar, "Second" bringt einen zeitlichen Charakter is Spiel. Da kann man jetzt wieder fragen "long Time" oder "short Time". Mit Speed Shift und Turbo kann der "IPS" Wert ja massiv unterschiedlich ausfallen. Wenn der Turbo Takt binnen weniger µS anliegt.

Wie messe ich sowas also? Nehm ich zb den Schnitt aus 60s um daraus IPS zu errechnen hab ich eigentlich 0 Informationsgewinn vergleichen mit IPC - und erst recht keine Bezug der mich irgendwie Richtung Single Thread Performance führt.

jetzt würde mich ein Test interessieren der via Oszilloskop die erste 200ms nach Last durchmisst und auch schaut wie viel "Clocks" da überhaupt gefahren werden. Kann ja sein dass da nen Unterschied von mehreren Faktoren auftritt und in dem Fall wäre das System mit mehr Clocks je nach IPC deutlich fixer.

Edit. @CB

Wäre doch was für eure Kreativität Abteilung, das Ansprechverhalten zu untersuchen. CPU quasi idle, dann ein App Launch oder ein Task der zb etwa 100- 500ms dauert.
Ggf quasi process time über einfache Schleifen Durchlauf. Damit müsste sich schon fast nen Graph plotten lassen wie sich die Performance über 500ms nach idle entwickelt. Ähnlich dem Intel Diagramm oben.

 

[HaZweiOh]

hier im Forum ist es doch eine schöne Sache wenn sich jemand um die Aufklärungsarbeit bemüht.

Das ist sogar der eigentliche Sinn eines Forums! Deshalb verstehe ich auch nicht, wenn einige (bei anderen Themen!) gleich aggressiv werden, weil man (wohl gemerkt bei einem spürbaren Gewinn von NULL!) mal auf den fehlenden Praxisnutzen eines teuren Spielzeugs hinweist. Das gehört auch zur Aufklärungsarbeit, und das Spielzeug geht davon ja nicht kaputt.
[Ende offtopic]

IPS ist mir sonst auch nie begegnet.

 

[xexex]

Wie messe ich sowas also? Nehm ich zb den Schnitt aus 60s um daraus IPS zu errechnen hab ich eigentlich 0 Informationsgewinn vergleichen mit IPC - und erst recht keine Bezug der mich irgendwie Richtung Single Thread Performance führt.

Eigentlich kann man einen IPC "Wert" nicht richtig ermitteln, da dieser stark vom Anwendungsfall abhängt. Man kann jetzt schlecht sagen eine CPU macht im Schnitt so und so viele Additionen und so und so viele Multiplikationen, also ermitteln wir damit den Standard-IPC.

Man kann diesen Wert eigentlich nur als Vergleichswert zwischen gleich getakteten CPUs im identischen Testparcour heranziehen und könnte ihn auch genauso "Effektivität" oder sowas in der Richtung nennen.

 

[rg88]

Zum Beispiel die Snapdragon 808 und 810. Und sehr wahrscheinlich auch die ganzen Kraits und Kryos, weil das Qualcomm Eigenentwicklungen sind, zu denen ARM schonmal gar nix sagen kann. Ebenso werden Samsungs Exynos mit ziemlicher Sicherheit auch betroffen sein, weil es nämlich keinerlei Statement von denen gibt. Wären sie nicht betroffen, würden sie es ja sofort sagen. So halten sie die Füße still und hoffen, dass keiner nachfragt.

Meltdown? Sicher, dass du nicht Spectre meinst? Hab dazu noch nichts in der Hinsicht gefunden.

 

[x2-3800]

Die Hersteller haben doch bereits ihre BIOS-Versionen aktualisiert. Oder zumindest ASUS spricht bei AGESA 1071 von "new upcoming processors."

Korrekt, habe letzte Woche ein BIOS Update V3008 für mein ASUS crosshair VI Hero gezogen, da war auch die Rede davon.

"Version 3008 2017/12/137.38 MBytes

CROSSHAIR VI HERO BIOS 3008
Update to AGESA 1071 for new upcoming processors."

 

[Smartcom5]

Hallo Leute,

mal eine Frage zu der stets und ständig verwendeten Bezeichnung IPC - wofür steht denn eurer Meinung nach das C? - gerade auf den letzten Seiten 13 und 14.

Bin eher interessierter Laie, was die Abgründe von Prozessorarchitektur angeht, aber mit dieser Information (mittig, Tabelle beim zweiten Vorkommen von "Issue Width") an der Hand geht es doch um Instruktionen pro (Takt-)Zyklus. Instruktionen pro Takt, die je nach Möglichkeit parallel von den vorhandenen funktionalen Einheiten abgearbeitet werden können. …

Das C der IPC steht für Cycle, daher (pro/je) Takt (-zyklus), das ist korrekt, ja.

Im Übrigen geht aus der Tabelle nicht eindeutig hervor, ob es sich um die jeweilige IPC oder etwa der deutlich gebräuchlicheren Einheit FLOPS (Floating Point Operations Per Second) handelt.

Die IPC ist also eher eine recht niedrige Ganzzahl, wie der Tabelle aus dem Link zu entnehmen ist. Hier sind an sich keine prozentualen Steigerungen möglich, da die IPC eine feststehende Kerngröße der Architektur darstellt. Hat der Kern nur zwei integer-Einheiten, lassen sich nur zwei integer-Instruktionen pro Takt abarbeiten.
Woran meiner Meinung nach eher gefeilt werden wird, ist die Minimierung der Leerzyklen, in denen die funktionalen Einheiten brachliegen, weil beispielsweise auf den Cache gewartet wird. Da wären wir dann wieder bei IPS, also Instructions Per Second, siehe #249 - da würde ich auch mit prozentualen Steigerungen mitgehen

Die IPC ist (nach Art) absolut und fix, ja.
Allerdings kann die Kennzahl mitunter stark schwanken durch Verwendung unterschiedlicher, abzuarbeitende Befehlsarten, da die IPC lediglich angibt, wie viele gegebene Instruktionen im Mittel je Taktzyklus verarbeitet werden können.

Bei synthetischen Instruktionen wie Befehlen mit geringer logischer Tiefe und algorithmischer Komplexität, welche geeignet sind, sehr kurz abgearbeitet zu werden, ergibt sich folgerichtig eine hohe IPC – wohingegen bei hoch-komplexen, langen Instruktionen eine deutlich geringe Kennzahl erreicht werden kann. Hier kann sogar der gegensätzliche Fall eintreten, daß es mehrere Takte benötigt, um die jeweilige einzelne Instruktion abarbeiten zu können. Dann spricht man vom reziproken Multiplikativ – umgangssprachlich schlicht als Kehrwert bezeichnet und genormt als (Clock-) Cycles per Instruction oder auch C/I, kurz CPI → Takt (-zyklen) je Instruktion.

Nein!

Eine CPU benötigt für die meisten Operationen mehr als einen Takt, es kann also in den wenigsten Fällen eine Ganzzahl sein.

Mal auf Wikipedia verwiesen.

Daß kurze Instruktionen, welche vollständig in die jeweiligen Ausführungseinheiten passen und binnen eines einzelnen Taktes abgearbeitet werden können und somit zu einer erhöhten IPC führen, dürfte offenkundig und somit nur folgerichtig sein. Bei wahllosen oder gar häufig wechselnden Instruktionsarten kann die nominale Leistung stark abfallen, da durchaus ein leeren (→ flush) der Ausführungseinheiten notwendig sein kann, um zwischen den verschiedenen Instruktionstypen zu wechseln.

Selbst verschiedene Programmiersprachen wie der krasse Unterschied in der Komplexität zwischen Hochsprachen (bspw. C++) und hardwarenahen Sprachen (bspw. Fortran, Assembler) beeinflußt die Auslastung und Effizienz von Ausführungseinheiten (→ pipelining). Auch können das Taktverhälniss der jeweiligen einzelnen logischen Ausführungseinheiten zueinander eine durchaus erhebliche Rolle spielen und zu einer höheren Effizienz innerhalb eines gegebenen Taktfensters führen.

Wie man sieht, ist das Thema nicht annähernd trivial wie es scheint, deswegen wird die Leistung von Prozessoren meist in der eingangs erwähnten Einheit FLOPS (Floating Point Operations Per Second) oder MIPS (Million Instructions per Second) verglichen, also der Leistung von Instruktionen pro Taktzyklus einer fest definierten Art von Berechnungen (i.d.F Gleitkommazahl, häufig auch Fließkommazahl).

---

Smartcom5 überimmt die Auflösungsarbeit da sicher gern. Hat ja vorher schon bewiesen wie unglaublich viel ihm an der Richtigstellung hinsichtlich IPC / IPS liegt.

„Der Umstand, daß wir Feinde haben, beweist klar genug, daß wir Verdienste besitzen.“
— Carl Ludwig Börne, deutscher Journalist, Literatur- und Theaterkritiker, ‚Ueber Etwas, das mich betrifft.‘

Er hatte aber auch Recht: IPC ist halt nicht Single Thread Leistung, sonst hieße es ja "Instructions per clock at the wall"

​

In diesem Sinne

Smartcom