AMD AMD Ryzen Threadripper 2990WX auf Lager, 2950X ab Mittwoch verfügbar

[Jakob Ginzburg]

Jakob Ginzburg Neuen News-Beitrag vorschlagen

Die ersten Shops listen AMDs „großen“ Threadripper 2990WX und geben damit die ab sofortige Verfügbar bekannt. Der kleinere, aber dadurch auch günstigere Threadripper 2950X, wird ab Mittwoch verfügbar sein. Sein Preis liegt geringfügig über 900 Euro.

Unser Premium-Partner Caseking listet die Ryzen Threadripper 2990WX CPU zu einem Preis von 1.829,00 Euro auf. Der Prozessor ist in erster Linie für den professionellen Einsatz gedacht und stellt eine günstige Alternative zu den Intel XEON-CPUs dar.

In unserem Testbericht waren wir von der Leistung überaus angetan. Für klassisches Gaming ist der Threadripper 2990WX aber überdimensioniert: AMD Ryzen Threadripper 2990WX und 2950X im Test – Echter Fortschritt mit bis zu 32 Kernen

Wem die beiden CPUs zu teuer oder zu potent sind, kann auch zu der ersten Threadripper-Generation greifen. Diese gibt es derzeit mit starken Preisnachlässen im Online- sowie Offline-Handel. Folgend die aktuelle Preisübersicht*:



AMD Ryzen Threadripper 2990WX

[affbox geizhals_id="1840353" caseking_url="amd-ryzen-threadripper-2990wx-3-0-ghz-pinnacle-ridge-sockel-tr4-boxed-hpam-145"]



AMD Ryzen Threadripper 2950X

[affbox geizhals_id="1867615" caseking_url="detail/index/sArticle/50037"]



AMD Ryzen Threadripper 1950X

[affbox geizhals_id="1664849" caseking_url="amd-ryzen-threadripper-1950x-3-4-ghz-summit-ridge-sockel-tr4-boxed-hpam-140"]



*Affiliate-Links. Durch betätigen der Links unterstützen Sie Tom‘s Hardware Deutschland.

Den Originalbeitrag lesen

 

[Tesetilaro]

ich wünschte wirklich ich hätte einen guten Grund so ein schätzchen zu rechtfertigen - allein es will mir kein Grund einfallen, den ich dann auch bei meiner Regierung durch bekomme

 

[Derfnam]

Hätteste mal ne Schneiderin geehelicht...

 

[Corro Dedd]

@Tesetilaro
Der Dackelblick funktioniert nicht mehr?
*Haben will*

 

[Besterino]

Ich fürchte, für meine Daddel-Zwecke reichen 6/12 bzw. 8/16 cores locker, wenn die denn mal ordentlich hoch takten. Wird dann wohl eher sowas in Richtung i9-9700/9900K... wobei mich die 64 Lanes schon extrem anlächeln...

Naja, so eilig ist's damit gerade nicht - da warte ich mal Testberichte ab.

 

[cpu-freak]

Ye, so ein Monster mit 32 Kernen findet jetzt nicht unbedingt Einsatz, aber wer weiß wie das in 2,3 Jahren aussieht, da tritt der wohl noch jedem noch so hoch getakteten Core i17 in den Hintern.
Nicht vergessen - gibt schon massenhaft Games die allesamt 16 Cores ansprechen - frei nach dem Motto ; 4x 5Ghz / 8x 4GHz oder 16x 3Ghz ?
Multicore (12+ Cores) schon seit 2011 n Thema - Software geht ja auch mit der Zeit und so wie es aussieht wird es dahin erstmal weitergehen.

Kann man sich meiner Meinung nach auf jeden Fall anschaffen die Platform (mit 16 Core) und wenn nötig in 5 Jahren ja immer noch n 32 Core auf Ebay kaufen Spiele-mäßig hat man dann für ne Dekade ausgesorgt und der Flaschenhals beim 32-Core ist wohl eher sowas wie eine Geforce 9080 RTX² ^^ ( die muss ersma erfunden werden ) - Einma kaufen, ewig Ruhe - einfach immer nur Grafikkarte durchwechseln.

 

[FfFCMAD]

Spiele werden nicht relevant sein bei der Multicore-Unterstuetzung. Auch wenn Spiele vereinzelt 16 Threads nutzen, wird die maximale Framerate IMMER an einem Core haengen. Es braeuchte eine andere Architektur, um dieses Problem zu loesen. Und man muesste Spiele asynchron programmieren, was halt schwierig ist. Denn Spiele sind nicht asynchron.

Mehr Kerne werden bei Spielen nur gewisse Dinge befeuern koennen: Mehr Verkehr auf den Strassen, mehr Gegner gleichzeitig berechnen (KI/ Wegfindung) Bei Shootern bringts halt nicht so viel.

 

[Corro Dedd]

Die Masse an Kernen bringt bei Spielen nur etwas, wenn man nebenher auch noch etwas anspruchsvolles anstellt, wie Streaming, was ein gleichzeitiges Komprimieren von einem Video bedeutet, hier brechen die FPS nicht so stark ein.
Auch, wenn man ein paar virtualisierte Systeme laufen hat, kann man hier mehr native Kerne verteilen.
Oder die Arbeitslast kann gut parallelisiert werden, wie Videoencoding.

Aber fürs reine Spielen tuts auch ein R7 2700X oder eine fast beliebige Intel CPU mit 4GHz+, IPC sei Dank. AMD holt in dem Bereich glücklicherweise auch auf, daher werde ich mir wohl nächstes Jahr den TR oder R7 3000 anschauen. Obwohl ich bisher nicht sagen kann, dass mein Prozessor der größte Flaschenhals im System ist ^^ Aber nach 6-7 Jahren WILL ich auch einfach mal etwas neues haben. Von den neuen Technologien und Features ganz zu schweigen, DDR4 oder vielleicht schon 5, M.2 oder Nachfolger, USB Type C und 3.2, etc.

 

[Besterino]

Naja, ich entscheide mich definitiv nicht heute für eine Plattform, weil sie irgendwas in 5 Jahren sein mag. Derartige Pläne sind mir schon zu oft nicht aufgegangen. Ich fahre mit der Philosophie eher beschränkter Upgradepfade seitdem ganz gut - für mehr als 2 Jahre plane ich nicht.

 

[cpu-freak]

Ich plan gerne für 10 Jahre - komme halt ausm Server Sektor - und ist auch oft interessant wenn man gleiche Benchmarks nochmal 2,4,6 Jahre später macht, mit aktueller Grafikkarte, man wird oft positiv überrascht - klar kommt irgendwo auch ein gewisses FPS Nivau von der CPU, aber solange sie "ausreicht" und gepaart wird mit einer aktuellen Grafikkarte sieht das aufeinmal ganz anders aus - da kann ein 8700k bereits am Flaschenhals hängen, weil er keine Geforce 3080 mehr füttern kann und der Threadripper wird endlich warm - und ein Test der heute gemacht wurde, wiederholt in 5 Jahren kann ganz andere Ergebnisse erzeugen, bedingt durch andere/neue Ansatzwege im Spiel/Programm, wo dann "alte" Hardware endlich vollständig genutzt werden kann.
Erinnert mich ein bisschen and die Geforce 3 vs Geforce 2, die brachte auch das erste Jahr kaum mehr, erst 1,2 Jahre später, mit neueren Treibern/Spielen kam die aufeinmal in fahrt und konnte ihre Vorteile ausspielen und nutzen. Immer das ewige ; Ist die Software oder Hardware stärker ? Ist die Software in der Lage mehr zu tun als die Hardware, muss erstmal die Hardware erfunden werden - jetzt haben die dicke Hardware, aber keine Software die es kann - pendelt seit ewigkeiten immer hin und her.

 

[FfFCMAD]

@cpu-freak: Wird nicht passieren. Wie ich bereits schrieb wird die Framerate immer an einem CPU-Kern haengen. Die IPC und der Takt sind somit entscheidend.

 

[gastello]

Die ID Tech 7 Engine wird alle Kerne einer 8 Core CPU auslasten inklusive SMT/HT und auf AMDs Zen IF optimiert sein. Ansonsten empfehle ich sich mit dem Tasksheduling und der CPU Utilization zu beschäftigen, was die Behauptung angeht die Framerate hinge an einem CPU Kern. Es ist genau anders herum, ein an einen Core getakterten Spiel wird unter massiven Framerateneinbrüchen und Stuttering leiden, weil die Zuweisung-/Ressourcenverteilung dynamisch erfolgt, da kann die IPC oder der Takt noch so hoch sein. Moderne CPUs wechseln mit dem Sheduler von einem Kern auf den anderen, um ihren hohen Takt halten zu können und die Rechenlast zu verteilen.

Wer dann ID Tech 7 spielen und im Hintergund anderes ausführen will, braucht mehr als 8 Cores, dort wird ein 6 Core bereits limitieren und nicht die höchste Framerate liefern. Heute werden 12 Task bereits gut ausgelastet. Wer hier glaubt das 5% mehr IPC pro Kern, zwei vollwertige Cores ersetzen können, weiß einfach nicht worüber er redet.

da kann ein 8700k bereits am Flaschenhals hängen, weil er keine Geforce 3080 mehr füttern kann.

???

Er ist das Bottleneck. Heutige Schedulerstrategie arbeiten beispielsweise auch work_conserving and non preemptive, weil das Verteilen, Umschalten und Abschließen eines Prozess meist nur wenig Zeit kostet, die Arbitratorlogik des Betriebssystem Multithread unterstützt und ausreichend Ressourcen vorhanden sind. Sie zu nutzen ist dann Aufgabe des Spieleentwicklers und Multithread ist klar im Trend. Hohe Turnaroundzeiten sind dabei aus dem Trend. Es gibt dabei unterschiedliche Medthoden des Prioritätscheduling. IPC und Takt ist dabei sicher nicht mehr alles, eher zählt Threadeffizienz.

 

[Derfnam]

Nur mal so: schedule.

 

[FfFCMAD]

Ein Kern kuemmert sich um die Auslastung der anderen kerne. Die Spieleengine haengt genau auf einem Core fest und gibt die Prozesse an andere Kerne weiter. Deswegen wird die Leistung immer an einem Kern haengen. Die anderen Kerne sind nur Sklaven des Hauptthreads. Das du mit mehr Kernen natuerlich mehr Leistung bekommst, ist logisch. Das funktioniert aber eben nur bis der Hauptthread des Spiels den einen CPU-Kern bis zum Anschlag ausreizt. Ab dem Moment ist das ganze gesaettigt und mehr kerne bringen keine hoeheren FPS.

 

[gastello]

Nur mal so: schedule.

Korrigiert.

Ein Kern kuemmert sich um die Auslastung der anderen kerne. Die Spieleengine haengt genau auf einem Core fest und gibt die Prozesse an andere Kerne weiter. .

???

Welches Beispiel fällt dir dazu ein, eins aus 1995? Es geht überhaupt nicht um Cores sondern um Task und die sind unabhängig von Cores zu sehen. Die Taskaffinität lässt sich auch nachträglich ändern.

 

[Derfnam]

Ach, gastello, vielleicht kommst du mal wieder runter und erklärst einfach mal den Unterschied zwischen dem mir bekannten Begriff des 'scheduling' und dem mir bisher nicht bekannten 'sheduling', anstatt mir zu unterstellen, dass ich ein Mobiltelefon besäße und darauf irgendwelche Kalenderplanungen vornähme.
Zumal die Suchmaschine meiner Wahl da sehr zurückhaltend ist.

 

[FfFCMAD]

Ich kenne aktuell kein Spiel, wo bis auf optische Physik oder Verkehr oder anderen Nebensaechlichkeiten irgendetwas im Spieleablauf asynchron und nicht voneinander abhaengig ist. Es gibt aktuell kein Spiel, wo das nicht so ist. Ob Singlecore oder Multicore: Ein CPU Kern bestimmt den Spieleablauf und bildet das Grundgeruest fuer alle anderen Threads. Ist so. Bleibt auch so.

Ein Spiel erfolgt nach Regeln. Und der Spieleablauf basiert auf einer Reihenfolge. Und diese Reihenfolge bestimmt der eine CPU Kern. Dieser ist der Hinkefuß. Das ist ein System, welches du nicht umgehen kannst.

Kurz: Du kannst ein Spiel mit mehr Zeug voll blasen. Aber das Regelwerk und die Engine an sich bleiben an einem Kern gebunden. Und je mehr Abhaengigkeiten zwischen den einzelnden Threads untereinander existieren, umso ineffizienter wird die Multicore-Unterstuetzung.

 

[Tesetilaro]

und jetzt kommen bitte alle wieder runter - kriegt Ihr das bitte hin ein Thema zu diskutieren, ohne Euch gleich in die Haare zu bekommen wie ne handvoll vorschulkinder?!?!

 

[FfFCMAD]

? Also ich bin total relaxt. Keinerlei boesartige Auswuechse hier. Eine Diskussion...

 

[gastello]

dass ich ein Mobiltelefon besäße und darauf irgendwelche Kalenderplanungen vornähme.

Ich besitze eins beim dem mir die Worterkennung einen Streich gespielt hat. Danke für den Hinweis. Ich dachte dich stört das eindeutschen englischer Begrifflichkeiten.

Kurz: Du kannst ein Spiel mit mehr Zeug voll blasen. Aber das Regelwerk und die Engine an sich bleiben an einem Kern gebunden. Und je mehr Abhaengigkeiten zwischen den einzelnden Threads untereinander existieren, umso ineffizienter wird die Multicore-Unterstuetzung.

Kurz das ist Quatsch und ich hätte gerne einen Link dafür der deine Theorie stützt.

Warum: eine Anwendung und damit Userthreads/-task (man kann sich steiten ob das der richtige Begriff dafür ist und man eher Process schreibt) unterscheidet nicht mal zwischen physischen und logischen Kernen, eine Multicore-CPU ist für die Anwendung keine Ansammlung von Cores. Singlethread geht mit dem Thema übrigens kein bißchen anders um. SMT und HT verfolgen diese Strategie, indem man einer Anwendung mit Verbreiterung der Verarbeitungspipeline weitere CPUs vorgaukelt, um die physikalischen Cores höher auszulasten. Dabei wird in prozessbasiertes Multitasking (unabhängiger Task) und threadbasiertes Multitasking (Unterteilung in mehrere Threads des gleichen Task) unterschieden, was klar die CPU-Reaktionszeiten verkürzt wenn komplexe Berechnungen ausgeführt werden und der Trend geht nun mal seit Jahren zum Multithreading über (Videospiele, Multimedia, Animation), weil das die Systemleistung stark verbessern kann und die Auslastung erhöht. Was und warum ist der größere Unterschied? Während sich reine Prozesse (Task) keine Speicherressourcen teilen können, können es Threads sehr wohl und diese brauchen dann auch noch weniger Zeit unkomplizierter untereinander zu kommunizieren.

Generell unterscheidet man dabei in User- und Kernelthreads, wobei Microsoft von einer manuellen Affinitätszuweisung bei Consumerplattformen abrät, weil die Arbitratorlogik die Task und Threads bereits in Categorien einteilt (High, Normal, Low Content) und mit Priority (Order) abarbeitet (Threadpool und Context Switch). Das heißt das paralelles Processing klare Vorteile gegenüber seriellem Processing mitbringt. Ein Usertask/-threads unterscheidet dabei nicht in Core 1, 2, 3, 4 sondern wird alle CPUs nutzen die er erkennt. 1995 war mit Absicht gewählt, weil es um Windows als Plattform geht. Ein Entwickler weißt der Anwendung/dem Spiel nicht Core 1 zu, wozu auch, denn die Anwendung erkennt viele CPUs anstatt denn einzelne Cores und soweit paralelles Processing möglich ist, werden Task in Threads unterteilt und über alle logischen und physikalischen Cores verteilt. Wie ich schon schrieb sind 12 Task ohne weiteres unter Spielen möglich.

Warum sollte daher Core 1 die Leistung eines Spiels bestimmen? Weil es den Gamingmode unter Windows 10 gibt? Der stellt nur bestimmtes Kernelprocessing zurück, wenn es an Ressourcen fehlt. Ansonsten werden die Anfragen über alle Cores verteilt und das kann mit Programmen wie HWInfo auch sehr schön abbilden. Dort ist Core 1 definitiv nicht die am höchsten ausgelastete CPU. Auch Turbo- oder Boostfrequenzen bei seriellem Tasking wird über alle physikalischen Cores verteilt.