mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.420
Das Ryzen "Dev Kit Program" besteht darin, Entwicklern entsprechende Ryzen Systeme zur Verfügung zu stellen, bisher >300. Das ist kein spezielles Software Kit oder so, was du downloaden kannst.Frage mich grade wieso AMD dieses "Ryzen Dev Kit" offenbar nicht frei veröffentlich hat (ich finde es jedenfalls nirgends).
Ich. Du hast pauschalWer redet denn vom 6900k?
geschrieben. Aber anscheinend hast du dir nicht mal ansatzweise das komplette Intel Portfolio angeschaut. Dir ist schon bewusst, dass die mehr als nur den i7-7700K im Angebot haben?Bekomme ich bei Intel für mein Geld mehr Spielleistung? Ja.
Nein, tut er nicht, zumindest im Vergleich zum R7 1800X. Das wurde ja mittlerweile von mehreren Seiten gezeigt. Mal davon abgesehen ist selbst der i7-7700K keine gute Wahl für Spieler, wenn es um P/L geht. Da muss man sich schon wundern, warum der trotzdem von einigen so gehyped wird. Ein i5-7600K wäre aktuell die deutlich sinnvollere Empfehlung für Spieler. Liegt selbst in gut multithreaded Spielen maximal 15% hinter dem i7, kostet aber gut ein Drittel weniger. Ryzen 5 wird den i7 ebenso bezüglich P/L alt aussehen lassen.Der 7700k ist genauso günstig wie der 1700 und der 7700k bietet einfach mehr Spieleleistung. Selbst mehr als der deutlich teurere 1800x.
Und das hat jetzt konkret welches Ausmass? MMn ist das bisher alles nur aufgebauscht, basierend auf irgendwelchen womöglich auch falsch interpretierten Beobachtungen oder gar falsch durchgeführten Tests. Ich kann bei einer Anwendung, die ich auf verschiedenen Kern-Pärchen meines i5 laufen lasse, ebenfalls unterschiedliche Ergebnisse provozieren, völlig ohne CCX Design. Und nu?Dann schau nochmal genau. Dadurch, dass die Kerne bei AMD in den beiden CCX CLustern liegen kann es vorkommen, dass Threads, die viel miteinander kommunizieren müssen (wie in vielen GAmes) auf je einem CCX Modul liegen und langsamer kommunizieren können als wenn beide auf einem Modul verarbeitet werden.
Bleiben wir doch mal bei den Fakten. Fakt ist, dass der Summit Ridge L3 an einen Kern mit dem gleichen Durchsatz angebunden ist wie die 2 CCX untereinander durch das Data Fabric, nämlich 32 Byte pro Takt. Allerdings läuft der L3 mit Kern-Takt, während das Data Fabric mit Speichertakt läuft. Kann man sich hier anschauen. Bei einem Speichertakt von 1333 MHz (DDR4-2667) stünden damit knapp 43 GB/s für das Data Fabric zur Verfügung. Auch wenn sich L3, MC und IO diese Bandbreite teilen müssen, was für Kohärenz notwendig ist, das ist mehr als genügend. Kommunikation zwischen Kernen ist bei typischen Desktop Anwendungen sehr begrenzt. Dafür braucht es keine grosse Bandbreite. Anders mag das bei Servern und grossen Datencentern sein. Deshalb ist dort auch NUMA ein so wichtiges Thema. Also ich denke nicht, dass die Bandbreite zwischen den CCX in irgendeiner Form ein Flaschenhals ist.
Was bei Desktops wichtiger ist, Latenz. Durch den niedrigeren Takt liegt die Latenz des Data Fabric natürlich deutlich höher als beim L3, irgendwo zwischen L3 und RAM. Man könnte es auch so sehen, der L3 des anderen CCX ist für einen Kern sowas wie ein Level 3,5 Cache. Die Preisfrage ist nun, welche Auswirkungen hat das auf die Performance? Generell kann man sagen, jedes höhere Level in einer Speicherhierarchie hat immer weniger Auswirkungen, weil es von den niedrigeren Leveln gepuffert wird. Ist der L1 Grütze, merkt man das sofort bei der Performance, praktisch in jeder Anwendung. Ob man nun aber DDR4-2133 oder DDR4-3200 nutzt, macht sich nur in wenigen Anwendungen und auch dort nur begrenzt bemerkbar. Und ähnlich verhält es sich auch beim L3. Dieser wird schon gut durch L1 und L2 gepuffert, so dass höhere Latenzen nur begrenzte Auswirkungen haben. Das gilt für den L3 beider CCX. Und genau das zeigen Tests bisher auch, inklusive Spiele, egal ob 1+1 vs 2+0 oder 2+2 vs 4+0, die Testergebnisse unterscheiden sich bis auf kleinere Abweichungen praktisch nicht. Und die paar wenigen Ausnahmen können in beide Richtungen ausschlagen. Was dafür spricht, dass die unterschiedlichen Ergebnisse an anderen Faktoren liegen müssen, nicht an irgendeinem "massiven" Flaschenhals des CCX Designs.
Also nochmal, nicht dass wir uns falsch verstehen, natürlich wäre es optimal, wenn Anwendungen und Thread-Scheduler Threads immer so ausführen, dass gerade grosse Mengen an gemeinsam genutzten Daten im selben CCX bleiben. Aber selbst wenn sie das nicht tun, die Auswirkungen in der Praxis sind sehr gering, kaum messbar. Deine Behauptung, dass hier "massiv Potenzial" verschenkt werden würde, ist schlichtweg unbegründet.
Dass Intel mehr Optimierung in die Kommunikation zwischen den Kernen gesteckt hat, wage ich stark zu bezweifeln. Schliesslich hat AMD den ersten nativen x86 Prozessor mit shared L3 rausgebracht, nicht Intel. Ausserdem hat auch Intels Ansatz so seine "Problemchen". Dazu müsste man nämlich wissen, dass ein Kern nur auf das direkt angebundene L3 Segment (2 MB) mit der niedrigsten Latenz zugreifen kann. Der Zugriff auf die anderen L3 Segmente kostet zusätzliche Latenz. Zumindest innerhalb AMDs Zen CCX kann jeder Kern auf die vollen 8 MB L3 mit der gleichen durchschnittlichen Latenz zugreifen. Mal davon abgesehen ermöglicht es AMD mit so einem Kern-Cluster sehr flexibel Designs zu gestalten. Intel muss praktisch immer wieder die Kerne neu zusammenbasteln, was zusätzlich Geld und Zeit kostet.Intel hat seine Kerne alle nebeneinander liegen (keine klar getrennten Cluster) und zudem mehr Arbeit in die Optimierung gesteckt was die Kommunikation zwischen Kernen angeht.
Zuletzt bearbeitet: