Ich verstehe halt nicht, warum AMD dies wieder tut. Dieser Grund dürfte ja damals auch bei Bulldozer für die Performance in Games maßgeblich gewesen sein. Das ist doch an sich ein Designfehler von Grund auf und AMD übernimmt diesen in Ryzen. Verstehe ich nicht. Würde zu gern wissen, welche Gedankengänge dahinter stecken.
Das ist sicher keine Absicht, sondern eben der Einfachheit geschuldet, denn es ist eben extrem Aufwendig in dem Bereich zu optimieren. Schau Dir an was Intel da getan hat, die TSX Befehle sind ja da nur ein sichtbares Zeichen dafür wie viel Aufwand in dem Bereich der Kommunikation zwischen den Kernen / Threads getrieben wurde. AMD hat für RYZEN 10% weniger Diefläche gebraucht, obwohl die maßgeblichen Strukturen beim 14nm Prozess von GF größer als bei Intel sind, die RYZEN dürften also sogar >10% weniger Transistoren als vergleichbare Intels CPUs haben. Diese zusätzlichen Transistoren bei Intel können durchaus zum Teil für genau solche Optimierungen benötigt werden, die gehen natürlich auch auf die Effizenz, die brauchen ja auch Leistung. Der Preis dafür ist dann eben, dass die AMD CPU dort Nachteile hat, was aber letztlich eine Designentscheidung ist und da dürfte auch das größte Optimierungspotential liegen.
Jetzt mal unabhängig davon, ob die Stellungnahme von AMD stimmt oder nicht...
Scheint es wohl:
https://www.hardwareluxx.de/index.p...keine-probleme-mit-dem-thread-scheduling.html]
Dabei weiß doch jedes Kind, dass Fehler von Firmen nur dann eingestanden werden, wenn es gar nicht mehr anders geht.
Da ist Intel seit dem Rechenfehler der ersten Pentium mit den Erratas ja zum Glück erfreulich offen.
Manche schreiben jetzt auch, dass die Performance und Architektur der CCX-Kommunikation schuld sei. Aber würde dann ein 32C Naples so performen wie man es gesehen hat?
Was hat man denn gesehen? Doch eine Anwendung bei der Aufgrund der Problemstellung die Thread sehr wahrscheinlich weitgehend unabhängig auf je einem Teil der Daten arbeiten können, genau die Schokoladenseite von RYZEN und NUMA ist dann auch kein Problem. Die neuen AMD und die Intel CPUs haben eben unterschiedliche Stärken und Schwächen, für Unternehmensanwender ist das aber weniger problematisch, die kaufen Server-HW ja meist für eine bestimmte Nutzung und können sich dann die dafür besser geeignete CPU aussuchen. Heimanwender wollen ja meist viele verschiedene Anwendungen auf ihrem Rechner laufen lassen und müssen daher eben selbst entscheiden wo sie die Schwerpunkte setzen, sollten also die Stärken und Schwächen der CPUs kennen um entscheiden zu können welche für sie besser geeignet ist.
Wie ist das nun mit dem Umstand, dass die Ryzen-CPU ein 2-Sockelsystem darstellt und dem NUMA-Handling?
Sehr wahrscheinlich dürfte schon ein Naples kein Land gegen eine Intel CPU mit annährend so vielen Kernen sehen, wenn viel Kommunikation zwischen den Threads nötig ist und mit den nächsten Skylake kommt ja sogar ein nativer 32 Kerner, mal sehen wie der dann auch bei solche Aufgaben abschneidet wo Naples gut ist.
Obwohl ich die den Verdacht durchaus für plausibel halte gibt es einen Punkt, der mich doch daran stört. Die Kommunikation zwischen den Kernen erfolgt in erster Linie über den L3-Cache. Laut AMD können alle Kerne eines CCX mit der durchschnittlich gleichen Latenz auf diesen zugreifen.
Der Datenaustausch erfolgt vielleicht über den L3 Cache, aber was passiert intern, wenn ein Thread einen Mutex setzt und die SW auf dem anderen Kern auch auf diese nun geschützten Bereich zugreifen möchte? Dies muss intern kommuniziert werden, damit der Task Scheduler des OS diesen zweiten SW-Thread solange anhalten kann, bis der Mutex freigegeben wurde, dann kann der Thread weiterlaufen, muss aber natürlich die Daten zu sehen bekommen die der andere Thread dort hinterlassen hat und nicht ggf. das was dort vorher stand.
Das ist alles nicht banal, wie genau das gemacht wird, verraten die Hersteller nicht und man sieht es auch nicht auf den schön bunten Folien zur Architektur der CPU. Aber wie immer und überall, dürfte es auch hier die aufwendigere und dafür schnellere oder eben die einfachere aber dafür langsamere Lösung geben und nach dem was Intel in dem Bereich getan hat, dürfte deren Lösung eben die aufwendigere sein und AMD hat dort vermutlich noch Optimierungspotential. RYZEN ist ja nun die erste CPU auf der Basis der neuen Architektur, da kann man nicht erwarten, dass die in allen Bereichen schon sehr gut optimiert werden konnte, dies wäre illusorisch.
AMD hat sich auf eine hohe Rohleistung und eine gute Effizienz konzentriert und der R7 1700 ist bei seinem geringeren Takt ja auch sehr effizient, die höher getakteten Modelle verlieren dann einiges an Effizienz, was aber auch normal ist.
Warum also gerade Spiele, die eher selten mehr als vier Kerne nutzen so problematisch sind, lässt sich dadurch nicht erklären.
Bei Spiele hängt alles voneinander ab, da ist viel Kommunikation zwischen Threads nötig. Bei Anwendungen / Benchmarks wie Cinebench oder Renderprogrammen könne die Thread dagegen weitgehend unabhängig auf je einem Teil der Daten arbeiten und da glänzt RYZEN dann ja auch.
Außerdem sollten dann Spiele, die mehr Threads nutzen tendenziell auch stärker einbrechen, was ich bei den Tests auch nicht erkennen kann.
Die Spiele sind ja auch unterschiedlich, außerdem müsste man wissen wie weit die Threads jeweils miteinander kommunizieren. Spezielle Benchmarks die dies simulieren wäre da aussagekräftiger.
Bei dem Punkt wäre es interessant zu sehen, wie sich Ryzen mit einem deaktivierten CCX verhält.
Ja, aber kann man denn eine CCX deaktivieren? Man könnte aber einen Benchmark so schreiben, dass er einmal die Threads an die logischen Kerne festbindet und dann jeweils zwischen zwei die Performance der Synchronisierungen testet, dann könnte man entweder den Unterschied zwischen den Kernen eines CCX sehen oder nicht.
Wäre das Problem bei der Kommunikation innerhalb des CCX, also im L3-Cache
Wie gesagt glaube ich nicht, dass es alleine über den L3 Cache läuft. Aber die ganzen internen Caches und Register sind Teil des Problems, es muss ja sichergestellt sein, dass deren Inhalte auch immer aktuell sind, wenn der SW Entwickler die entsprechenden Synchronisierungsmechanismen einsetzt, nur kenne ich eben keinen verfügbaren Benchmark der sowas explizit ermittelt, deshalb hatte damals auch mal einen eigenen Test dafür geschrieben. Den müsste ich mal wieder raussuchen und überarbeiten.
Aber vielleicht bin ich auch auf der falschen Fährte und das alles hängt mit diesem Problem zusammen:
https://www.hardwareluxx.de/index.p...hen-zu-langsam-auf-und-temperatur-offset.html Ich hatte mich schon gewundert, wieso RYZEN z.B. bei Blender im Vergleich zu Intels CPUs umso besser abschneidet, je kürzer der Benchmark dauert und ebenso, wieso ein auf 3,8GHz übertakteter 1700 nicht an die Leistung eines 1800X bei gleichem Takt (also auf 3,8GHz übertaktet) kommt, wobei der 1800X dann mal schneller und mal langsamer als @Stock war, der taktet also @Stock mal höher und mal unter 3,8GHz. Auch muss man schauen wie weit welche Tools was überhaupt korrekt auslesen, siehe diese scheinbarer Übertakten nach dem Aufwachen aus dem Ruhezustand von dem auch berichtet wird.
Fest steht: RYZEN hat noch einige Geheimnisse die es zu ergründen gilt.
und als unternehmen welches dann 50 von den kisten kauft fallen die 25k auch nicht ins gewicht, wo wir ja alle wissn dass in der wirtschaft nicht so aufs geld geschaut wird, da hat mans ja
