Ryzen 7000 mit mehr Cache: AMD stellt gleich drei X3D-Modelle vor

Tech Enthusiast schrieb:
Hast Du für die Aussage einen Link, wo ich das nachlesen könnte?
Das behaupten so viele in Foren (die finde ich dann über Google), aber das klingt einfach wild und undenkbar deppert, wenn AMD diesen Schritt nicht so löst, wie CPUs das seit den Lochkarten lösen.
Eigentlich jede komplexe Hardware hat so was, ... weil es einfach Sinn macht strikt zwischen Umsetzung und Anfrage zu trennen. Wenn ich als Anfrager von IRGENDWAS vorher erst verstehen muss, WIE die andere Seite das lösen könnte,... dann muss ich ja genauso viel über deren Produkt wissen, wie sie selber. Ansonsten kann das ja nur schief gehen?!

Man stelle sich vor, dass die Auto Software genau wissen müsste wie jeder einzelne Teil im Motor läuft, damit sich das Auto bewegt.
Und als IT / Software-Entwickler kann ich ganz klar sagen: Programmieren auf einer CPU ist um ein VIELFACHES einfacher, als für eine GPU. Also muss es da eine CU geben. Ohne wäre das gar nicht machbar. Sonst müsste ja auch jede Entwicklungsumgebung den Code entsprechend der Ziel CPU anders kompilieren, was definitiv nicht passiert. Es wird nur zwischen 32 und 64 bit unterschieden.
Und ich kann natürlich der CPU sagen, dass ich nen eigenen Kern für eine Aufgabe brauche, oder 20 Threads, oder auch 1000 Threads (nicht identisch zu den Thread Angaben bei CPUs) . Was die CPU aus meiner Anfrage dann macht, ist ihr Ding.

Die Idee, dass das OS zwischen mir als Softwarentwickler und AMD als Hardwarehersteller übersetzen soll, wo sie die Hardware nicht selber bauen und die Software natürlich gar nicht kennen können, ist so wild, dass ich es ehrlich gesagt nicht glauben kann. Das schreit einfach nur "unmöglich" an nahezu jedem Ende.
Alles in der IT läuft über APIs. Software wie Hardware. Schnittstellen an jedem Ende. Nummer 1 Regel dabei: Jede Schnittstelle ist eine Blackbox. Und das ist bei CPUs seit den Lochkarten auch so gewesen.
Nun soll AMD das einfach mal "weglassen"?
Zum Vergrößern anklicken....
Kommt ein bisschen drauf an, in der modernen Programmierung oder den Hochsprachen kümmert man sich eben nicht mehr so genau darum Ressourcen zu verteilen.
Das überlässt man schon relativ intelligenten Mechanismen für die Ressourcen Einteilung seitens OS.
Du sagst auch nicht deinem System wie er über das Netzwerk welches Datenpaket verschicken soll, das übernehmen die Systeme und deren Protokolle dazwischen.
Von Glasfaser Signal auf Kupfer von Kupfer auf Funk.

Ein anderes Beispiel ist Automatik beim Auto, für dich als Autofahrer ist es total Latte ob der Elektro, Hybrid, Diesel oder welche Antriebsart er auch immer hat. Gefühlt ist es je nach Antrieb etwas anders, aber die Funktion bleibt ja gleich. Der Unterbau sorgt wie die Homogenität des Systems. z. B Besonders deutlich beim Plugin-Hybriden. (Benzinmotor+Eletromotor) Das System schaltet selbst intelligent zwischen den System hin und her je nach dem was man brauch.
So ähnlich sollte das auch die CPU machen am ende. Wenn du viel Gas geben musst für Geschwindigkeit (umschalten auf mehr Takt), wenn du Kontinuität brauchst und Effizienz E-Core (Intels Hybrid Model).
Hier müsst es eher so sein: Brauch ich ein größeren Kofferraum => 3D-Cach, brauch ich mehr Top Speed => "High-Clock CCD"... Nur es ist schwierig das in ns. Bruchteilen zu ermitteln und die Entscheidung zu treffen

