AMD Pinnacle Ridge: Ryzen 5 2600 mit Taktplus entdeckt [Update]

296
News Mark Mantel Als bevorzugte Quelle auf Google hinzufügen
AMD Pinnacle Ridge: Ryzen 5 2600 mit Taktplus entdeckt
Quelle: PC Games Hardware

In der Benchmark-Datenbank von Sisoftware Sandra ist mal wieder ein interessantes Stück Hardware aufgetaucht: Ein mutmaßliches Qualification Sample eines Ryzen 5 2600 aus der Pinnacle-Ridge-Familie, das auf einem Asus Crosshair VII Hero Wifi gelaufen sei - dem Namen zu urteilen ein erstes X470-Mainboard.

Update vom 19.02.18:

Inzwischen lassen sich erste Ergebnisse zum mutmaßlichen Qualification Sample ZD2600BBM68AF_38/34_Y auch in der Datenbank des Geekbench 4 finden (via Reddit). Der Basistakt in Höhe von 3,4 GHz wird dort noch einmal explizit angegeben, der maximale Boost (ohne XFR) sollte wie angesprochen bei 3,8 GHz liegen.


Originalartikel vom 18.01.18:

Nach den Raven-Ridge-APUs im Februar möchte AMD im April die Pinnacle-Ridge-Prozessoren als Nachfolger von Summit Ridge veröffentlichen. Laut dem Chiphersteller sollen die neuen Modelle einen neuen Silizium-Die erhalten, der bei Globalfoundries in 12LP (12 nm Leading Performance, ein 14LPP-Derivat) vom Band läuft. Dabei winken höhere Taktraten und Verbesserungen am Cache, dem Speicher-Controller und den Latenzen, wobei noch keine konkreten Details genannt wurden.

Solche bieten nun augenscheinlich die Datenbank des Benchmark-Tools Sisoftware Sandra, in der die Kollegen von hardwareluxx.de einen mutmaßlichen Ryzen 5 2600 entdeckt haben. Der Name wird nicht direkt angegeben, Sisoftware Sandra nennt aber einen "AMD Ryzen: ZD2600BBM68AF_38/34_Y". Die Codes kennen wir bereits von den Engineering- und Qualification Samples der Summit-Ridge-Generation, scheinen sich aber minimal geändert zu haben. Die erste Zahl gab früher den Basistakt und die Revision wieder - "2600" hießen dann 2,6 GHz Basistakt und die allererste Revision. Tatsächlich dürfte jetzt die Modellnummer und damit der Ryzen 5 2600 gemeint sein, denn das hintere Anhängsel spricht von einem Basistakt in Höhe von 3,4 GHz und einem Boost von 3,8 GHz (ohne XFR).

Gab es ansonsten keine Änderungen am Code, handle es sich um ein Qualification Sample für den Desktop, das bereits mit den finalen Spezifikationen daherkommen sollte. "BB" steht für eine niedrige TDP von 65 Watt. Unverändert blieben logischerweise der Sockel AM4 und die 16 MiByte L3-Cache. AMD lässt den Aufbau mit zwei CPU-Complexes (CCX) aller Voraussicht nach unangetastet, womit der L3-Cache zweigeteilt wäre. Und natürlich handle es sich noch um einen Sechskerner mit SMT.

Gegenüber dem Ryzen 5 1600 wachse sowohl der Basistakt als auch der Boost um 200 MHz an. Im Falle des Basistakts entspricht das einem Plus von gut sechs Prozent, wobei man von dem Ryzen 5 2600 nicht auf die größeren Modelle schließen sollte. AMD könnte die Modelle schlichtweg stärker voneinander trennen oder auf der anderen Seite näher aneinander rücken. Ein gutes Zeichen ist aber, dass 3,4 bis 3,8 GHz in der 65-Watt-Klasse drin sein sollen. Zudem versprechen die kleineren Architekturänderungen etwas mehr Leistung pro Takt.

Modell Kerne/Threads Basistakt Turbo (exkl. XFR) L3-Cache TDP
Ryzen 5 2600* 6/12 3,4 GHz 3,8 GHz 16 MiB 65 Watt
Ryzen 5 1600X 6/12 3,6 GHz 4,0 GHz 16 MiB 95 Watt
Ryzen 5 1600 6/12 3,2 GHz 3,6 GHz 16 MiB 65 Watt

*angebliche Spezifikationen

296
    • Kommentare (296)

      Zur Diskussion im Forum
      • Von Mahoy Volt-Modder(in)
        Dann ist doch eigentlich ganz einfach: Wenn auch rein logische Kerne an sich gut genutzt werden, aber ihr Ausschluss bessere Performance bringt, obwohl die von ihnen erbrachte Leistung auf weniger Threads verteilt werden muss, dann ist das Problem nicht SMT, sondern die spezifische CPU bzw. deren Architektur.

        Dass die innere Kommunikation von Ryzen noch so ihre Bremsen hat, ist ja bekannt. Es wäre daher interessant zu sehen, ob die gleichen Einbußen auch auftreten, wenn man bei einer Intel-CPU den direkten Vergleich mit aktiviertem und deaktiviertem SMT vornimmt. Dann kann man eine generalisierte Aussage zu SMT treffen, während es bisher nur ein spezifisches Verhalten vom Threadripper ist. Und natürlich ohnehin nur in bestimmten Programmen.
      • Von Mahoy Volt-Modder(in)
        Dann ist doch eigentlich ganz einfach: Wenn auch rein logische Kerne an sich gut genutzt werden, aber ihr Ausschluss bessere Performance bringt, obwohl die von ihnen erbrachte Leistung auf weniger Threads verteilt werden muss, dann ist das Problem nicht SMT, sondern die spezifische CPU bzw. deren Architektur.

        Dass die innere Kommunikation von Ryzen noch so ihre Bremsen hat, ist ja bekannt. Es wäre daher interessant zu sehen, ob die gleichen Einbußen auch auftreten, wenn man bei einer Intel-CPU den direkten Vergleich mit aktiviertem und deaktiviertem SMT vornimmt. Dann kann man eine generalisierte Aussage zu SMT treffen, während es bisher nur ein spezifisches Verhalten vom Threadripper ist. Und natürlich ohnehin nur in bestimmten Programmen.
      • Von gaussmath
        Wenn SMT deaktiviert ist, habe ich über 200 FPS. Die Frames sind nicht fixiert, die 144 FPS sind Zufall.
      • Von Mahoy Volt-Modder(in)
        Einmal davon abgesehen, dass sich bei 144 fps (Ich vermute, die Framerate ist fixiert?) und Frametimes von 7,8 ms jetzt nicht unbedingt erkennen lässt, wo das Problem mit SMT liegen soll ...

        ... stellt sich mir die Frage, wie sehr sich die Situation - behauptetermaßen positiv - verändert, wenn SMT deaktiviert wird, nur noch die 16 Threads zur Verfügung stehen, hinter denen physikalische Kerne stehen und die dann (mit bereits jetzt mit rund zwei Dritteln Auslastung) das allein stemmen müssen, was vorher zusätzlich virtuelle Kerne (mit ebenfalls rund zwei Dritteln Auslastung) mitgetragen haben.
      • Von gaussmath
      • Von Mahoy Volt-Modder(in)
        Zitat von gaussmath
        Gut, mir ging's auch eher um 16 oder sogar 32 Threads.
        Da könnte ich mir vorstellen, dass deshalb, weil nicht alle Kerne/Threads genutzt werden, einige logischerweise vor sich hin idlen, was dann den Scheduler dazu motiviert, die Last öfter mal zwischen diesen Kernen/Threads zu verlagern. Das würde dann, je nach Architektur, mehr oder weniger viel Performance kosten.
      Direkt zum Diskussionsende
  • Print / Abo
    Apps
    PCGH Magazin 07/2026 PC Games 06/2026 play5 07/2026 N-Zone 06/2026 Linux Magazin 06/2026 LinuxUser 06/2026 Raspberry Pi Geek 07/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk