AMD Ryzen Threadripper 2990WX und 2950X im Test: Mit Vollgas an Intel vorbei

Ach, der 2990WX ist für Workstations gedacht? :confused:

Ich dachte das steht für /Ironie an 2990 Windows Gaming EXtreme /Ironie aus :bigok:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
So liebe Software Entwickler jetzt wollen wir aber auch so schnell wie möglich Software sehen die mit dieser Leistung umgehen kann.
Die theoretische Leistung so einer CPU kann man nur ausnutzen, wenn die Aufgabe es auch erlaubt diese entsprechend zu parallelisieren und nicht alle Aufgaben sind parallelisierbar, wenn ein Rechnung vom Ergebnis der vorherigen abhängt, geht dies nicht. Außerdem braucht man auch eine Threadsynchronisierung, die kostet genauso wie der Starten es Threads im OS eben auch Zeit und daher lohnt sich Parallelisierung die bei ganz kleinen Aufgaben auch nicht, sondern verschlechtert die Performance sogar. Wer keine Ahnung von SW Entwicklung hat, kann leicht daherreden, sollte es aber selbst erstmal besser machen und wird dann beim Versuch so manches begreifen und hoffentlich künftig weniger dumm daherreden.
du kannst mit nem Intel QC auch die Intel HEDT komplett versägen, wenns um die richtige SW geht...wenns halt auf wenige Threads mit viel Takt optimiert ist, wie hier auch.
Die Skylake-X takten bei Last auf wenigen Kernen auch schon sehr hoch, so einfach versägt man die mit einer Mainstream CPU nicht mehr.

Zieh die blaue Brille ab und schau dir objektiv an, wofür die jeweiligen SKUs gemacht sind.
Schau mal was AMD dazu schreibt:
Tolle Aussage "wenn man den Modus nimmt, der bekanntermaßen schlechter für Spiele ist, was auch so kommuniziert wird, dann ist die Performance schlecht".
AMD sagt, man könnte:
Wenn man rendert, also alle Kerne aktiviert hat und daneben spielen will und man eine mies Spielesperformance.
nettes Nischenprodukt für die die es brauchen können!
Eben, vor allem der 2990WX ist ein Nischenprodukt, denn in den meisten Anwendungen ist der 2950WX auch noch schneller, nur bei synthetischen Multithread Benchmarks kann der 32 Kerner punkten.
Jetzt fehlt bloß noch, dass jmd. die Überschrift dieses Tests als reißerisch bezeichnen tut. :fresse:
Ist sie doch, denn bei Anandtech findet man auch Benchmarks wo der i9-7980XE vorne liegt und dies sind nicht nur solche die nur Singlethreadperformance fordern.
Wo ist hier der Unterschied zu Intel CPUs mit Mesh? Die sind in Games doch genauso wenig brauchbar und werden von den normalen Desktops teilweise eklatant abgehengt.
Belege? Wo werden die Skylake-X beim Gaming genauso "eklatant abgehengt" (abgehängt)? Die performen nicht so optimal wie die Mainstream CPUs, aber auch längst nicht so schlecht wie ein 2990WX wenn 32 aktiven Cores.
Dann mal darüber nachdenken wie die Threadqueue ohne Support und Dynamic Memory agiert, ohne zugewiesene Ressourcen.
Was meinst du mit "die Threadqueue ohne Support und Dynamic Memory"? Ich entwickle seit 35 Jahren Software, seit 20 Jahren intensiv multithreaded, aber Threadqueues verwalten die Task Scheduler des OS wenn es darum geht welche Prozesse in welchem Zustand sind und Dynamic Memory kenne ich nur im Zusammenhang mit der dynamic memory allocation, also dem alten alloc in C oder new oder wie auch immer eine Programmsprache dies umsetzt, wenn dies schiefgeht kann man meist nicht viel mehr machen als eine Fehlermeldung auszugeben und das Programm zu beenden. Wie soll ein Prozess ohne Ressourcen auch überhaupt laufen?
Wäre es nicht irgendwie möglich, einen Prozess an einen DIE/Node zu binden, damit alle seine Threads auf diesem DIE/Node bleiben?

- - - Updated - - -

SetThreadAffinityMask function | Microsoft Docs
Das ist ein alter Hut, aber es verrät einem nicht auf welchem CCX der Core sich befindet.
Programm schreiben, dass alle Threads eines Prozesses analysiert, z.B. deren User/Kernel-Time checkt und dementsprechend verteilt. Gibt es dafür noch kein Tool?!
Dies ist eine der Aufgaben des Task Schedulers des OS und soweit ich gelesen haben, macht der bei den aktuellen AMD CPUs die Wechsel zwischen den Kernen längst nicht mehr so hektisch wie früher.
Wenn ich mich nicht verlesen, bzw. etwas überlesen habe, könnte man damit sehr einfach alle Threads an die ersten 8 Kerne binden, oder an die Kerne 9 bis 16 usw., wie man halt möchte. Wäre damit das Problem nicht gelöst?
Vermutlich nicht, denn wen man die an die ersten 16 Cores (also 8 physikalischen Kerne + SMT) bindet, dann wären diese bei de 2970W immer noch über 2 Dies verteilt, bei dem sind ja nur 6 Kerne pro CCX aktiv. Die SW müsste also für jede CPU einzeln optimiert werden und außerdem dürfte bei der UMA Einstellung auch RAM verwendet werden welches nicht an dem Die angebunden ist zu dem die Kerne gehören.
Kann man die CPU gebrauchen? Ja oder Nein?
Wie immer: Es hängt von der Nutzung ab. Wenn Du die nicht kennt oder nicht weißt was für Anforderungen diese z.B. bzgl. der Speicherbandbreite stellt, dann könnte es ein teurer Fehlkauf werden. Viel hilft viel, gilt eben auch hier wie so oft
Ich weiß jetzt nicht ab wann (welches Framework), aber das gibt es schon (sperren aufgrund threadsicherer Prozeduren). Das Problem ist das zur Threadsicherheit eine gesamte bereits gewrappte Enumeration gesperrt werden kann und die Queue dann folgerichtig wieder neu synchronisiert werden muss.

Das kann zu einem Memory "Ballooning" Effekt führen, wie man diesen aus VMs kennt.
???
Kann es sein das du ein Bot bist der einfach irgendwelche Begriffe aus dem Zusammenhang gerissen postet, obwohl diese keine Sinn ergeben und in keinem Zusammenhang stehen, also totalen Schwachsinn ergeben?
Für die Konfigurationen (OS) müssen dann ein Interagtionsservice geladen werden (weil damit nicht alle umgehen können), wobei dann für bestimmte Operationssysteme Werte manuell (Startup) gesetzt werden müssen. Ansonsten wird bei Ressourcenknappheit wohl ein Swapping stattfinden. Was sich aber nachweisen lassen würde. Dabei bricht natürlich auch die Bandbreite ein.
Interagtionsservice? Swapping innerhalb einer CPU und deswegen bricht die Bandbreite ein? Es muss sich hier um einen Bot handeln.
Welcher Thread dabei Windows zugerechnet werden kann und welcher dem Spiel, oder jeder anderen Anwendung die im Hintergrund läuft ist schwer zu sagen, und wird uns MS wohl auch nicht so einfach verraten.
Doch, die kann man im Task Manager oder Prozess Explorer sogar sehen.
 
@Holt

Mein Beitrag war ironisch gemeint. Habe in der Familie jemand der Software entwickelt und weiß aus seinen Berichten über die Schwierigkeiten teilweise auf Kompromisse zu setzen. Es ging mir in meinem Beitrag nur auf die Richtung hinzuweisen die hier eingeschlagen wird wenn die Leute sich genug über die Leistung der CPU´s gestritten haben und bei den Hardwareentwicklern keinen Schuldigen finden. Irgendwann sind dann die Softwareentwickler die Bösen die nichts auf die Reihe bekommen.
 
Naja, der generalisierte Einzelfall besteht in Anwendungen ohne nennenswerten (RAM)-IO. Bisher:
- manche Renderer (aber auch nicht alle, bspw. Blender)
- Schach
.... Ich denke also, es hat schon einen Grund, weshalb EPYC 4 Speicherinterfaces bringt ;).

CAD fehlt da noch. Wobei man dort auch klar unterscheiden muss. Derzeit ist die beste CAD Cpu für die Modellierung, Zeichnungsableitung und allgemeine Aufgaben der 8700K (ja, echt! :d ) Für alles was Simulation (CFD/FEM), Rendering und so weiter angeht braucht man was dickeres.

VMs fehlen auch noch, zumindest wenn man sehr viele davon einsetzt.
 
Ich beziehe mich meist auf den 2990WX. Wird meiner Meinung nach sonst zu viel, das Prinzip, bzw. die Problematik ist ja immer die gleiche.

Das ist ein alter Hut, aber es verrät einem nicht auf welchem CCX der Core sich befindet.
Kann man nicht annehmen, dass die einfach von 0 bis 63 durchnummeriert sind? Also 0 bis 7 auf DIE0-CCX0, 8 bis 15 auf DIE0-CCX1, 16 bis 23 auf DIE1-CCX0, usw.?

Dies ist eine der Aufgaben des Task Schedulers des OS und soweit ich gelesen haben, macht der bei den aktuellen AMD CPUs die Wechsel zwischen den Kernen längst nicht mehr so hektisch wie früher.
Dieser scheint ja aber immer noch die Threads "ungünstig" zu verteilen, oder warum laufen manche Spiele im GameMode mit nur einem aktiven DIE soviel besser?
SetProcessAffinityMask ist natürlich sinnvoller, erspart einem selber die Threads zu analysieren, der Scheduler macht das sicher eh besser.

Vermutlich nicht, denn wen man die an die ersten 16 Cores (also 8 physikalischen Kerne + SMT) bindet, dann wären diese bei de 2970W immer noch über 2 Dies verteilt, bei dem sind ja nur 6 Kerne pro CCX aktiv. Die SW müsste also für jede CPU einzeln optimiert werden ...
Ich habe bei meiner Überlegung nur an den 2990WX gedacht. Beim 2970W müsste man natürlich anders vorgehen.
Ich dachte pro DIE gibt es zwei CCX. Wie ist das beim 2970W? Pro CCX nur drei Kerne, ein CCX mit vier und einer mit zwei? Oder ganz anders?

und außerdem dürfte bei der UMA Einstellung auch RAM verwendet werden welches nicht an dem Die angebunden ist zu dem die Kerne gehören.
Wie darf ich mir das mit dem Speicher vorstellen. Ich habe gelesen, das beim 2990WX jeweils zwei DIEs (0 und 2) zwei Speicherkanäle und 32 PCIe-Lanes haben. Die anderen DIEs (1 und 3) haben keinen direkt Zugriff auf RAM oder die PCIe-Lanes. DIE0 und DIE2 haben "direkten" Zugriff auf den gesamten Speicher. Wenn ich jetzt einen Prozess an DIE0 binde, können dessen Threads doch direkt auf den gesamten Speicher "ohne Umwege" zugreifen? Ob UMA oder NUMA ist in dem Fall doch egal?

Ich dachte die teils schlechte Performance in Spielen liegt daran, dass mehrere Threads auf unterschiedlichen Kernen den selben Speicherbereich nutzen. Nachdem ich das nochmal alles durchgelesen habe, liegt es eher an den Threads, die auf den DIEs liegen, die keinen direkten Zugriff auf den Speicher haben. Ein Render-Thread, der viel an die Grafikkarte schickt, müsste ohne direkten PCIe-Zugriff auch langsamer sein. Geht meine Vermutung in die richtige Richtung?
 
??
Diese Art von Hardware gibts doch seit Anno Assbach... Aber sie gibt/gab es eben nur in Bereichen, die mit dieser Architektur primär eben auch was anfangen können oder konnten. Und ich sag dir noch was
Ich dir auch.
Wer für den WX nichts sinnvolles auf der Platte hat, der will auch keinen 7980XE. Numa hin oder her. Wenn es wirklich drauf ankommt, kauft man sich halt den Epyc oder Xeon. Bei allen anderen tut es auch ein X. In FPS ist der 2990WX beim Daddeln ~30% schwächer als ein 2950X. Auch ein 2920X kommt noch (12 Kerne).
Den 2700X gibts ja auch noch, wenn das alles nicht gefällt...

Der 2950X - also der 16-kerner davon - ist meist mind. gleich schnell, nicht selten messbar schneller, als ein i9-7980XE, der 2 Kerne mehr hat und quasi (noch) das Doppelte kostet.
Kann es übrigens sein, daß du mit einer harten Zockeranalyse des 2990WX, eben nur vom 2950X ablenken wolltest?

WX ist für Leute, die perfekterweise Epyc-Platform gebrauchen könnten, sich das aber nicht leisten möchten. Alle anderen werden problemlos mit den X auskommen.
Wer AMD einfach nur nicht mag, wird sich dann dafür was von Intel holen. Bald mit einem viel besserem P/L. Dank AMD.

Verweigere dich nicht fortlaufend der Realität.
 
Zuletzt bearbeitet:
WX ist für Leute, die perfekterweise Epyc-Platform gebrauchen könnten, sich das aber nicht leisten möchten. Alle anderen werden problemlos mit den X auskommen.
Nur blöd, dass die Leute dann leider nicht nur 16 Rechenkerne zusätzlich haben, sondern meist auch ein Problem damit, dass eben 80% ihrer Anwendungen besser nicht auf den Rechenkernen laufen sollten. Für den Desktopnutzer mit Windows ist das imho schon ein Problem, da man da scheinbar nicht so einfach (wie es unter Linux mit dem cgroups-Subsystem der Fall ist) den Desktop auf Die0 setzen kann und dann auf den restlichen Dies einfach wenig IO-intensive Rechnerei laufen lässt (und hofft, dass alle IOs auf dem Die 2 landen).

@Tzk: sehr viele VMs ohne Speicher und IOPS ist eine gaaaanz schlecht Idee.

@Goderion: https://scr3.golem.de/screenshots/1808/Ryzen-Threadripper-2990WX-Test/thumb620/Threadripper-v2-Review-01.png. Wenn also die Threads auf Die 1 und Die 2 Daten aus dem RAM brauchen, dauert es lang.
 
Sorry, aber wie kann es denn sein, dass mit dem stärksten mainboard beim overclocking die spannungsversorgung limitiert?
 
Bin ja mal gespannt, ob AMD die Limitierungen des Threadripper-Designs in der Zukunft wird optimieren können.

Auf jeden Fall hat AMD am Zen-Design noch so viele Optimierungsmöglichkeiten, um noch mehr Leistung rauszuholen, dass ich als Intel Sorgen hätte.

Intel quetscht seit Jahren den letzten Rest aus der Core-Architektur und setzt Dank AMD endlich mal Kerne oben drauf.

Mal sehen, was da die nächsten Jahre noch kommt.
 
Sachlich bleiben ... Mission FAILED! :fresse:

So habe ich das verstanden:
Ich glaube eher, es geht fdsonne um das grundsätzliche Problem vom neuen TR, dass es aufgrund der Speicheranbindung bei Anwendungen zu großen Performanceeinbußen kommen kann. Alle Anwendungen, bei denen sich unterschiedliche Threads die gleichen Daten/Speicherbereiche teilen, werden darunter leiden. Windows verschiebt die Threads auf der CPU ständig hin und her, vermutlich zur besseren Lastverteilung. Starte z.B. Prime95 mit nur einem Arbeiter. Im Taskmanager wirst du einfach erkennen können, dass die Auslastung ständig durch die Kerne wandert und nicht auf einem Kern bleibt. Wenn Du jetzt ein Programm mit zwei Threads hast, die beide intensiv auf die selben Daten zugreifen, kann es beim neuen TR leicht passieren, das Thread 1 auf DIE 0 sitzt und Thread 2 auf DIE 1, und schon bricht die Performance signifikant ein.

AMD erwartet jetzt von Microsoft, dass diese das System zum Verteilen der Threads an den neuen TR anpassen, anstatt selbst, z.B. durch Treiber, die Problematik zu lösen. Finde ich auch recht cheesy und da ist die Kritik von fdsonne vollkommen gerechtfertigt.

Und wieso ist es schon wieder so spät ... um 6:00 Uhr wieder aufstehen ... NARF!
Gute Nacht!
Das der Compiler einfach wild Threads durchreicht war schon immer ziemlich dämlich. Und da wäre eine Lösung schon länger fällig. Das kostet ja schon bei normalen CPU Performance und Energie. Mit Pech Beides, weil der Turbo einbricht, weil man ja unbedingt noch 2 Kerne kurz wecken musste, damit die 5 Sekunden an irgendetwas rumrechnen.

Aber ja, sachlich ist was Anderes.
 
Ich nichtsachlich war Saladin, der immer noch nicht beurlaubt und gemoddet ist. Damit euch der Spaß nicht entgeht, wenn das passiert:
fdsonne, du musst echt mal aus deinem Kellerloch raus. Geh mal abends raus, trink n Bier, knall ne Alte oder mach mal sonst irgendwas was mit der realen Welt zu tun hat.

Den Scheiss kann man sich ja hier echt nicht geben. Da laberst du hier was von Gaming Performance bei so ner Kiste und heulst rum das der nicht so schnell ist wie du kleine Sissy es gerne hättest. Das Teil kauft sich niemand zu zocken, vielleicht raffst du es irgendwann auch mal. Ach und natürlich weißt du es auch besser als AMD, sind ja alle anderen auf diesem Planeten halbdebile Primaten, nur eure Heiligkeit hat Eier aus Stahl und das gesamte Menschheitswissen gepachtet.

Und nur weil man wild Begriffe durcheinander wirft, wird es auch nicht besser ;). Der Compiler hat mit dem Threadscheduling jetzt eher sehr wenig zu tun (zumindest in den üblichen Bibliotheken/OS).
 
Ist schon irgendwie komisch von AMD, dass die sich nicht vernünftig darum kümmern. Meiner Meinung nach müssten die irgendwie dafür sorgen, dass die Threads vernünftig verteilt werden und das nicht einfach auf Microsoft abwälzen.

Wenn dies so einfach wäre, so würde es AMD sicherlich auch tun.
Problem ist nur, AMD kann nicht einfach hergehen und den Sheduler von Windows umschreiben. Dazu haben sie einfach keine Rechte, denn der Urheber sind nicht sie sondern Microsoft. Also muss alles vorher mit Microsoft abgesprochen werden. Aber wenn diese nein sagen, kann AMD auch nichts dagegen machen. Was aber zu bezweifeln ist, da Microsoft ebenfalls ein Interesse daran hat die CPUs so schnell wie möglich auf ihrem Betriebssystem laufen zu haben, siehe Anpassung an Ryzen.

Das es ein Problem mit Windows gibt, wurde schon bestätigt, denn Benchmarks auf einem anderen Betriebssystem wie Linux sind deutlich besser und deklassieren förmlich die gesamte CPU-Liga! :eek:
 
Ich glaube eher, es geht fdsonne um das grundsätzliche Problem vom neuen TR, dass es aufgrund der Speicheranbindung bei Anwendungen zu großen Performanceeinbußen kommen kann.

Ich hätte mir von AMD eher gewünscht, dass jeder DIE einen Speicherkanal hätte bekommen. Das wäre das mMn rundere Produkt gewesen. Es lässt hier und dort ein paar Prozent liegen bei Software, die stark über Bandbreite skaliert aber absolut gar nichts mit NUMA anfangen kann. Unter Teillast bis Vollast hingegen würde das sogut wie keinen Unterschied machen. Das was jetzt auf den beiden Compute DIEs läuft und die Daten über die Fabric holt, hätte das dann im anderen Aufbau auch getan, wenn der local Memory nicht mehr hätte gereicht.

Finde ich auch recht cheesy und da ist die Kritik von fdsonne vollkommen gerechtfertigt.
Das im Scheduler zu drehe ist ja nur das eine... Der Scheduler kann das halt für Last <50%, indem er, wie bspw. bei SMT schon gesehen, einfach die Last erst dann auf die Compute Nodes legt, wenn explizit gefordert oder es gar keine anderen Ressourcen mehr gibt. Das heist unterm Strich dann, der Prozessor skaliert bis 16C wie eben der 2950X auch - und darüber dann je nach Software mal gut, mal nicht gut.
Würde man aber, wie oben erwähnt, die Anbindung ändern auf 1CH per DIE, dann wäre es wurst egal wo die Threads laufen. Jeder hätte seine Anbindung, schmal aber vorhanden. Und es würde funktionieren.

Man darf sich da aber auch nix vormachen. Damit AMD das hätte einbauen können hätten sie für den 2970/2990WX den Träger umvertraten müssen. Also nicht mehr 1:1 die gleichen CPUs vom Band laufen lassen, sondern welche mit Anbindung 4x1 und welche mit 2x2. Aufwand für ne Niesche, der in einem ähnlich schlechten Verhältnis stehen würde wie der Wunsch, dass Intel eine Sonderedition ala 8086k verlötet -> sowas ist wirtschaftlich nicht drin.

MMn ist das Anbindungsproblem einfach nur das Resultat daraus, dass man sich irgendwann nach der Entscheidung pro 16C Threadripper auf 32C geeinigt hat. Das war sicher so nie im Plan. Denn wäre es im Plan, hätte man 1:1 nen Teildeaktiveren Epyc 1P Sockel, Träger unter der CPU, Anbindungslayout bei den Boards usw. nehmen können. -> stattdessen gabs ne eigene Linie, eigene Produkte usw. Der 16C ist damit leicht im Vorteil, >16C aber im Nachteil

Gute Frage. Per SetProcessAffinityMask kann ich anscheinend leicht ein Programm an die ersten 16 logischen Kerne binden, also auf DIE/NODE 0. Eigentlich müsste dann doch Windows alle anderen Sachen auf die restlichen Kerne verteilen. Sollte das Windows nicht geregelt kriegen, muss man hier halt auch wieder "Hand" anlegen und z.B. den Encoder an die restlichen 48 logischen Kerne binden.
Windows kann das schon - aber im Moment geht der Threadscheduler davon aus, dass bei 4x NUMA Nodes auch 4x Speicher vorhanden ist. Denn das ist bis dato bei ALLEN CPUs der Fall, die NUMA mit der Nodeanzahl 2 oder mehr nutzen, es sei denn, es ist falsch konfiguriert. Der "Sinn" dahinter ist auch einfach erklärt. Als Entwickler möchtest du, dass der Scheduler die Threads auf einem Node hält, weil dort die Daten liegen (Caches/RAM, ggf. sogar Storage -> PCIe) - als Entwickler wirst du auch, wenn du NUMA aware programmierst, diese Umstände berücksichten. Bspw. dass deine Software dann einfach bei mehr Nodes einfach "mehr" Aufgaben verteilt. Rendering, Encoding usw. können das idR gut abdecken. Oder im Serverumfeld. Da gibts viele kleine Tasks, oft unabhängig von einander, das Skaliert dann sehr schön.
Hier aber hat es eben zwei Nodes ohne RAM. Sobald Threads auf den Compute Nodes laufen, laufen die Speicherzugriffe über die IF. Das ist das, was jeder Entwickler verhindert sehen will, weil es ein Performancekiller ist. Auch bei der im Vergleich wirklich schnellen IF von AMD (ggü. alten Intel QPI Umsetzungen oder HTT bei AMD damals noch)

Deswegen sagte ich ja oben auch schonmal, nicht der UMA Mode ist die Basis, sondern normal ist eigentlich der NUMA Mode mit Software, die das auch kennt die Basis. Dort ist dann auch niemals ein UMA Konstrukt schneller - weil es immer nur Nachteile/Kompromisse bereitstellen kann, ggü. dem, wie der Entwickler das nativ beachtet.
Die Herausforderung für AMD dürfte hier eher werden, dass eben die Leute, die so nen Prozessor kaufen mehr als nur eine Aufgabe damit machen. Um so höher die Last, desto bescheidener funktioniert das mit der Zuordnung von "außen". Egal ob das nun via Tool oder via Taskmanager gepinnt wird.

Ihr könntet ja mal testen, was es bringt, die Spiele an einen DIE per SetProcessAffinityMask zu binden. Vielleicht kann man sich damit den GameMode/Neustart sparen.

Ich gehe davon aus, dass es exakt so läuft wie mit bisherigen Multi-NUMA Node Systemen. Pin die Threads und das läuft wie es soll... Aber dann zieht halt auch bisschen das Argument, was mir her permanent an die Birne geworfen wird -> das Teil ist primär nicht zum Spielen gebaut. Denn legst du mehr als nur die Spielelast an - belastest also noch den Rest in Teilen oder sogar voll - wirst du Probleme haben die Leistung auch umzusetzen. Mit Prioritäten kann man das Spiel in den Fokus holen, damit die FPS wenigstens stabil bleiben. Aber dann schwankt ggf. halt die Leistung der Backgroundtasks bis dahin, dass es einfach nicht schneller ist als bei nur halber Nutzung -> im Worst Case also bis zu 900$ für den Wind...

VMs fehlen auch noch, zumindest wenn man sehr viele davon einsetzt.

Mit 128GB real zu bestückenden RAM? Mag für den ein oder anderen hier viel sein - aber im Hypervisorumfeld ist das nix... Da gehts ab 384-512GB eher so los. Bis rauf in den TB Bereich - je nach Anforderungen. Manche Hoster oder Kunden brauchen mehr CPU-, andere mehr Storage- und wieder andere mehr RAM Menge/Power. Und gerade die halbseitige Anbindung des RAMs sowie die vielen NUMA Nodes schränken das VM Geschäft schon arg ein...

Ich dir auch.
Wer für den WX nichts sinnvolles auf der Platte hat, der will auch keinen 7980XE.

Warum bringt hier alle Nase lang irgendwas mit Intel? Intel hat doch hier nichts verloren - es war auch nie Punkt der Kritik hier AMD oder Intel als Hersteller zu kritisieren, sondern die Kritik zielt auf die Umsetzung des WX. Keine Ahnung was dieses - "ja aber die anderen machen es auch nicht besser" immer soll...
Da scheint man hier bei vielen einfach nur nen Wunden Punkt zu treffen so wie das hier immer angeht. Es könnte so nüchtern entspannt sein. Was habt ihr bitte davon? Ich versteh es einfach nicht... 99% der Leute hier kaufen das Teil sowieso nicht. Warum nur muss das immer diese Richtung annehmen? Entweder man ist für oder gegen den Hersteller - was anderes kennt ihr nicht... Traurig, echt traurig sowas...

WX ist für Leute, die perfekterweise Epyc-Platform gebrauchen könnten, sich das aber nicht leisten möchten. Alle anderen werden problemlos mit den X auskommen.
Wer AMD einfach nur nicht mag, wird sich dann dafür was von Intel holen. Bald mit einem viel besserem P/L. Dank AMD.

Verweigere dich nicht fortlaufend der Realität.

Wer behauptet was von AMD nicht mögen? Muss man einen Hersteller mögen? Dieser subjektive Unsinn ist doch hier völlig fehl am Platz.

Ach und Thema Realität, den gebe ich gern zurück. Die Realität ist nicht, dass der Hersteller vorschreibt, wie man den Prozessor einzusetzen hat. Im Gegensatz zu dir oder dem ein oder anderen hier lass ich mir das nicht gefallen. Aber bei euch gehts scheinbar nicht ohne Markenverbundenheit. Keine Ahnung - ist mir zu hoch das zu verstehen. Bin ich vllt auch zu alt für... Warum muss es immer auf AMD gut oder scheiße rauslaufen? Oder Intel gut oder scheiße?
Auch AMD darf mal ein Produkt verhauen. Wie auch Intel oder NV oder wer auch immer... Das schlimme daran ist, dass immer die Fans dann dieses Zeug derart bis aufs Blut verteidigen müssen ohne einfach mal einzusehen, dass die Umsetzung nicht der Bringer ist oder war. Hier ganz konkret, es wäre besser gegangen. Es gibt sogar Tests dazu, und witzigerweise kann es JEDER! von euch selbst testen. Aber das macht ihr ja dann nicht - Augen zu und durch. Lieber nicht hinsehen und irgendwas behaupten. Solange die Front hält, halten wir zum Hersteller... DAS ist ne echt komische Realität in der ihr da verweilt. Ob AMD das auf lange Sicht hilft? Wir werden es sehen... Abseits der privaten Community sind die Leute deutlich nüchterner und weniger verblendet.
 
Diese Wall of Text immer, die jedes Wort des "Gegners" einzeln zitiert und zerpflückt ist ein Unart.
 
Irgendwo muss halt der Abstand von Epyc zu Threadripper gemacht werden. Ein Kanal pro Die hätte halt auch wieder Nachteile....

Ich hab bisher nur von Golem etwas dazu gefunden:

Die Alternative wäre gewesen, je nur einen Kanal und je nur 16 Bahnen pro Die zu verwenden, was aber ein anderes Routing im Package notwendig gemacht hätte und daher von AMD nie ernsthaft in Betracht gezogen wurde. Zwei der vier Dies steuern also schlicht ihre Recheneinheiten, aber keine I/O-Funktionen bei.
 
Diese Wall of Text immer, die jedes Wort des "Gegners" einzeln zitiert und zerpflückt ist ein Unart.

Nö, wenn du den Text lesen würdest, wäre dir aufgefallen, dass das Einzelzitate aus einzelnen Beitragen sind. Ich für meinen Teil sehe bspw. an Goderions Überlegungen ein Interesse sich dem Thema zu widmen und dieses entsprechend zu diskutieren. Wenn das nunmal in 3-4 Beiträgen kommt - wie anders als in 3-4 Zitaten drauf antworten? Den Postcounter zu liebe jedes Zitat einzeln rauslassen? -> gibt Durcheinander ohne Ende...
Wenn es dir nicht passt, gehste halt - ich werde ich nicht aufhalten.

PS: Einzeiler ohne Themenbezug sind übrigens eine Unart ganz anderer Natur :wink:

Irgendwo muss halt der Abstand von Epyc zu Threadripper gemacht werden. Ein Kanal pro Die hätte halt auch wieder Nachteile....

Jupp, das ist exakt das, was ich oben sagte - es wäre unwirtschaftlich für AMD, wenn auch technisch nicht unmöglich. Ob das so wirklichen nachteile hätte, lässt sich bspw. mit nem 1950X oder 2950X selbst austesten, wenn man je DIE mal einen Speicherriegel zieht. So viel ist das nicht. Im Schnitt sind das mal ein paar Prozent hier, mal ein paar Prozent dort. Aber du hast ne verlässliche Größe.
Ein netter Nebeneffekt davon wäre übrigens noch, dass der Spaß bei Vollbestückung wahrscheinlich effektiv höher taktbar wäre RAM seitig - also für die OC Freunde unter uns... Kompensiert also die geringere Bandbreite absolut dann sogar ein bisschen, je nach Takt halt grob in die Region 30-50%...
 
lol, ich pers finde diese "du bist mod, du darfst so nicht reden" sprüche ja immer eher lustig, aber "wenns dir nicht passt, gehste halt" ist mal ne ansage von einem, der den titel des moderators inne hat.
 
Das es ein Problem mit Windows gibt, wurde schon bestätigt, denn Benchmarks auf einem anderen Betriebssystem wie Linux sind deutlich besser und deklassieren förmlich die gesamte CPU-Liga! :eek:

Es werden aber auch zum Teil völlig andere Benches verwendet. Du findest diese "Deklassierung" auch unter Windows mit den richten Tools/Benches. Genau so wie du unter Linux Tools/Benches findest, die das absolut genau so mistig finden wie unter Windows. Leider ein weit verbreiteter Irrtum, dass das irgendwo direkt am OS hängt. Der Scheduler trägt seinen Teil dazu bei - aber ist nicht die Ursache. Die Ursache ist sind zwei Compute Nodes ohne RAM Access mit entsprechend lahmer und hoch latenter Speicheranbindung... :wink:

lol, ich pers finde diese "du bist mod, du darfst so nicht reden" sprüche ja immer eher lustig, aber "wenns dir nicht passt, gehste halt" ist mal ne ansage von einem, der den titel des moderators inne hat.

Was soll ich dir sonst drauf antworten? :confused: Du kritisierst die Textlänge von Beiträgen, die absolut nicht für dich bestimmt waren. Ist dein gutes Recht, aber mit nem Einzelner versteht die Menge es hier ja noch weniger... Wenn selbst die Erklärung nicht ohne Erklärung auskommt... Oder man Aussagen absichtlich missversteht nur weil man mich nicht leiden kann oder etwas gesagt wurde, was der eigenen Meinung nach nicht sein darf. Mir persönlich doch recht egal. ;)
 
Zuletzt bearbeitet:
Ich weiss warum webmi auf der Blacklist ist... Was ein geistiger Dünnpfiff...


@Fdsonne: Wäre dabei nicht praktisch die Sockelkompatibilität zunichte? Ich weiß gerade nicht ob man im gleichen Sockel die Speicher den 4 Dies hätte zuteilen können (Mal ganz abgesehen von neuer Maske, eigener Fertigungslinie usw)
Ich glaube der 2990wx ist ein Nischenprodukt sondergleichen (bin auf Intels x599 mit 28 Kernen gespannt 0o) und ansonsten sieht man das die ganze Plattform mit 2950x richtig rockt.
 
Was soll ich dir sonst drauf antworten? :confused:

Der Inhalt deiner Beiträge hat absolut Substanz und ist auch für mich durchaus ab und an mal ganz interessant, nur, wie gesagt, diese Wall of Text immer, wo jeder Satz zerlegt und widerlegt werden muss, fällt halt auf.

Das Ding ist - egal wie lächerlich dieses "du bist Mod" Gefasel finde - fällt dein Handeln irgendwie doch aufs Forum zurück, ob du das nun willst oder nicht, ob du das nun als ganz normaler Nutzer sagst, oder nicht.

Ich habe absolut null Probleme mit dir persönlich oder deiner Meinung, das nur mal als Anmerkung.
 
@Fdsonne: Wäre dabei nicht praktisch die Sockelkompatibilität zunichte? Ich weiß gerade nicht ob man im gleichen Sockel die Speicher den 4 Dies hätte zuteilen können (Mal ganz abgesehen von neuer Maske, eigener Fertigungslinie usw)
Ich glaube der 2990wx ist ein Nischenprodukt sondergleichen (bin auf Intels x599 mit 28 Kernen gespannt 0o) und ansonsten sieht man das die ganze Plattform mit 2950x richtig rockt.

Ich denke nicht - AMD könnte mMn (und auch der Ausführung da seitens Golem) einfach die Kanäle anders verdrahten. Aber das würde eben voraussetzen, dass man anstatt einem einzigen Modell in der Produktion (mit Teildeaktivierung zwischen den verschiedenen Endprodukten) eben mehrere echte Fertigungslinien aufziehen müsste. Der Träger, der vier DIEs des 4x1 Speicherkanal angebundenen Prozessors aufnimmt wäre intern ja völlig anders beschalten als der, der 2x2 Kanäle aufnimmt. Und gerade weil TR da eher die Niesche ist dürfte sowas auch extrem unwirtschaftlich sein... Das ist wie der Wunsch ggü. Intel einen 8086k als Sondermodell zu verlöten, weil ist doch ein Sondermodell. -> für den Hersteller ist das nur ein anderer Name mit vllt noch irgend einem anderen Binning. Thats it - da macht keiner nen Kopfstand.

Was den 28C Intel angeht, auch dort bin ich im Moment noch skeptisch. Mir gefällt im Moment der Corewahn nicht so recht. Weil es einfach übel über den Verbrauch geht. Für nen Wakü User OK - aber auch mit Wakü müssen die hunderte Watt Abwärme, die so ein Teil produziert, irgendwo hin. AMD ist jetzt bei 280W, der 28C Intel könnte (bei hohem Takt) da sogar noch ne Schippe drauf legen... Da hat man dann mal eben so die Energieaufnahme innerhalb von 2-3 Jahren verdreifacht :fresse: Zwar gibts auch deutlich mehr MT Performance, aber wo soll das enden?

- - - Updated - - -

Der Inhalt deiner Beiträge hat absolut Substanz und ist auch für mich durchaus ab und an mal ganz interessant, nur, wie gesagt, diese Wall of Text immer, wo jeder Satz zerlegt und widerlegt werden muss, fällt halt auf.

Das Ding ist - egal wie lächerlich dieses "du bist Mod" Gefasel finde - fällt dein Handeln irgendwie doch aufs Forum zurück, ob du das nun willst oder nicht, ob du das nun als ganz normaler Nutzer sagst, oder nicht.

Ich habe absolut null Probleme mit dir persönlich oder deiner Meinung, das nur mal als Anmerkung.

Ich nehme ich solcher Kritik auch gerne an, aber sag mir doch bitte, WIE soll ich das anders machen? Ein Einzeiler reicht nicht für die Erklärung. Sieh es da oben doch selbst. Da laberst du dir den Mund fusslig - und man WILL es nicht verstehen, scheinbar einfach nur, weil man meine Nase nicht mag.
Mal davon ab, jeder Satz zerlegt -> übertreib nicht. ICH persönlich finde es eher schlimm, wenn permanent Leute irgendwelchen Stuss behaupten, von dem sie technisch keinen Dunst haben. DAS macht die Foren kaputt. Und egal ob du da mit nem Einzeler oder mit viel Text antwortest - die Diskussion dreht sich dann nicht mehr um das Ding an sich, sondern nur noch um das Recht behalten - entweder du bist dafür oder du bist dagegen... Wahrscheinlich ist es einfach besser, gar nix zu schreiben... Geholfen ist den Leuten, die sich dafür aber interessieren dann doch aber auch nicht?? Ich habe mich damals hier angemeldet mit der Maßgabe, mit den Leuten hier Wissen oder Anregungen und Überlegungen auszutaschen - gern auch mal um Anderen zu helfen. Aber auch mir fällt auf, dass dies in 2018 scheinbar einfach nicht mehr gewünscht ist... Man müsst den ganzen Scheiß hier einfach nur hinwerfen..
 
Ich denke nicht - AMD könnte mMn (und auch der Ausführung da seitens Golem) einfach die Kanäle anders verdrahten. Aber das würde eben voraussetzen, dass man anstatt einem einzigen Modell in der Produktion (mit Teildeaktivierung zwischen den verschiedenen Endprodukten) eben mehrere echte Fertigungslinien aufziehen müsste. Der Träger, der vier DIEs des 4x1 Speicherkanal angebundenen Prozessors aufnimmt wäre intern ja völlig anders beschalten als der, der 2x2 Kanäle aufnimmt. Und gerade weil TR da eher die Niesche ist dürfte sowas auch extrem unwirtschaftlich sein... Das ist wie der Wunsch ggü. Intel einen 8086k als Sondermodell zu verlöten, weil ist doch ein Sondermodell. -> für den Hersteller ist das nur ein anderer Name mit vllt noch irgend einem anderen Binning. Thats it - da macht keiner nen Kopfstand.

Was den 28C Intel angeht, auch dort bin ich im Moment noch skeptisch. Mir gefällt im Moment der Corewahn nicht so recht. Weil es einfach übel über den Verbrauch geht. Für nen Wakü User OK - aber auch mit Wakü müssen die hunderte Watt Abwärme, die so ein Teil produziert, irgendwo hin. AMD ist jetzt bei 280W, der 28C Intel könnte (bei hohem Takt) da sogar noch ne Schippe drauf legen... Da hat man dann mal eben so die Energieaufnahme innerhalb von 2-3 Jahren verdreifacht :fresse: Zwar gibts auch deutlich mehr MT Performance, aber wo soll das enden?


Jo das mit der Abwärme ist so ein Thema, ich finde den neuen "Stock" Kühler von AMD beeindruckend, zumal der wirklich die CPU bändigen kann. Ist halt mit über 1Kg auch eine Wuchtbrumme aber was solls :)
Insgesamt ist anscheinend das Thema erreicht, das sich im Takt wenig tut (Sandy Bridge konnte schon 4,5-4,7ghz; jetzt Coffee macht 5-5,2) Man pro Takt auch nicht unendlich viele Operationen durchführen kann, also müssen es dann irgendwann Kerne retten.
Das wäre insofern kein Problem wenn sich Windows etwas anders Verhalten würde und die Programme mehr mit mehr Kernen können.

Ich verstehe aber auch jeden Programmierer, der mir sagt, dass er ungerne für 30 Kerne programmiert wenn die meisten 4-8 haben... Das ist dann halt auch nachvollziehbar.

Am Ende bleibt doch sowieso die Frage: Wie klein gehts noch mit Silizium, was geht mit Sw und Hw Integration noch und wann sind wir da am Ende und suchen/benutzen nach anderen Lösungen (zb Quanten)
 
Nur blöd, dass die Leute dann leider nicht nur 16 Rechenkerne zusätzlich haben, sondern meist auch ein Problem damit, dass eben 80% ihrer Anwendungen besser nicht auf den Rechenkernen laufen sollten.
Ich weiß jetzt ehrlich gesagt nicht was an "gebrauchen könnten" unverständlich war...

@fdsonne
Ich mein da bist du leider nicht ohne Schuld. Wenn du damals sehr ähnliche Texte zum 7980XE abgegeben hättest, würde man auch deine jetzige Meinung dazu bestimmt ernst nehmen. So fehlt halt bisschen die objektive Grundlage dazu.

Im Gegensatz zu dir oder dem ein oder anderen hier lass ich mir das nicht gefallen.
Nein, das soll natürlich keinem aufgezwungen werden. Wenn du findest, du möchtest mit einem JohnDeer 6155M auf die Nordschleife, oder alternativ mit einem 911er - natürlich mit front lift - Stück Feld beackern, dann sollst du das natürlich machen dürfen.
Ich bin mir nur nicht sicher wie sinnig das ist anschließend über die jeweilige Eignung zu lästern. Wie gesagt, WX ist nicht die einzige CPU-Serie die AMD anbietet.

Wer dabei eigentlich auch garnicht so das Problem mit der CPU, sondern mit dem OS und seinem Programmbestand hat, der hat eine verkehrte CPU gekauft. In dem Fall macht es Sinn sich eher selbstkritisch zu zeigen.

Wie gesagt aber, man soll sich auch eine Quadro zum Zocken kaufen dürfen. Kein Ding für mich.
 
Zuletzt bearbeitet:
Wenn dies so einfach wäre, so würde es AMD sicherlich auch tun.
Problem ist nur, AMD kann nicht einfach hergehen und den Sheduler von Windows umschreiben. Dazu haben sie einfach keine Rechte, denn der Urheber sind nicht sie sondern Microsoft. Also muss alles vorher mit Microsoft abgesprochen werden. Aber wenn diese nein sagen, kann AMD auch nichts dagegen machen. Was aber zu bezweifeln ist, da Microsoft ebenfalls ein Interesse daran hat die CPUs so schnell wie möglich auf ihrem Betriebssystem laufen zu haben, siehe Anpassung an Ryzen.
Die Vergangenheit hat gelehrt, das Microsoft die Skalierungsprobleme herzlich egal sind, solange nicht viele oder prominente Anwender davon betroffen sind. Ein Chromium-Entwickler hat einige davon in seinem Blog dokumentiert. Microsoft waren die Probleme teilweise schon längst bekannt, aber sie sind erst dann tätig geworden, nachdem die Chromium-Leute in mühevoller Kleinarbeit herausgefunden und nachgewiesen hatten, dass das Problem an Windows liegt.

24-core CPU and I cant move my mouse | Random ASCII
Zombie Processes are Eating your Memory | Random ASCII
Compiler bug? Linker bug? Windows Kernel bug. | Random ASCII

Es werden aber auch zum Teil völlig andere Benches verwendet. Du findest diese "Deklassierung" auch unter Windows mit den richten Tools/Benches.
7-zip, Blender, usw. wurden auch von den Windows-Review-Seiten verwendet, und die Ergebnisse dort passen durchaus zum Rest.

Das Problem, dass der 2990WX nicht skaliert, ist ganz klar eine Kombination aus schlechter Anwendungssoftware und schlechtem Betriebssystem. Wobei das Windows-Betriebssystem den 2990WX grundsätzlich ausbremst, und die Anwendungssoftware mal mehr und mal weniger.
 
Im Falle von Blender ist der Phoronix Bench unbrauchbar, weil eine veraltete Blenderversion genommen wurde. Mit aktuellen builds sind keine derartigen Leistungsunterschiede zwischen Windows- und Linuxbuilds vorhanden. Außerdem ist nicht nachvollziehbar, wieso nicht der gooseberry bench zum Einsatz kommt. Ist vom Workload einfach am realistischsten.
 
Das Windows das per Scheduler regelt, wäre sicher die beste Lösung, aber irgendwie hat AMD es versäumt, Microsoft dazu zu bringen, dass früh genug zu implementieren. Den aktuellen Ansatz von AMD, die CPU zu 75% zu deaktivieren, um bei bestimmten Anwendungen keine Performance zu verlieren, finde ich seltsam. Ich bin jetzt kein Experte und kann hier nur spekulieren. Es wäre vermutlich sinnvoller gewesen, wenn das AMD irgendwie anders gelöst hätte, z.B. ein eigenes Tool/Service/Dienst, wo man Programme auswählen kann, die nur innerhalb eines DIE/NODE laufen sollen. Vorausgesetzt das würde funktionieren, könnte man sich den GameMode/Neustart sparen.

Aktuell spiele ich zwar nichts, aber es würde mich schon leicht nerven, wenn ich jedes mal, wenn ich vom Arbeiten zum Zocken wechseln möchte (oder umgekehrt), den Computer neustarten muss. Und wenn ich dann zocken würde, könnte ich nicht mal parallel dazu etwas Kompilieren, Encoden oder Rendern, ist schon irgendwie schade.

Ich glaube auch nicht, dass das lange so bleiben wird. Microsoft und/oder AMD werden sicher die Situation verbessern, aber der Ersteindruck hat meiner Meinung nach unnötig dadurch gelitten.
Der OS Sheduler muss halt neutral bleiben, sonst ist nur Ring-Bus oder Topologie möglich. ;)
Microsoft hat deswegen das Problem ausgelagert, manche kennen das Programm schon: Process Lasso von Bitsum: Bitsum Real-time CPU Optimization and Automation Software for Windows
Damit kann man jedem Programm eine eigenes Profil zuweisen, so ähnlich wie Mulit-GPU Profile für Games. ;)

Ich habe damals nicht schlecht gestaunt wie die GPU Auslastung höher wurde ohne Takt Änderung. (Prio & Core pinning)
 
Schön dass in den Spieletests die Möglichkeit in Betracht gezogen wurde dass man Kerne auch begrenzen kann, wenn man sie denn hat :d Die Spiele Benchmarks jucken mich zwar wenig aber mit nem 1950x zocke ich auch jetzt schon ohne Probleme, das gejammer um die Latenzen kann ich kaum nachvollziehen. Ich zocke aber auch in 4k - die kack 1080ti limitiert hier mehr als die CPU wie so oft. Schön wie der 2990WX abgeht, wird gekauft.
 
Zuletzt bearbeitet:
Kann man nicht annehmen, dass die einfach von 0 bis 63 durchnummeriert sind? Also 0 bis 7 auf DIE0-CCX0, 8 bis 15 auf DIE0-CCX1, 16 bis 23 auf DIE1-CCX0, usw.?
Die Durchnummerierung der Kerne dürfte genau wie die der SATA Ports durch das BIOS erfolgen, ob die bei allen Boards dann auch immer gleich ist, wäre damit nicht garantiert.

Dieser scheint ja aber immer noch die Threads "ungünstig" zu verteilen, oder warum laufen manche Spiele im GameMode mit nur einem aktiven DIE soviel besser?
Weil dann nur Dies (oder gar nur ein Die) aktiv sind, die auch direkt RAM angebunden haben. Das Problem hier eine Lösung über den Scheduler zu erwarten ist aber: Was soll der denn mit den Kernen machen die eben keine eigenen RAM Anbindung haben? Wenn da denen nie einen Task zuweist, hat man doch wieder nur eine 16 Kern CPU, da auf den anderen ja nichts laufen wird und der Scheduler kann ja auch nicht wissen welcher Thread nun gleich was machen wird, also ob der viele RAM Zugriffen machen wird oder nur auf den Daten arbeitet die in die Caches auf dem CCX passen. In letzeren Fall ist so ein 2990WX sauschnell und kann eben Kerne gut auslasten, allerdings kommt sowas bei realen Anwendungen eben nur sehr selten vor.

Das Problem ist, dass eben nur 2 Dies ans RAM angebunden sind, hätte man alle 4 je einen RAM Kanal zugeteilt (mehr als 4 geht ja bei der Plattform nicht), dann wäre es einfacher, weil es dann für jeden NUMA Node die gleiche RAM Anbindung geben würde und so ist dies ja auch normalerwiese bei NUMA Architekturen.
SetProcessAffinityMask ist natürlich sinnvoller, erspart einem selber die Threads zu analysieren, der Scheduler macht das sicher eh besser.
Der Scheduler kann keine Thread analysieren, den Aufwand dafür wäre viel zu hoch. Der schaut welche Thread laufen wollen, welche gerade auf etwas (I/O, RAM Zugriff, ein Signal) warten müssen und welche schon so lange laufen, dass man wieder ein anderer dran ist, dann weist er einen der gerade freien Kerne dem nächsten Prozess zu der auf Ausführung wartet und an der Reihe (unter Berücksichtigung der Priorität, etc.) ist. Wenn man noch Analysen des Codes machen wollte der dann von einem Thread gleich noch abgearbeitet werden soll, dann wäre der Aufwand gewaltig und der Rechner saulahm. Mit SetProcessAffinityMask grenzt man dem Scheduler nur in der Hinsicht ein, dass er eben den Thread auf bestimmten Kernen ausführen lassen darf.

Es wäre Aufgabe der Spielehersteller die CPUs zu unterstützen und denn SetProcessAffinityMask entsprechend zu verwenden. Alternativ kann der Nutzer dies auch beim Starten machen, indem er Anwendungen über "cmd.exe /affinity 0xff irgendwas.exe" startet, dann werden im Beispiel nur die ersten 8 logischen Kerne genutzt, alternativ kann man SetAffinity auch im Task Manager ausführen.

Ich habe bei meiner Überlegung nur an den 2990WX gedacht. Beim 2970W müsste man natürlich anders vorgehen.
Eben und damit steigt der Aufwand, denn die SW müsste für jede CPU einzeln angepasst werden.
Ich dachte pro DIE gibt es zwei CCX. Wie ist das beim 2970W? Pro CCX nur drei Kerne, ein CCX mit vier und einer mit zwei? Oder ganz anders?
irgendwo stand, dass der 2970WX pro CCX 6 aktive Kerne hat, was auch zum bisherigen Vorgehen passt, wonach bei allen AMD CPUs immer alle CCX die gleiche Anzahl aktiver Kerne haben.

Wie darf ich mir das mit dem Speicher vorstellen. Ich habe gelesen, das beim 2990WX jeweils zwei DIEs (0 und 2) zwei Speicherkanäle und 32 PCIe-Lanes haben.
Ja, von 2 Dies werden nur die Kerne genutzt, von den anderen beiden auch die RAM und PCIe Lane Controller. Das ist ja das Problem, wären alle Kerne wenigstens mit einem RAM Kanal ans RAM angebunden, wären in der Hinsicht alle NUMA Nodes identisch, allerdings wäre die Spieleperformance dann wohl auch bei Nutzung nur einer Die viel schlechter, da dies dann eben auch nur noch die halbe Speicherbandbreite hat. Insgesamt wäre Speicherbandbreite aber nicht schlechter, auch wenn die üblichen Tools wie AIDA dies natürlich anderes anzeigen werden, denn die dürften kaum für NUMA angepasst sein und die Bandbreite über alle NUMS Nodes messen, sonder nur die eines Nodes.
DIE0 und DIE2 haben "direkten" Zugriff auf den gesamten Speicher.
Nein, wenn man alle RAM Kanäle bestückt hat, dann kann jedes der beiden Dies nur auf die Hälfte des gesamten Speichers zugreifen, auf die anderen Hälfte nur über das jeweils andere Die.
Wenn ich jetzt einen Prozess an DIE0 binde, können dessen Threads doch direkt auf den gesamten Speicher "ohne Umwege" zugreifen? Ob UMA oder NUMA ist in dem Fall doch egal?
Nein und nein, erstens wie eben gesagt nur auf die Hälfte und zweitens ist UMA oder NUMA nicht egal, denn davon hängt ab wie die CPUs aus Sicher der SW aussieht, nur bei NUMA weiß die Software (auch die Speicherverwaltung des OS) überhaupt welche Resourcen zu welchem NUMA Node gehören und wenigstens versuchen das RAM des NUMA Nodes zu belegen auf dem der Thread auch gerade läuft und sollte den dann entsprechend auch nur auf diesem einen Node laufen lassen. Zwar haben ich keinen Threadripper, aber im UMA Modus dürfte das ganze RAM nur ein einheitlicher Bereich sein und ähnlich wie bei einem RAID 0 dürften die Adressen über alle RAM Kanäle verteilt werden und nicht wie bei einem JBOD(BIG) erst ein RAM Bereich von einem Die kommen und dann der vom anderen, denn sonst wäre der RAM Durchsatz um UMA Modus nicht höher als im NUMA Modus, es es im Review aber ermittelt worden ist. Damit landen als alle Speicherinhalte im UMA Modus in den RAM die an beiden Dies hängen und erfolgen immer auch Zugriffe auf das RAM welches am anderen Die hängt, weshalb im UMA Modus die Latenz der RAM Zugriffe ja auch höher und die Bandbreite bei weitem nicht doppelt so hoch ist. UMA oder NUMA ist also nicht egal, selbst wenn nur die Kerne eines Dies genutzt werden.

Ich dachte die teils schlechte Performance in Spielen liegt daran, dass mehrere Threads auf unterschiedlichen Kernen den selben Speicherbereich nutzen.
Wenn, dann sollten sie nur lesend darauf zugreifen oder die Zugriffe entsprechend synchronisieren, was bei MCM CPUs und Multi-CPU Systemen auch viel länger dauert als bei monolithischen CPUs. Durch die CCX Architektur ist es selbst bei den einfachen RYZEN CPU schon langsamer wenn die Threads der SW viel miteinander kommunizieren, wozu eben auch die Maßnahmen der Threadsynchronisierung zählen und bei TR verschärft sich dies noch, bei denen mit 4 aktiven Dies umso mehr. Spiele brauchen aber viel Synchronisierung, es sind Simulationen bei denen der Ablauf durch die Aktionen alle Teilnehmer bestimmt wird und diese alle voneinander abhängen. Bei einer Rennsimulation muss es ja auch krachen, wenn zwei Autos den gleichen physikalischen Platz zur gleichen Zeit beanspruchen, bei einem Ballerspiel muss einer Umfallen, wenn er der Kugel im Weg war. Dies alles nur auf einem Die auszuführen, ist also von der Performance her aus viele Gründen von Vorteil.

Schach ist was anderes, da kann einer für sich 1000 Züge voraus simulieren ohne überhaupt auf ein externes Ereignis Rücksicht nehmen zu müssen, denn dies passiert in Form des Zuges des Gegners ja erst, wenn der eigene Zug getätigt wurde. Passen dann noch alle Daten in den Cache, dann ist der TR ein Biest für solche Anwendungen, aber eben nicht für solche mit viel Interaktion wie sie bei Games üblich ist.

Ein Render-Thread, der viel an die Grafikkarte schickt, müsste ohne direkten PCIe-Zugriff auch langsamer sein. Geht meine Vermutung in die richtige Richtung?
Sicher, der wird auch langsamer sein, aber ich denke nicht das Leute die sich einen 2990WX fürs Rendern kaufen, dann auf der Graka rendern werden. Rendern ist auch so eine Aufgaben bei der typischerweise jeder Thread für sich auf einem eigenen Teil der Daten rechnet und es daher wenig Interaktion zwischen den Threads gibt, weshalb die RYZEN CPUs da auch besonders stark sind. Durch die Senkung der internen Latenzen bei Zen+, die man ja auch an den geringeren Latenzen der Cachezugriffe sieht, hat sich bei den Spielen ja auch einiges verbessert und wenn man dann noch das RAM übertaktet und damit die IF, so bringt dies noch mal viel mehr als bei Intel CPUs, eben weil der Takt der IF da dran hängt und so die Latenzen weiter fallen.

Bei vier aktiven Dies wie beim Ryzen Threadripper 2990WX sollen es 51,2 GB/s (ebenfalls ) pro Link sein. Ausgegangen wird dabei von einem Speichertakt von 1.600 MHz, bzw. DDR4-3200.
Da offiziell kein DDR4-3200 freigegeben ist, finde ich solche Angaben übrigens wenig seriös. Entweder man gibt den RAM Takt dann auch frei oder macht die Angaben zu einem freigegeben RAM Takt.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh