Es ist eine Frage der Anforderungen. Wenn jemand seinen Workload stündlich um 10 Sek. reduzieren kann, kann ihn eine einmalig höhere Investition über Zeit günstiger kommen.
AMD Ryzen 3800X: Geekbenchwerte gegen Core i9-9900K und Core i7-9800X
- Ersteller PCGH-Redaktion
- Erstellt am
Es ist eine Frage der Anforderungen. Wenn jemand seinen Workload stündlich um 10 Sek. reduzieren kann, kann ihn eine einmalig höhere Investition über Zeit günstiger kommen.
Ja, die Entscheidung IO und Chiplets zu trennen ist genial. Eine CPU mit defekter IO kann man nicht verkaufen, die mit defekten Kernen oder Cache schon. In 7nm konzenriert man sich auf 8 kernchiplets. Da kann man jeden Defekt weiterverarbeiten oder eben zusammenkleben. Wahrscheinlich gibt es mehr Ausschuss beim IO Chip als bei Ryzen selbst und der Chip wird billig hergestellt.
Bei Intel müssten sie den gesamten Chip bei IO Defekt wegschmeißen. Bei 4 defekten Kernen hätten sie immer noch die Gesamtkosten von einem 8 Kerner. Ryzen verklebt ihn mit einem 8 Kerner zu einem Premium X3900.
Intel hat schon ihre 10nm gelockert. Es bringt trotzdem wenig.
Ich dachte 3900x bekommt 2 x 6er? Also 8er Chiplets mit je 2 defekten/deaktivierten.
Wo wurde das festgelegt?
Das wird hier und da spekuliert bzw. von ausgegangen. 8+4 wirkt irgendwie unzutreffend. Ein 8er Chiplet würde dann auf 3950x>>3900x>>3800x>>3700x selektiert werden.
???? Ich weis nicht was du da zu rechnen glaubts, aber 1375/1250 sind einfach nur die MT-Ergebnisse durhc die Threadanzahl dividiert - nochmal dividieren liefert nur Zahlen die mit nichts korrelieren.
Und wie sieht es mit Chiplets aus mit defekter Verbindung zum IO-Chiplet? Oh... ja, genau.
Oh hey - hier ist ein kleiner Defekt im IF - muss auch alles weggeschmissen werden.
Komplexität hat KEINEN Einfluss auf die Ausbeute. Die Größe der Chips ist ausschlaggebend. Die Fehleranzahl kann im allgemeinen als konstant pro Waver angenommen werden.
Wenn man dann aus einem Waver nur 50 Chips schneiden kann hat man deutlich mehr verschnitt und die 20 Fehler werden wohl so um die 10-15 Chips beeinträchtigen bis ruinieren. Wenn man aber 200 Chips macht hat man weniger verschnitt und es sind dann halt 15-20 Chips betroffen - 20 aus 200 ist deutlich weniger als 10 aus 50.
Oder kurzum - Nein, du liegst einfach falsch.
Hm, wie rechnet man sonst 25% und 37,5% raus? Machst du bei der MwSt. die Multiplikation mit 0.81 oder die Division mit 1.19?
HT/SMT muss raus und danach dividierst du durch die Anzahl der Kerne und erhälst die netto Leistung jedes Kerns im Allcore, auf den wiederum 2 Threads laufen. Kannst die Werte am Ende noch halbieren wenn du auf 12/16 Threads rechnest, ändert aber nichts an der minimalen Leistung im maximalen Lastzustand.
Zuletzt bearbeitet:
G
gaussmath
Guest
Muss ich wieder mit dir schimpfen, Buggi?
Warte doch erstmal die Tests ab. Wenn Zen 2 tatsächlich jetzt rund 10% mehr IPC hat, der Takt sich aber nicht großartig unterscheidet (200-300MHz?!), dann wird AMD wohl vorne liegen. Das gilt bestimmt nicht ausnahmslos für alle Workloads. Um Licht ins Dunkel zu bringen, lasst uns doch erstmal die ersten guten Benchmarks abwarten. Und kommt bitte nicht später mit dem Kindergartenparcour von PCGH, wenn es um Anwendungen geht. PCGH ist die Referenz für Games!
Außerdem, wieso eigentlich mit "Kernen kaschieren". Ich kann diese mutwillige Negativargumentation nicht mehr hören. Wenn der Workload es erlaubt, sind mehr Kerne besser. Punkt. Du hast doch was mit Software zu tun, oder nicht? Kompiliere doch mal ein großes Projekt und mache gleichzeitig noch was anderes. Ich liebe es, wenn das System immer prompt reagiert. Das ist meinem Arbeitsflow zuträglich.
Ich werde das Glück haben, den 3900X und den 9900k direkt vergleichen zu können. Und ich werde das aus meiner Perspektive ausgiebig testen.
G
gaussmath
Guest
Muss ich wieder mit dir schimpfen, Buggi?
Warte doch erstmal die Tests ab. Wenn Zen 2 tatsächlich jetzt rund 10% mehr IPC hat, der Takt sich aber nicht großartig unterscheidet (200-300MHz?!), dann wird AMD wohl vorne liegen. Das gilt bestimmt nicht ausnahmslos für alle Workloads. Um Licht ins Dunkel zu bringen, lasst uns doch erstmal die ersten guten Benchmarks abwarten. Und kommt bitte nicht später mit dem Kindergartenparcour von PCGH, wenn es um Anwendungen geht. PCGH ist die Referenz für Games!
Außerdem, wieso eigentlich mit "Kernen kaschieren"?! Ich kann diese mutwillige Negativargumentation nicht mehr hören. Wenn der Workload es erlaubt, sind mehr Kerne besser. Punkt. Du hast doch was mit Software zu tun, oder nicht? Kompiliere doch mal ein großes Projekt und mache gleichzeitig noch was anderes. Ich liebe es, wenn das System immer prompt reagiert. Das ist meinem Arbeitsflow zuträglich.
Ich werde das Glück haben, den 3900X und den 9900k direkt vergleichen zu können. Und ich werde das aus meiner Perspektive ausgiebig testen.
Muss ich wieder mit dir schimpfen, Buggi?
Du hast gerade zweimal mit mir in Folge geschimpft. Pöses Gaussmath
Ja hast ja recht, dass Kernding für mich ist ganz einfach nur das der Allcore Boost ziemlich abgeschlagen ist vom Boost des Singlecore. Vielleicht klappt ja dieses mal MCE, dann passt es auch.
"Wenn der Workload es erlaubt"... Wir sind hier in einem Gaming Forum wo jede verdammte Codezeile mit einer höheren Threadleistung schneller ausgeführt wird. Du weißt doch selbst das man nicht jeden Codeschnippsel in einen eigenen Thread verpackt, ergo profitierst du immer und überall von der Leistung. Das man hier und da, dieses und jenes auf nem separaten Thread ausführt ist auch gängige Praxis, dennoch spricht das Verhältnis zu Gunsten der Threadleistung.
Große Projekte werden genau einmal vollkompiliert, danach auch nur noch die Änderungen. Gauss..., du solltest häufiger F5 drücken und debuggen
und nicht jedes mal "Projektmappe neu erstellen" klicken. Spaß bei Seite, ich brauche aktuell viel einzelne Threadleistung, da Echtzeitvideoverarbeitung und ich die GPU noch nicht ans Laufen gebracht habe, mistige managed Code Umgebung manchmal... 
I
IICARUS
Guest
Bei mir muss ich einige Prozesse im Task beenden damit für ein paar millisekunden vielleicht mal die 5 Ghz anliegen. Ansonsten habe ich immer zwischen 4,7 und 4,8GHz anliegen. 5 GHZ auf alle Kerne geht natürlich gut und mit meiner Wasserkühlung habe ich da auch so gute Ergebnisse das ich auch die 5 Ghz gut laufen lassen kann. Mit der Spannung scheint mein Exemplar auch gut ausgefallen zu sein, da ich für 5 GHz auf alle Kerne unter Last nur 1,225v anliegen haben muss.
Das mit dem neu aufsetzen des Systems war ein Vermutung von mir, getestet habe ich es aber noch nie.
G
gaussmath
Guest
@Buggi: Klar, wenn AMD wüsste, was die Gamer über die "Kernstrategie" denken, dann würden sie sagen: Oh ok, dann machen wir das doch nicht so, sorry!
Ja ja, man kompiliert nur die Änderungen. Deine Projekt sind natürlich immer perfekt konfiguriert. Der unmanaged Teil ist immer schön mit vorkompilierten Headern abgedeckt. Außerdem kompilierst du nur selten, weil du dir alles vorher perfekt überlegst*. Du kannst quasi alles immer so einchecken auf den TFS ohne vorherige lokale Tests...
* Und Änderungen im XAML Code kannst du immer ohne Laufzeit Check abschätzen, weil WPF immer das macht, was man erwartet...
Man kann wohl davon ausgehen, dass der 3900X einen Allcore Boost von ca. 4.4-4.5GHz bei leichter bis mittlerer Last haben wird. Beim 9900k sind's 4.7GHz. Das sind jetzt nicht die riesigen Unterschiede.
Ja ja, man kompiliert nur die Änderungen. Deine Projekt sind natürlich immer perfekt konfiguriert. Der unmanaged Teil ist immer schön mit vorkompilierten Headern abgedeckt. Außerdem kompilierst du nur selten, weil du dir alles vorher perfekt überlegst*. Du kannst quasi alles immer so einchecken auf den TFS ohne vorherige lokale Tests...
* Und Änderungen im XAML Code kannst du immer ohne Laufzeit Check abschätzen, weil WPF immer das macht, was man erwartet...
Man kann wohl davon ausgehen, dass der 3900X einen Allcore Boost von ca. 4.4-4.5GHz bei leichter bis mittlerer Last haben wird. Beim 9900k sind's 4.7GHz. Das sind jetzt nicht die riesigen Unterschiede.
Zuletzt bearbeitet von einem Moderator:
I
IICARUS
Guest
Werden sie diesmal auch nicht, zumindest nicht wenn der Intel übertaktet ist.
Was aber nicht bedeuten soll das der AMD schlechter sein wird, da es am ende auch nicht mehr darauf mit ankommt.
Zuletzt bearbeitet von einem Moderator:
Wieso? Wenn der Chip nicht hoch genug taktet, dann macht es total Sinn. Die Zusammensetzung hängt eh von der Nachfrage ab.
Deine Konstellation klingt zu optimal, also dass jedes CCX genau einen defekten Kern hat. 2+4+3+3 oder 2+4+2+4 oder 2+3 +4+3 sind genauso möglich.
Zuletzt bearbeitet:
Große Projekte werden genau einmal vollkompiliert, danach auch nur noch die Änderungen. Gauss..., du solltest häufiger F5 drücken und debuggen
Ach wär das schön wenns so einfach wäre. ich glaub allein diese Woche hab ich selbst schon an die 15h reiner Kompilierzeit, wenn nicht mehr. "wir brauchen hier ein neues Feld für Daten für diesen einen Spezialfall - ist leider eine Core-Komponente die all Interfaces betrifft, dauert dann halt 30 minuten" und wir waren gerade am zusammenführen mehrere Komponenten. Gut das ich meistens 2-3 Server habe und andere Sachen tun kann, sonst wird es sehr schnell sehr langweilig.
klar, sehr oft reich das kompilieren von kleinen Komponenten - da komm ich dann selten auf mehr als 8-10 threads - was in 10-30 Sekunden Fertig ist. Aber selbst da möchte ich nicht mit nur 4 threads arbeiten müssen, viel Spaß wenn man da gerade kleine Änderungen testen möchte.
Dann schmeißt man einen Chiplet weg an Stelle vom ganzen DIE, der Verlust hält sich dadurch in Grenzen. Bei Intel wäre der gesamte Chip hin. Man kann auf diese Art und Weise die Ausbeute doch steigern, indem man die Kerne/Infrastruktur auf mehrere kleinere Chips aufteilt.
@Buggi: Klar, wenn AMD wüsste, was die Gamer über die "Kernstrategie" denken, dann würden sie sagen: Oh ok, dann machen wir das doch nicht so, sorry!
Ja ja, man kompiliert nur die Änderungen. Deine Projekt sind natürlich immer perfekt konfiguriert. Der unmanaged Teil ist immer schön mit vorkompilierten Headern abgedeckt. Außerdem kompilierst du nur selten, weil du dir alles vorher perfekt überlegst. Du kannst quasi alles immer so einchecken auf den TFS ohne vorherige lokale Tests...
Man würde jedenfalls nicht nur eine Folie zeigen mit 1% höherer Singlethread und 2% höherer Multithread Leistung, was ja suggeriert das man einfach immer die bessere Leistung fährt. Dann kommen die Tester und messen vielleicht -5% in 8 von 10 Titeln, wo dann auch die große Frage aufkommt "warum", obwohl die Antwort genau dazwischen liegt. AMD lügt ja nicht, sie lassen nur die Singlethread Leistung im Multithreading aus.
Es ist halt die ausschlaggebende Leistung für Gamer.
Visual Studio übernimmt das bereits, lediglich bei Abhängigkeiten zu anderen Projekten oder Bindungen wird ggf. über Änderungen hinaus kompiliert. Wir reden nicht von VS 2005/2008. Lokale Projektkopie aus dem TFS ziehen, einmal kompilieren, programmieren, wieder kompilieren (VS berücksichtigt nur Änderungen), einchecken. Zwischendurch immer mal die lokale Kopie auf Änderungen im TFS rekursiv prüfen, fertig. Puhh, wenn ich da an SourceSafe zurück denke, bin ich schon heilfroh das es heute extrem flexibel ist mit TFS. Wenn du ständig massiv kompilieren musst scheint mir der Flaschenhals an ganz anderer Stelle zu liegen, da behandeln mehr Kerne zwar das Problem, beheben aber nicht die Ursache.
G
gaussmath
Guest
Ach, haben die Agents auf euren Buildservern mehr als zwei Kerne zugewiesen bekommen?
