AMD Genesis: Angeblich Threadripper 4000 in AIDA64 gesichtet

PCGH-Redaktion

Kommentar-System
Teammitglied
Jetzt ist Ihre Meinung gefragt zu AMD Genesis: Angeblich Threadripper 4000 in AIDA64 gesichtet

Threadripper 3000 ist noch nicht mal richtig für Herbst 2019 angekündigt, da geistert nun bereits Threadripper 4000 durchs Internet - angeblich auf Basis von Zen 3. Die Herleitung, dass es sich um die vierte HEDT-Generation von AMD handelt, ist zwar schlüssig, aber auch wild - zumindest so früh vor Veröffentlichung.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

lastpost-right.png
Zurück zum Artikel: AMD Genesis: Angeblich Threadripper 4000 in AIDA64 gesichtet
 
Solche Spekulationen und Gerüchte sind zwei Jahre vor Release doch totaler Schwachsinn.

Jetzt heißt es erstmal abwarten und Tee trinken.


Ende 2020 sind keine 2 Jahre mehr wenn man es genau nehmen will

1 Jahr und 2 Monate das 4 Quartal steht vor der Tür welches das Ende 2019 einläutet.

Daher durch aus denkbar das erste CPUs getestet werden von Zen 3
 
Irwie unglaublich wie früh sowas teils schon entdeckt wird.
Die Vergangenheit hat ja schon oft aufgezeigt das an solchen Sachen doch einiges wahr ist.

Mal sehen was wir in vllt 2 Jahren sagen :ugly:
 
SMT4 würde ja den Mutmaßungen von MooresLawIsDead (Youtuber) entsprechen. Hat duvar erst vor kurzem gepostet
YouTube

Hat der nicht auch mal Behauptungen über Zen3 zur Computex gemahct, die sich als falsch herausgestellt haben oder irre ich mich? Also wie "vetrauenswürdig" ist er? An sich ist es ein logischer Rückschluss, dass sich TR4 von AM4 etwas abheben kann...
 
Ja genau das habe ich mir auch gedacht. wie gut die OS damit wohl umgehen können:):schief:

Im Serverbereich mit Linux sollte das kein großes Problem sein. Gibt genug Anwendungsfälle.
AMD will im Serverbereich stärker Fuß fassen und dort kann es wirklich was bringen.
Lisa Su hat bestimmt bei IBM auch Kontakt mit der Technologie gehabt. IBM setzt es schon länger ein.
 
Hat der nicht auch mal Behauptungen über Zen3 zur Computex gemahct, die sich als falsch herausgestellt haben oder irre ich mich? Also wie "vetrauenswürdig" ist er? An sich ist es ein logischer Rückschluss, dass sich TR4 von AM4 etwas abheben kann...
Vertrauenswürdig würde ich auf 1 stellen, wobei 0 nicht glaubwürdig und 10 glaubwürdig ist :)
Nachdem Youtube sofort meinte mir nur noch Videos von ihm vorzuschlagen, habe ich ihn gleich geblockt
 
Hat der nicht auch mal Behauptungen über Zen3 zur Computex gemahct, die sich als falsch herausgestellt haben oder irre ich mich? Also wie "vetrauenswürdig" ist er? An sich ist es ein logischer Rückschluss, dass sich TR4 von AM4 etwas abheben kann...

Naja man sollte solche Analysten eh immer mit gesundem Menschenverstand betrachten. Ich schaue mir sloche Geschichten auf Youtube gerne an, habe auch die Videos von AdoredTV gerne angesehen, aber mehr als irgendwelche Gerüchte aufsaugen und dann in die weite Welt posaunen tun diese Typen nicht. Und so Typen wie Jim von Adored können nichtmal sich selbst eingestehen wenn sie dann doch mal falsch liegen und heulen dann in nem 40min Video darüber herum :ugly:
Am Ende ist's eben nur was zum Zeit vertreiben, wirklich glauben würde ich den "neuen Medien" nicht blind.
 
Zuletzt bearbeitet:
SMT4... Langsam kommt man an big blue ran...
Aber im Ernst:
Ich halte SMT4 vor allem im Serverbereich für realistisch, allerdings glaub ich kaum, dass so ne Info jetzt schon durchgesteckt werden würde.
 
Zuletzt bearbeitet:
Hmm, ich weiß gar nicht, ob der Schritt so groß ist, solange das OS weiß, welche Threads jeweils zueinander gehören. Da ist eventuell die Chiplettopologie noch die größere Herausforderung.

Das Betriebssystem ordnet nur logischen Kernen zu. Wie viele physische dahinter stecken ist für den eigentlichen Programmablauf egal. Man muss Windows zwar bei jeder Designänderung von neuem Beibringen, wie optimales Load-Balancing aussieht, wenn ein Viermoduler statt normalem Achtkerner, ein Zwei-CCX-er statt normalem Achtkerner, ein zwei-Die-er statt einem normalem 16-Kerner, ein Compute-plus-I/O-Die-er statt einem normalem 32-Kerner oder ein Chiplet-plus-I/O-Chip-er statt normalem 16-Kerner genutzt wird, aber laufen tut die Software auch ohne solche Anpassungen. Im Vergleich zu den bisherigen Abweichungen AMDs von gleichrangigen Strukturen wäre der Scheduler für SMT4 vermutlich sogar sehr einfach zu optimieren.

Aus Endnutzersicht spannender ist die Gegenrichtung: Lohnt sich SMT4 beim derzeitigen Kerndesign überhaupt? Die CPU kann damit zwar mehr Threads pro physischem Kern annehmen, muss diese aber auch verwalten und Anwendungen generieren Threads ohne Rücksicht auf inhomogene Ausführungseinheiten. Bereits heute beobachten wir bei vielkernigen CPUs, dass SMT eher bremst weil kaum zusätzliche Ressourcen für Berechnungen genutzt werden, aber der zusätzliche Verwaltungs- und Synchronisationsaufwand gestemmt werden muss. Das wird mit doppelt so vielen logischen Kernen nicht besser. Rückschlüsse von Power-8-Systemen mit doppelt so breiten Kern-Designs und auf sehr große Speichermengen, nicht aber unbedingt auf sehr niedrige Latenzen ausgelegtem Speichersystem sind hier mit Vorsicht zu genießen.
 
Das Betriebssystem ordnet nur logischen Kernen zu. Wie viele physische dahinter stecken ist für den eigentlichen Programmablauf egal. Man muss Windows zwar bei jeder Designänderung von neuem Beibringen, wie optimales Load-Balancing aussieht, wenn ein Viermoduler statt normalem Achtkerner, ein Zwei-CCX-er statt normalem Achtkerner, ein zwei-Die-er statt einem normalem 16-Kerner, ein Compute-plus-I/O-Die-er statt einem normalem 32-Kerner oder ein Chiplet-plus-I/O-Chip-er statt normalem 16-Kerner genutzt wird, aber laufen tut die Software auch ohne solche Anpassungen. Im Vergleich zu den bisherigen Abweichungen AMDs von gleichrangigen Strukturen wäre der Scheduler für SMT4 vermutlich sogar sehr einfach zu optimieren.

Ja, ich meinte darum ging es auch. Nicht, ob es überhaupt funktioniert, sondern ob eine gute Auslastung erreicht wird.

Aus Endnutzersicht spannender ist die Gegenrichtung: Lohnt sich SMT4 beim derzeitigen Kerndesign überhaupt? Die CPU kann damit zwar mehr Threads pro physischem Kern annehmen, muss diese aber auch verwalten und Anwendungen generieren Threads ohne Rücksicht auf inhomogene Ausführungseinheiten. Bereits heute beobachten wir bei vielkernigen CPUs, dass SMT eher bremst weil kaum zusätzliche Ressourcen für Berechnungen genutzt werden, aber der zusätzliche Verwaltungs- und Synchronisationsaufwand gestemmt werden muss. Das wird mit doppelt so vielen logischen Kernen nicht besser. Rückschlüsse von Power-8-Systemen mit doppelt so breiten Kern-Designs und auf sehr große Speichermengen, nicht aber unbedingt auf sehr niedrige Latenzen ausgelegtem Speichersystem sind hier mit Vorsicht zu genießen.

Ich weiß nicht, ob es da wirklich nennenswerten zeitlichen Aufwand gibt. Im Endeffekt ist SMT doch nichts anderes als das Vorhalten mehrerer Programmkontexte, damit diese nicht in und aus dem Speicher geladen werden müssen. Wo es vermutlich hapert ist dabei, dafür zu sorgen, dass alle Programme die nötigen Zeitabschnitte kriegen, in denen die Befehle einreihen können. Das ist auch kein triviales Problem. Macht man einen Thread zum "Hauptthread", der solange dran ist, bis irgendeine Latenz auftritt, leiden unter Umständen die anderen Threads, wenn die auch etwas schwerer sind, verteilt man gleichmäßig leidet ein eventueller schwerer Thread unnötig, wenn alle anderen sehr leicht sind.
 
Zurück