News AMD bei Zen 3 mit mindestens acht Prozent höherer IPC?
- Mitglied seit
- 16.10.2000
- Beiträge
- 24.368
- Renomée
- 9.694
- Standort
- East Fishkill, Minga, Xanten
AMD hat noch nicht einmal alle Zen 2 Desktopprozessoren vorgestellt, da tauchen erneut weitere Gerüchte und Spekulationen zum Nachfolger Zen 3 auf, nachdem in der vorigen Woche bereits eine AMD-Präsentation mit Informationen zu Zen 3 wohl versehentlich kurzzeitig in Netz gelangte (wir berichteten). Laut RedGamingTech soll Zen 3 bei der IPC (Instructions per cycle) gegenüber Zen 2 um mindestens acht Prozent zulegen.
(…)
» Artikel lesen
(…)
» Artikel lesen
Hotstepper
Vice Admiral Special
- Mitglied seit
- 12.04.2005
- Beiträge
- 831
- Renomée
- 117
@Peet007
Das kommt ja schon alleine durch einen gemeinsamen L3 Cache je Chiplet zustande. Dann muss nicht mehr jeder CCX zu CCX Verkehr über das IOD sondern nur noch der CCP zu CCP Verkehr. Sprich... der Traffic halbiert sich.
Das kommt ja schon alleine durch einen gemeinsamen L3 Cache je Chiplet zustande. Dann muss nicht mehr jeder CCX zu CCX Verkehr über das IOD sondern nur noch der CCP zu CCP Verkehr. Sprich... der Traffic halbiert sich.
Was bei Zen 2 gnadenlos zuschlägt ist die VCore Grenze von ca. 1,2 Volt da steigt die Leistungsaufnahme extrem an. Wenn sie mit einer verbesserten Fertigung unter 1,2 Volt bis 4 GHz kommen wäre ja nicht schlecht. Der riesige L3 und IF sind da auch keine Sparwunder wenn Datenmenen drüber müssen.
Ein vereinheitlichter L3-Cache wäre wirklich gut. Denn die Verbindung zwischen den CCXen ist wirklich langsam.
Es gibt ein bekanntes, praktisches Problem der Informatik nach dem ich kürzlich für eine bessere als die verfügbaren Lösungen suchte. Die Standard-Lösung skaliert nicht mit der Anzahl der Kerne / Threads und alle anderen Lösungen die besser skalieren als der naive Ansatz sind alle sub-optimal. Ich hab eine Lösung gefunden die bisher noch keiner gefunden hat und die so gut ist wie es nur möglich ist (hat aber dennoch nen fetten Overhead durch die Lansamkeit der Verbindungen zwischen den Caches). Beim Benchmarken musste ich feststellen, dass die Performance unter Windows 10 nach vier Threads um 35% zurückging. Das lag daran, dass Windows die ersten vier Threads auf einem CCX gruppierte, der fünfte aber dann aber einen Überlauf auf das nächste verursachte.
Die Balken-Gruppen sind die Anzahl der Threads von 1 bis 16. Die Balken in der Gruppe ist die Größe eines lock-freien Puffers den ich benötige um meine Datenstruktur ohne Kernel-Contention zu aktualisieren. Hab den Drop von Gruppe vier Threads auf Gruppe fünf Threads markiert.
Nebenbei sieht man mal den Unterschied zwischen single-threaded und multi-threaded zwischen Gruppe ein Thread und zwei Threads. Da fällt die Performance um 2/3 ab, allein dadurch, dass zusätzlich Cachezeilen-Inhalte zwischen den Kernen hin und her wandern müssen. Also ganz ohne, dass da Kernel-Synchronisation stattfindet.
Es gibt ein bekanntes, praktisches Problem der Informatik nach dem ich kürzlich für eine bessere als die verfügbaren Lösungen suchte. Die Standard-Lösung skaliert nicht mit der Anzahl der Kerne / Threads und alle anderen Lösungen die besser skalieren als der naive Ansatz sind alle sub-optimal. Ich hab eine Lösung gefunden die bisher noch keiner gefunden hat und die so gut ist wie es nur möglich ist (hat aber dennoch nen fetten Overhead durch die Lansamkeit der Verbindungen zwischen den Caches). Beim Benchmarken musste ich feststellen, dass die Performance unter Windows 10 nach vier Threads um 35% zurückging. Das lag daran, dass Windows die ersten vier Threads auf einem CCX gruppierte, der fünfte aber dann aber einen Überlauf auf das nächste verursachte.
Die Balken-Gruppen sind die Anzahl der Threads von 1 bis 16. Die Balken in der Gruppe ist die Größe eines lock-freien Puffers den ich benötige um meine Datenstruktur ohne Kernel-Contention zu aktualisieren. Hab den Drop von Gruppe vier Threads auf Gruppe fünf Threads markiert.
Nebenbei sieht man mal den Unterschied zwischen single-threaded und multi-threaded zwischen Gruppe ein Thread und zwei Threads. Da fällt die Performance um 2/3 ab, allein dadurch, dass zusätzlich Cachezeilen-Inhalte zwischen den Kernen hin und her wandern müssen. Also ganz ohne, dass da Kernel-Synchronisation stattfindet.
Zuletzt bearbeitet:
Ähnliche Themen
- Umfrage