Bezüglich nicht sichtbarem was aber unabhängig vom Programm oder Betriebssystem im Hintergrund läuft: https://de.wikipedia.org/wiki/Sprungvorhersage

Hier zum Betriebssystem

Scheduling

Unter Scheduling versteht man die Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse.
dev-supp.de dev-supp.de
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
n3cron schrieb:
Kommt ein bisschen drauf an, in der modernen Programmierung oder den Hochsprachen kümmert man sich eben nicht mehr so genau darum Ressourcen zu verteilen.
Das überlässt man schon relativ intelligenten Mechanismen für die Ressourcen Einteilung seitens OS.
Du sagst auch nicht deinem System wie er über das Netzwerk welches Datenpaket verschicken soll, das übernehmen die Systeme und deren Protokolle dazwischen.
Von Glasfaser Signal auf Kupfer von Kupfer auf Funk.

Ein anderes Beispiel ist Automatik beim Auto, für dich als Autofahrer ist es total Latte ob der Elektro, Hybrid, Diesel oder welche Antriebsart er auch immer hat. Gefühlt ist es je nach Antrieb etwas anders, aber die Funktion bleibt ja gleich. Der Unterbau sorgt wie die Homogenität des Systems. z. B Besonders deutlich beim Plugin-Hybriden. (Benzinmotor+Eletromotor) Das System schaltet selbst intelligent zwischen den System hin und her je nach dem was man brauch.
So ähnlich sollte das auch die CPU machen am ende. Wenn du viel Gas geben musst für Geschwindigkeit (umschalten auf mehr Takt), wenn du Kontinuität brauchst und Effizienz E-Core (Intels Hybrid Model).
Hier müsst es eher so sein: Brauch ich ein größeren Kofferraum => 3D-Cach, brauch ich mehr Top Speed => "High-Clock CCD"... Nur es ist schwierig das in ns. Bruchteilen zu ermitteln und die Entscheidung zu treffen

Bezüglich nicht sichtbarem was aber unabhängig vom Programm oder Betriebssystem im Hintergrund läuft: https://de.wikipedia.org/wiki/Sprungvorhersage

Hier zum Betriebssystem

Scheduling

Unter Scheduling versteht man die Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse.
dev-supp.de dev-supp.de
Zum Vergrößern anklicken....
Das eigentliche Problem ist: Das Automatikgetriebe wird nicht vom OS der Headunit gesteuert, sondern vom Steuergerät des Getriebes! Wenn die Headunit das machen müsste, würden Dir beim sportlichen Fahren die Zahnräder um die Ohren fliegen, da die Headunit maßlos mit den Schaltvorgängen überfordert wäre! Lastwechselreaktion, Getriebeöldruck in einer schnellen Kurve? All das ist der Software der Headunit völlig unbekannt 😉 Genau das ist ja das Problem von AMD - ich habe es im letzten Thread beschrieben. Bildlich gesehen und auf die CPU-Problematik bezogen: Intel macht das genau deswegen mit dem Hardware-Scheduler - dieser ist das Steuergerät. Und AMD macht es analog mit der Software der Headunit - das Schalten - denk an die fliegenden Zahnräder 😉
 
Hab jetzt noch mal ne Weile mit der AMD Microarchitektur beschäftigt.
Die haben mit Zen 4 sogar einen großen Fokus auf ihre "Execution Engine" gelegt. Das ist die Control Unit.
Marketing Speak, aber alle Komponenten und Aufgaben sind die, einer CU.
Inklusive Hardware Scheduler, sogar getrennt in Floating Point und Integer.

Auf deren Slides für Zen 4 ist sogar aufgeschlüsselt, dass Verbesserungen gerade in dieser Pipeline zu den IPC Steigerungen gehören, die Zen 4 über Zen 3 hat.

Es bleibt für mich also die Frage: Was genau macht das OS nun wirklich? Weil ganz offensichtlich macht Microsoft ja was und AMD bewirbt ja auch die Zusammenarbeit.
Nur WAS GENAU ist da nun vor der Blackbox von OS Seite? Weil die CPU (natürlich!) einen eigenen Controller dafür hat.
AMD selber spricht immer nur von "wir arbeiten mit Microsoft zusammen", sagen aber nie für was genau. Die Slides geben nur her, dass das Scheduling in der CPU selber passiert,... aber im OS heißt es auch Scheduler, also wäre mein aktueller Disconnect noch: Wofür braucht es beide, oder haben die einen unterschiedlichen Fokus?

Welchen Vorteil bietet es, wenn das OS was rät (mehr kann das OS ja nicht, gut raten nur) und die CPU dann theoretisch doch alleine regelt?
Wäre da weiter für nen Link dankbar, der das im Detail beleuchtet. Finde dazu leider nur viel Geratenes, wie von mir. Das hilft mir ja nicht weiter. ;-)

Mein bester Versuch es zu "raten" wäre: Vorverarbeitung.
Scheduling passiert in der CPU selber, weil sie die Hardware besser kennt. Aber das OS kennt die Software besser und kann so ggf. Parameter vorselektieren und die an die CPU weitergeben.
So kann dann die CPU ein paar NS sparen beim ausprobieren und direkt die OS Parameter nutzen, solange es kein Problem damit gibt.
Kontrollieren, ob die Parameter passen, muss die CPU aber sowieso, weil sie ja sonst gegrillt werden könnte. Von dem her ist der Vorteil eher unklar.
Beitrag automatisch zusammengeführt:

n3cron schrieb:
Hier zum Betriebssystem

Scheduling

Unter Scheduling versteht man die Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse.
dev-supp.de dev-supp.de
Zum Vergrößern anklicken....
Danke dafür.
Das zeigt leider nur Softwareseitiges Scheduling.
Logischerweise muss das auf OS Seite sein, weil die CPU davon ja nichts wissen kann.

Im Endeffekt geht es da darum, wenn 3 Prozesse gestartet werden, welcher wird zuerst in Auftrag gegeben bei der CPU.
Es geht aber nicht darum, wie die CPU damit umzugehen hat, nur in welcher Reihenfolge sie berechnen soll.

Das hat zumindest mit dem, was ich mit meinen Beiträgen meinte, nichts zu tun.
Nämlich die Unterscheidung, ob das OS die Cache CCD oder die Frequenz CCDs anspricht, bzw. überhaupt die Option hat da zu unterscheiden.
 
Zuletzt bearbeitet:
Bitte verstehe mich nicht falsch, aber irgendwie verstehst Du nicht, wie eine CPU, bzw. der Kernel des OS in Verbindung mit Software funktioniert. Einfache Frage: Wer stellt in dieser Konstellation die Anfrage, wer verwaltet die Anfrage und wer führt sie aus? Damit Du diese Konstellation besser verstehen kannst, musst Du Dich mit Maschinensprache beschäftigen, nicht mit Zen-Architektur. Leider wird einem heutzutage in der Entwicklung beigebracht, die Problemstellungen mit dem Nutzen von vorhandenen Bibliotheken, APIs und anderen Hilfsmitteln anzugehen. Was hardwarenah passiert, bleibt aber meist aussen vor. Deshalb ist sie Entwicklung (wie Du selbst richtig beschrieben hast) im GPGPU-Umfeld wesentlich anspruchsvoller, als im CPU-Umfeld. Wenn ich Dir damit Unrecht tue, entschuldige ich mich dafür! Aber die Aussagen deinerseits verleiten eben zu den genannten Aussagen.

Alleine die Tatsache, dass AMD eine Whitelist verwenden will, zeigt doch eindeutig, dass Deine Annahmen im Ergebnis falsch sind - denn dann wäre das alles gar nicht nötig und das OS bräuchte auch keinen Scheduler 😉 Anwendungsorientiertes Programmieren und die Nutzung von Übersetzern aller Art in Maschinensprache im alltäglichen Job helfen einem ungemein, aber bringen einen auch immer weiter weg von der eigentlichen Funktionsweise von PCs. Ich habe mit Softwareentwicklung begonnen, als es noch gar keine Bibliotheken oder Vegleichbares gab. Wir mussten tatsächlich erst einmal die Entwicklungsumgebung selbst programmieren, mit der man dann angefangen hat, die eigentliche Anwendung zu entwickeln 😉 Trotzdem geht die Diskussion immer mehr Off Topic - Sorry dafür!
Na jedenfalls bleibt es spannend, wie AMD die Problemstellung letztendlich gelöst bekommt 😀👍
 
Der Thread ist jetzt drei Wochen alt... versucht ihr immer noch ihm zu erklären was ein Scheduler ist? :hmm::fresse:
 
Tech Enthusiast schrieb:
Hab jetzt noch mal ne Weile mit der AMD Microarchitektur beschäftigt.
Die haben mit Zen 4 sogar einen großen Fokus auf ihre "Execution Engine" gelegt. Das ist die Control Unit.
Marketing Speak, aber alle Komponenten und Aufgaben sind die, einer CU.
Inklusive Hardware Scheduler, sogar getrennt in Floating Point und Integer.

Auf deren Slides für Zen 4 ist sogar aufgeschlüsselt, dass Verbesserungen gerade in dieser Pipeline zu den IPC Steigerungen gehören, die Zen 4 über Zen 3 hat.

Es bleibt für mich also die Frage: Was genau macht das OS nun wirklich? Weil ganz offensichtlich macht Microsoft ja was und AMD bewirbt ja auch die Zusammenarbeit.
Nur WAS GENAU ist da nun vor der Blackbox von OS Seite? Weil die CPU (natürlich!) einen eigenen Controller dafür hat.
AMD selber spricht immer nur von "wir arbeiten mit Microsoft zusammen", sagen aber nie für was genau. Die Slides geben nur her, dass das Scheduling in der CPU selber passiert,... aber im OS heißt es auch Scheduler, also wäre mein aktueller Disconnect noch: Wofür braucht es beide, oder haben die einen unterschiedlichen Fokus?

Welchen Vorteil bietet es, wenn das OS was rät (mehr kann das OS ja nicht, gut raten nur) und die CPU dann theoretisch doch alleine regelt?
Wäre da weiter für nen Link dankbar, der das im Detail beleuchtet. Finde dazu leider nur viel Geratenes, wie von mir. Das hilft mir ja nicht weiter. ;-)

Mein bester Versuch es zu "raten" wäre: Vorverarbeitung.
Scheduling passiert in der CPU selber, weil sie die Hardware besser kennt. Aber das OS kennt die Software besser und kann so ggf. Parameter vorselektieren und die an die CPU weitergeben.
So kann dann die CPU ein paar NS sparen beim ausprobieren und direkt die OS Parameter nutzen, solange es kein Problem damit gibt.
Kontrollieren, ob die Parameter passen, muss die CPU aber sowieso, weil sie ja sonst gegrillt werden könnte. Von dem her ist der Vorteil eher unklar.
Beitrag automatisch zusammengeführt:


Danke dafür.
Das zeigt leider nur Softwareseitiges Scheduling.
Logischerweise muss das auf OS Seite sein, weil die CPU davon ja nichts wissen kann.

Im Endeffekt geht es da darum, wenn 3 Prozesse gestartet werden, welcher wird zuerst in Auftrag gegeben bei der CPU.
Es geht aber nicht darum, wie die CPU damit umzugehen hat, nur in welcher Reihenfolge sie berechnen soll.

Das hat zumindest mit dem, was ich mit meinen Beiträgen meinte, nichts zu tun.
Nämlich die Unterscheidung, ob das OS die Cache CCD oder die Frequenz CCDs anspricht, bzw. überhaupt die Option hat da zu unterscheiden.
Zum Vergrößern anklicken....
Darum gehts doch, für gewöhnlich wissen CPU und OS nichts direkt voneinander. Das OS weis nicht welcher Kern z. B den schnellsten Takt hat. Was da AMD mit MS macht ist nicht anders als Reglen zu definieren wie der Scheduler der CPU klar machen kannn (wie anweisen) was die CPU umsetzen sollte, damit die CPU die richtigen Schlüsse ziehen kann. Man einigt sich auf ein Protokoll. Wenn der Hardware Hersteller nichts vorgibt, verwendet halt MS ein Standard Setting das nicht auf eine Hardware spezifiziert ist.
 
Deutet das auf nen Release im Februar hin? Sind das bestätigte Ergebnisse? Wohin geht die Reise? Wo sind offizielle Infos von AMD? Wo hängts und wieso?
 
bernisv schrieb:
Alleine die Tatsache, dass AMD eine Whitelist verwenden will, zeigt doch eindeutig, dass Deine Annahmen im Ergebnis falsch sind - denn dann wäre das alles gar nicht nötig und das OS bräuchte auch keinen Scheduler 😉
Zum Vergrößern anklicken....
Gegenfrage:
Wofür sind dann die Scheduler in der CPU und wieso schreibt AMD auf den eigenen Folien, dass ihre Engine die Aufgaben nun besser verteilt?
Das ist doch genau das, was hier unterstellt wird, dass nur das OS das kann. Wieso behauptet AMD das Gegenteil und zeigt die CU in solchen Details?

Dass ich das >Ganze nicht 100% verstehe sage ich ja selber und frage deswegen.
Bedeutet aber mitnichten, dass ich jede Info sofort als 100% richtig annehme, wenn sie sich mit den AMD Angaben und der Logik beißen. Zu einer Diskussion gehören kritische Nachfragen und Informationen zu hinterfragen.

L0rd_Helmchen schrieb:
Der Thread ist jetzt drei Wochen alt... versucht ihr immer noch ihm zu erklären was ein Scheduler ist? :hmm::fresse:
Zum Vergrößern anklicken....
Selektives Lesen führt immer wieder zu Lachern, meist auf Kosten derer, die meinen nen schlauen Kommentar zu bringen. Trotzdem danke dafür. ;-)

n3cron schrieb:
Darum gehts doch, für gewöhnlich wissen CPU und OS nichts direkt voneinander. Das OS weis nicht welcher Kern z. B den schnellsten Takt hat. Was da AMD mit MS macht ist nicht anders als Reglen zu definieren wie der Scheduler der CPU klar machen kannn (wie anweisen) was die CPU umsetzen sollte, damit die CPU die richtigen Schlüsse ziehen kann. Man einigt sich auf ein Protokoll. Wenn der Hardware Hersteller nichts vorgibt, verwendet halt MS ein Standard Setting das nicht auf eine Hardware spezifiziert ist.
Zum Vergrößern anklicken....
Also liege ich mit meiner Vermutung richtig, dass sowohl OS, als auch CPU die Aufgaben ohne gegenseitige Hilfe ausführen können, aber eine Zusammenarbeit führt zu besserer Vorarbeit und Parametern, die beiden Seiten helfen ihre Aufgaben effizienter zu machen.
Dass die Zusammenarbeit hilft und man auch API Calls effizienter machen kann, wenn man versteht, was dahinter grob passiert, ist ja klar und habe ich nie hinterfragt.
Ich behaupte ja nur, dass dies nicht nötig für die Funktion ist, sondern lediglich die letzten paar Prozent raus holen kann.

Die Verteilung auf die Kerne macht, laut AMD, die interne Hardware Lösung und eben nicht der Windows Scheduler. Windows macht einen unverbindlichen Vorschlag anhand von geratenen (oder whitelisted) Parametern, aber nicht in jedem Fall. Nur, wenn es relativ eindeutig ist (bzw. in der Whitelist steht).
 
Vereinfacht ausgedrückt: Die CPU verwaltet ihre Aufgaben „hardwareintern“ selbst. Das meint AMD mit den Aufgaben und Entwicklungen der CU, usw. Das hat aber gar nichts mit den Aufgaben zu tun, die sie vom OS bekommt! Das sind unterschiedliche Dinge. Die Anwendungssoftware stellt Anfragen an das OS, dass diese dann verteilt. Es kann somit über die Treiberebene und den Scheduler im Kernel die Aufgaben an die entsprechende Hardware weiterleiten (in unserem Fall die CPU). Diese Aufgaben verteilt das OS unter Berücksichtigung der verbauten Hardware (gehört ja nicht nur die CPU dazu, sondern z.B. der Arbeitsspeicher, etc.). Somit: Eine CPU kann ihre INTERNEN CPU-Aufgaben verwalten (Verteilung von internem Cache, Verteilung zwischen den CCDs, etc.). Aber sie hat keine Ahnung, was um sie herum passiert (z.B. was ist RAM, SATA-Schnittstelle? etc. - sie weiss schlichtweg gar nicht, was das überhaupt ist). Deshalb gibt es ja das OS, das alles zusammenfügt und ALLE Aufgaben, die softwareseitig, oder aber über die Treiberebene zwischen unterschiedlichen Hardwarekomponenten her rühren, verwaltet! Das macht dann der im Kernel sitzende Scheduler - er bestimmt, welche Aufgabe welcher Kern über welchen Thread bekommt. Nochmal: Für die CPU gibt es nichts ausserhalb der CPU, sondern nur innerhalb! Eine CPU ist ja nicht ein einziges Teil, sondern besteht aus vielen verschiedenen Einheiten (z.B Logikeinheit, 2Lv-Cache, etc). Und diese, internen Einheiten der CPU, verwaltet sie logischerweise auch selbst. Dafür braucht sie auch einen eigenen Scheduler, der aber nichts mit der Aufgabenverteilung von Aufgaben ausserhalb der eigentlichen CPU zu tun hat. Die CPU weiss weder was von Software, noch vom OS. Das OS hat im Kernel Anweisungen in Maschinensprache parat, dass der CPU sagt, was sie wann zu tun hat. Und diese führt sie dann aus! Mehr nicht! Eine CPU ist einfach relativ dumm - sie hat keine eigene Logik ausserhalb von sich selbst - sie verarbeitet nur 1 und 0! Das OS weiss aber (oder sollte wissen - darum geht es ja) über die Treiberebene viel von der CPU. Aber eben nicht alles - und genau da wird es kompliziert!
n3cron schrieb:
Darum gehts doch, für gewöhnlich wissen CPU und OS nichts direkt voneinander. Das OS weis nicht welcher Kern z. B den schnellsten Takt hat. Was da AMD mit MS macht ist nicht anders als Reglen zu definieren wie der Scheduler der CPU klar machen kannn (wie anweisen) was die CPU umsetzen sollte, damit die CPU die richtigen Schlüsse ziehen kann. Man einigt sich auf ein Protokoll. Wenn der Hardware Hersteller nichts vorgibt, verwendet halt MS ein Standard Setting das nicht auf eine Hardware spezifiziert ist.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Damit hast Du jetzt nur ausführlicher gesagt, was ich ja selber auch sage.
CPU macht ihre CPU Dinger, OS die OS Dinger.
Aber die CPU braucht das OS nicht, um zu funktionieren, oder intern zu verteilen. Die CPU bekommt einfach ne Aufgabe und entscheidet dann selber, wie sie die am besten umsetzt. Weil die CPU als einziges die dafür nötigen Daten hat.
Genauso wie das OS die einzige Instanz ist, die die nötigen Daten für die Softwareabläufe hat.

Warum also das OS kritisch sein soll, damit die CPU intern die richtigen Kerne anspricht, bleibt offen.
Alles, dass über eine geratene Empfehlung des OS hinaus geht, scheint undenkbar / sinnlos.

Im Endeffekt ist das natürlich für die Leistung egal (also das Verstehen im Detail).
Die Benchmarks zeigen dann schon, ob es funktioniert oder nicht. Dann ist auch egal, wieso es funktioniert.
Persönlich habe ich mich mittlerweile in einige AMD Paper zu dem Thema eingelesen und wenig "begeistert" davon. Es funktioniert wie vor 20 Jahren, hat alles nur tolle neue Marketingbegriffe heute. Die eigentlichen Funktionen, Aufgaben und Aufgabenverteilung sind identisch. Nur mit ein paar neuen Parametern, weil mehr Komponenten vorhanden sind. Die neuen Prozesse erlauben mehr solcher Logik auf kleinerem Raum zu haben, also können die CPUs etwas schlauer agieren als früher, in der Theorie zumindest, ... in der Praxis wird dieses Potenzial fast komplett von der gestiegenen Komplexität aufgefressen.
 
Der Release-Termin rückt (hoffentlich) näher :)
 
Hoffentlich bleibt es bei dem kommunizierten Release-Termin (14.02)....bin schon ganz aufgeregt und freue mich auf die ersten Tests...☺️
 
Ben@cha@min schrieb:
Hoffentlich bleibt es bei dem kommunizierten Release-Termin (14.02)....bin schon ganz aufgeregt und freue mich auf die ersten Tests...☺️
Zum Vergrößern anklicken....
Sie haben doch gesagt, dass es nicht der korrekte Termin ist...?
 
Termin & Preise offiziell


28.02. für 7900x3d (599$) & 7950x3d (699$)
6.04. 7800x3d (449$)
 
Die Preisvorstellung ist ja mal gar nicht so falsch. Hatte mit mehr gerechnet.
 
Wenn man mit dem aktuellen EURO-DOLLAR-Kurs umrechnet, kommt der 7800X3D auf ziemlich genau 490€ (inkl. den 19% MWSt.)
 
n3cron schrieb:
Die Preisvorstellung ist ja mal gar nicht so falsch. Hatte mit mehr gerechnet.
Zum Vergrößern anklicken....

Ja Preise scheinen sehr moderat zu werden, könnte aber auch ein Hinweis darauf, dass man leistungsmäßig nicht ganz so weit nach vorne rückt ....
 
@Don Der Preis beim 7800X3D in der News stimmt nicht. Es sind 449$ und nicht 499$.
 
  • Danke
Reaktionen: Don
Boah, noch 28 Tage warten, ich dreh durch :P
 
Was heißt hier "nur" 28 Tage warten. Ich will einen 7800X3D -> noch etwas über 2 Monate warten :cry:
 
Mhm irgendwie seltsam, dass die wahrscheinlich interessanteste CPU so viel später kommt.
 
Erst kommt das Zeug, was die höchste Marge hergibt...
 
Ist wie bei den Grafikkarten, erst die teuren Modelle für die ungeduldigen die am meisten Geld bringen, dann der Rest.
 
Ich tippe mal, dass im reinen Gaming der 7950X3D und 7800X3D gleich schnell sein werden und der 7900X3D knapp dahinter, wenn mehr als 6 Kerne vom Spiel genutzt werden können (vorausgesetzt, der 7900er besteht aus zwei 6er Chiplets, eines mit und eines ohne 3D-Cache). Braucht man die Extrakerne ohne 3D-Cache nicht, weil man keine entsprechende Workloads hat, sind die 79er Modelle für den Gamer + normale Anwendernutzung uninteressant. Also einfach das kleine "günstige" Modell kaufen. Wenn das Modell aber erst ein paar Wochen später kommt und man es einfach nicht abwarten kann, ist die Versuchung da, obwohl eigentlich nicht benötigt, die teureren 79er Modelle zu kaufen. Es geht doch nur noch darum das Maximum aus den Kundschaft rauszumelken.
 
Das Argument mit dem 6/8 Chiplet ist nicht von der Hand zu weisen. Allerdings spielt da der Takt auch noch mit.
 
Anmelden, um zu antworten.

Ähnliche Themen

HWL News Bot
Kleiner Zen 4 mit 3D V-Cache: AMD Ryzen 5 7600X3D im Test
2
Antworten
36
Aufrufe
5K
FM4E
FM4E
HWL News Bot
Mehr Leistung und niedrigere Temperaturen: Ryzen 9000X3D hat den 3D V-Cache unter dem CCD
2
Antworten
48
Aufrufe
3K
PeterPan62
PeterPan62
HWL News Bot
Ryzen 9000X3D: Gleiche Cache-Größen, aber Overclocking möglich
2
Antworten
55
Aufrufe
4K
Erisch
Erisch
HWL News Bot
Tiefstpreis: AMDs Ryzen 7000 X3D aktuell so günstig wie nie
2
Antworten
31
Aufrufe
2K
DTX xxx
D
HWL News Bot
Update für AM4: AMD stellt neue X3D- und GT-Modelle vor
2
Antworten
54
Aufrufe
4K
feidl74
F
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