News Geekbench-Ergebnisse: Intel Core Ultra 9 285K schlägt AMD Ryzen 9 9950X

[RavensRunner]

Und die CPU brenne wie die 13/14 auch nach 1 jahr ab wegen defekten microcode?
Jetzt aufn Papier den besseren lümmel haben aber dann wieder kundenverarsche mit Spannung oder Migration?

Dann lieber jetzt den 9950x der in 6 Monaten alle Bugs softwaremäßig beseitigt hat und mir nicht durchbrennt!

 

[Doenereater]

Ehrlich gesagt beeindruckt mich der Geekbench-Score nicht sonderlich, zumal Intel hier erfahrungsgemäß ein bisserl besser abschneidet als die Konkurrenz. Scheint ein eher seichtes CPU-Jahr zu werden. Schauen wir mal was die neuen X3Ds können und obs vielleicht doch noch eine Überrauschung beim Release von den Arrows gibt

 

[stefan92x]

Ich kenne jetzt die Designs von den Epics nicht

Da gibt es keine Hybrid-Designs, entweder ist alles Zen 4 (Genoa/Genoa-X) oder Zen 4c (Bergamo/Siena), und das wird sich voraussichtlich auch bei der nächsten Generation genau so verhalten.

 

[Laphonso]

Angesichts dessen, dass AMD mit dem 9950X die Messlatte jetzt nicht so wirklich hoch gelegt hat, finde ich das jetzt noch nicht überraschende oder beeindruckend.
Da muss Intel ja nicht mal eine Hürde nehmen, sondern nur den Fuß anheben.

Für Gamer ist nachher tatsächlich das Duell gegen die neuen x3D in belastbaren Spiele Benchmarks interessanter

 

[ElliotAlderson]

Ich habe gesagt das man beim i9 mehr P-Cores als 8 erwarten sollte, wie man das macht ist mir rechtherzlich egal, das ist das Problem der CPU Designer.

Warum interessiert dich die Architektur der CPU und welche Relevanz haben Designentscheidungen der Ingenieure für dich als Anwender?
Es ist völlig irrelevant, was da für CPUs drin stecken. Es zählen nur Preis, Leistung und Verbrauch.

Und ja man stelle sich vor es gibt Anwendungen die nicht bis ins unendliche mit Cores skalieren sondern nur wenige Threads nutzen wo es aber von Vorteil ist wenn diese schneller mit Ihrer Arbeit fertig sind.

Und welche Anwendung soll das sein, die genau von 16, aber nicht von 24 Kernen profitiert? Mal abgesehen davon, dass der 9950X 32 Threads hat und SMT somit brach liegt, was in weniger Leistung resultiert

Weil vielleicht auch mehrere Instanzen parallel laufen aber eben vielleicht nicht 32 oder 64 sondern eben nur 12 oder 16. In dem Fall bevorzuge ich mehr P-Cores, Ja.

Welche Anwendung ist das, die du so oft nutzt und nur 12-16 Threads benötigt?

Akzeptiert doch mal das es Auch Anwendungsfälle abseits Eures Horizont gibt.

Das kann jeder von uns akzeptieren, nur würde ich gerne dazu Beispiele sehen und kein plattes: "16 P-Cores over all!! big.LITTLE ist kein Highend!".
Und was ist, wenn die Intel CPU in diesen Beispielen trotzdem gleichwertig oder sogar schneller ist? Ich meine, du nimmst es einfach nur an, aber wissen tust du es nicht. Deine ganze Argumentation basiert auf irgendwelchen theoretischen Beispielen, die du nicht mal beweisen kannst.

Und wie hier auch schon mehrfach erwähnt wurde spielt auch die Leistungsaufnahme eine Rolle, die eben nicht angegeben wurde und Intel halt wie immer wahrscheinlich mit der Brechstange die Spitze geholt hat.

Das ist Glaskugellesen, aber wieder versuchst du dich an irgendwas hochzuziehen und deshalb denke ich, dass du eine Abneigung gegen Intel hast. Keiner von uns kennt den Verbrauch, aber trotzdem bringst du ihn als möglichen negative Punkt an. Darüber kann man diskutieren, wenn wir genaues wissen.

Du hast nicht 1x was positives über die CPUs geschrieben. Sämtliche Posts von dir sind kritischer Natur und nichts davon basiert auf irgendwelchen Fakten, sondern sind Annahmen/Theorie.
Sag doch beim nächsten mal einfach: "Ich hasse Intel und liebe AMD". Das macht es einfacher und man weiß genau, was Sache ist.

 

[Cr4y]

Tatsächlich interessant. Oder halt mehr Memory Controller.

N Quad-Channel-Controller wäre mit CAMM2 Kosten/Nutzen-Technisch vielleicht machbar(er). Bräuchte dann aber n neuen Sockel, nehme ich mal an. Wobei es für ARL-S angeblich Mobos mit CAMM2 geben soll, aber da natürlich auch nur so, dass es Dual Channel entspricht. Könnte AMD ggf. dazu bewegen für Zen 6 doch einen neuen Sockel aufzusetzen?

 

[cookie_dent]

Angesichts dessen, dass AMD mit dem 9950X die Messlatte jetzt nicht so wirklich hoch gelegt hat, finde ich das jetzt noch nicht überraschende oder beeindruckend.

So in der Art wollte ich es auch ausdrücken, die Schwäche von Ryzen 9xxx sollte eigentlich eine Steilvorlage für Intel sein.
Mal sehen, ob sie es umsetzen können.

 

[stefan92x]

Vom AMD 3D Cache profitieren - zumindest mir bekannt - bislang nur Spiele. Das allerdings sehr gut.

Im Prinzip profitiert jede Anwendung, aber alle leiden bei Ryzen X3D unter dem gesunkenen Takt. Unterm Strich bringt der 3D-Cache nur dann einen Mehrwert, wenn der Leistungszuwachs durch den Cache den Leistungsverlust durch den Takt übertrifft.

Wie das für verschiedene (Compute-)Anwendungen bei gleichem Takt läuft, kann man hier mal im Benchmark sehen: https://www.phoronix.com/review/epyc-9684x-3d-vcache

Da erkennt man auch sehr gut, warum AMD das Konzept für allem für Server entwickelt hat, da gibts kein Szenario, dass einen Leistungsverlust zeigt.

 

[Krik]

Zudem es auch nach wie vor so ist, dass Rechenwerke besser auszulasten nur dann ein Vorteil ist, wen die Rechenzeit pro Thread irrelevant ist. Spätestens wenn Threadlaufzeiten ins Spiel kommen, will der Anwender maximale Performance in diesem einem Thread und nicht die Summe von zweien, dafür mit Abstrichen bei beiden.

Ich kenne keinen Fall wo ein OS das gut hinbekommt. Im Falle von Windows bspw. greift SMT pauschal erst bei >50% Load. Vorher wird einfach auf die anderen Cores verteilt. Seit den Hybrid CPUs von Intel ist das aber ein dreier Gespann, da nicht von außen klar ist, ob ein Thread auf einem langsam taktenden und IPC Nachteilbehaftetem E-Core schneller läuft als auf einem zweiten Thread des P-Cores, der auf dem anderen Thread ebenso schon was zu tun hat. Das ist von außen einfach OS Threadschedulerseitig nicht erkennbar.

Für mich klingt das alles nach einer mangelhaften Implementierung.

Die Programmierer können Threads Prioritäten zuweisen. So weiß der Scheduler, welchen Thread er auf welchen (SMT)Core verteilen muss. Problematisch wird das erst, wenn zu viele anspruchsvolle Threads auf zu wenig Cores treffen. Aber dann wird es ohnehin lahm.

Ein Hintergrunddienst kann dann also so eingestellt werden, dass er nur auf den E-Cores bzw. nur auf den energiesparenden Cores läuft. Anwendungen, die wenige aber anspruchsvolle Threads haben, können bzw. sollte man so taggen, dass sie auf den P-Cores bzw. Nicht-SMT-Cores und vielleicht sogar auf den Cores mit Boost laufen.

Ich sage nicht, dass man das einfach umsetzen kann, aber unmöglich ist es nicht. Der Prozessor kann nicht entscheiden, welchen Thread es wie behandeln soll, aber der Programmierer kann es.

Oder ein anderes Beispiel: Smartphone CPUs
Die enthalten zwei bis drei verschiedene Core-Arten, um verschiedene Szenarien abzudecken. Was dort klappt, klappt auch in einem PC.

 

[Ltcrusher]

Also grad so AMD nVidia Intel Themen sind ja inzwischen echt abartig hier.

Das war früher auch schon so.

Auch in der Schärfe, aber die benutzten Worte bzw. der Satzbau waren anders. Trotz der Schärfe wirkte es freundlicher. Ein Forum wie unseres ist leider auch immer ein Abbild der Gesellschaft. Und die heutige verzeiht weniger und ist schneller aggressiv als noch vor ca. 10 Jahren.

 

[Shoryuken94]

ann lieber jetzt den 9950x der in 6 Monaten alle Bugs softwaremäßig beseitigt hat und mir nicht durchbrennt!

Stimmt, weil AMD CPUs ja auch nie kaputt gehen....

https://www.techpowerup.com/325250/...lure-rate-than-intel-13th-and-14th-generation


Oder die ganzen CPUs die samt Board in der Ryzen 7000 Generation gestorben sind, wegen zu hohen SoC Spannungen und AMD keine entsprechenden failsafes im Voraus mit den Partnern implementiert haben.

Das soll Intels Probleme nicht schmälern, aber AMD baut auch nicht die perfekten CPUs. Und ob AMD die Probleme irgendwann bei Ryzen 9000 fixen kann, ist nicht sicher. Ich warte auch noch auf den Vega Wundertreiber oder den Fix für den alten Dual Monitor Idle Powerbug.

 

[Atma]

Angesichts dessen, dass AMD mit dem 9950X die Messlatte jetzt nicht so wirklich hoch gelegt hat, finde ich das jetzt noch nicht überraschende oder beeindruckend.
Da muss Intel ja nicht mal eine Hürde nehmen, sondern nur den Fuß anheben.

Die Leistungssteigerung bei Arrow Lake ist schon beachtlich. Nicht vergessen, es gibt nur noch 24C/24T statt 24C/32T.

 

[Hovac]

Warum nochmal lässt Intel jetzt Hyperthreading weg?

Die Einführung dessen wurde damals damit begründet, dass es die CPU besser auslastet und man so "kostenlos" mehr Performance raus kitzelt. Es ist mir daher unklar, warum man jetzt kein HT mehr haben will.

Ich habe es so in Erinnerung, für 5% mehr Chipfläche gibt es 25% mehr Leistung. Richtig gestimmt hat es nie, da ein vergleich der Prozessoren mit und ohne nur schwer möglich war da der 2600k zum 2500k und alle folgenden immer etwas mehr cache hatten.
Ich nutze SMT/HT seit den letzten drei CPUs nicht mehr, weil für mich der negative Effekt der höhern Leistungsdichte seit dem schon besteht. Das ist nun auch bei maximal gekühlten Systemen angekommen, daher dürfte das 5 zu 25 Verhältnis zwar durchsus noch da sein, von der Leistungsaufnahme und Wärmeentwicklung hat es sich aber negativ entwickelt. 25% Mehrleistung für 35% mehr Energier oder ein Laufen in die Temperaturgrenze lohnt halt nicht mehr, da bringt es wohl mehr die Energie an die E-Kerne zu geben.

 

[fdsonne]

Ich finde es allgemein interessant, wie hier auf CB Cinebench als reiner Rendering Test als Maß der Dinge gilt und Benchmarks die ein breites Feld an häufig real genutzen libraries Durchjagen (Geekbench) teils verteufelt werden.

Es wird u.A. durch die Reviews so vorgelebt. Dort wird man primär einen MT Fokus finden was CPU Reviews angeht, dann noch ein bisschen Theorie Benches (PCMark und Co.) und ein paar wenige 1T Benches sowie eben Gaming.
Woher soll da auch mehr Praxis kommen? Im Endeffekt glauben die Leute das, was sie aus "seriöser" Quelle präsentiert bekommen. Da wird ja selbst Cinebench und Co. auf schmalen 15-25W Mobile CPUs als der Maßstab genommen, weil das in den Reviews halt so gebencht wurde.

Allerdings muss man fairerweise sagen, es ist drastisch schwerer reproduzierbare praktischere Szenarien zu definieren und die dann auch so durchzumessen, dass es über Monate bis Jahre hinweg konsistent vergleichbar bleibt.

Naja, es gibt halt auch Anwendungen die sich hervorragend parallelisieren lassen, und wenn alle Kerne gebraucht werden, und HT die Auslastung der Kerne verbessert, dann kann das schon helfen.

Jupp, aber ehrlicherweise, gemessen an der relevanten Praxis - wie oft kommt das jetzt genau vor?

Nimm die Zahlen von MF und schau dir an, was AMD da aktuell an CPUs verkauft. Da kommt der 6C und 8C auf in Summe den Großteil aller Verkäuft, gefolgt vom 12C und der 16C mit wenig Absatz overall. MT Volllast ist da also überhaupt kein Fokus.

Das liegt aber an der Anzahl der Kerne, nicht an den c-Cores. Phoenix/Hawk Point 2 hat Zen 4 und 4c in einen CCX gepackt, dürfte bei Kraken Point durchaus auch so sein.

Aber spielt doch keine Rolle? Sie machen es - also ist der Nachteil auch drin.
Es ging doch darum, dass der Ansatz besser wäre? Aber wenn man dann etwas nicht macht (praktisch in der Umsetzung), kann das in der Theorie noch so toll sein - in der Praxis bleibt der Nachteil doch weiterhin...

Ich kenne jetzt die Designs von den Epics nicht, aber sollten sich Zen und Zen-C Kerne auf einem Chiplet befinden, ist es kein Problem, es bei einem CCX zu belassen. Aber wahrscheinlich wird wohl eher ein Chiplet mit C-Kernen vollgestopft, statt zu mischen.

Bei den Epycs mit nur C Cores gibt es zwei CCX pro CCD und je 16MB L3 Cache pro 8x C-Cores. Also auch wieder die Aufteilung wenn ich das richtig sehe.

Die Frage ist an der Stelle nicht, ob das jetzt am C-Core liegt oder nicht, sondern ob im jeweilig genutzten Design bspw. genug Ports vorhanden sind um den Spaß auch zu verbinden. Der Cache nutzt ja erstmal nix, wenn du nicht schnell genug "ran" kommst. Das hat eher was mit der Organisation der Zugriffe zu tun. Da ja die Caches in "Lines" aufgebaut sind und es damit potentiell zu kollisionen kommt wenn da verschiedene Einheiten drauf zugreifen.

Bei Phoenix 2 sind es halt 2+4 Cores. Also 6C in Total an einem 16MB L3 Cache. Das ist selbst für jeden Thread bei maximal gleichzeitiger Nutzung ein Zugriff zumindest theoretisch möglich.
Bei Strix Point sind es 4+8, also 12C. AMD hatte bisher keinen? mir bekannten CCX, wo mehr wie 8C auf eine gemeinsame Cache Partition zugegriffen haben. Wahrscheinlich hat das auch ein Stück weit etwas mit der absoluten Zugriffsgeschwindigkeit zu tun. Denn auch die Signalwege werden länger. Früher bei Intel hieß es mal, den Ringbus mit >8C zu bauen und die Cores daran zu verbinden, wäre ungünstig. Kann jetzt Zufall sein dass AMD auch dort nen Cut macht? Oder das ist wirklich irgendwo so eine Art BEP andem das im Verhältnis kippt?

 

[inge70]

Und welche Anwendung soll das sein, die genau von 16, aber nicht von 24 Kernen profitiert? Mal abgesehen davon, dass der 9950X 32 Threads hat und SMT somit brach liegt, was in weniger Leistung resultiert

ähm der 9950X hat 16 Cores und durch SMT kann er auf 32 Threads zugreifen (zumindest verstehe ich das so).
Wo liegt denn da jetzt SMT brach?

 

[DJMadMax]

Der Single-Core-Test fördert für den Intel Core Ultra 9 285K auf einem Asus-Z89-Board 3.449 Punkte zutage.

Ich glaub, da fehlt ne 0 beim Chipsatz

Ich freue mich schon - wie immer - auf erste, unabhängige Tests. Dass die Leistung derzeit zu passen scheint, ist schön, aber grundsätzlich steht und fällt das Ganze doch auch wieder mit der Energieeffizienz.

 

[ElliotAlderson]

ähm der 9950X hat 16 Cores und durch SMT kann er auf 32 Threads zugreifen (zumindest verstehe ich das so).
Wo liegt denn da jetzt SMT brach?

In seinem Beispiel gibt es nur 12 bzw. 16 Threads. Ich gehe mal davon aus, dass AMD ebenfalls echte Cores vor SMT Cores bevorzugt, somit hätten die 16 SMT Cores nicht zutun und SMT liegt quasi brach.

 

[fdsonne]

Für mich klingt das alles nach einer mangelhaften Implementierung.

Die Programmierer können Threads Prioritäten zuweisen. So weiß der Scheduler, welchen Thread er auf welchen (SMT)Core verteilen muss. Problematisch wird das erst, wenn zu viele anspruchsvolle Threads auf zu wenig Cores treffen. Aber dann wird es ohnehin lahm.

Ne, das funktioniert nicht, weil sich der Bedarf je nach Szenario teils x-fach die Sekunde ändert. Nimm Gaming wieder als Beispiel, dann hat es bei 150 FPS 150x Bilder, die da berechnet werden. Ein geübter Gamer ist in der Lage bei sagen wir einem Shooter binnen einer Sekunde das Blickfeld von stark CPU limitiert in wenig anspruchsvoll und zurück zu ändern.
Was soll da eine Prio noch groß was bringen? Es kann von einem auf das nächste Frage auf einmal bspw. eine komplexe KI oder Physik ins Spiel kommen, die mal eben so die Threadlaufzeiten von vorher ruhenden oder nur seichten Dingen stark erhöht und damit das Gefüge der Threads zu Cores Zuordnung deutlich durcheinander würftelt.
Jetzt wirst du vielleicht sagen, OK, dann schubs die Threads halt rum wie es benötigt wird - KANN man machen, aber das bedeutet, die Daten der Caches gehen verlustig und müssen neu gezogen werden. Die Auswirkung davon sieht man bspw. wenn man auf nem Dual CCD Ryzen ein Game mal anstatt auf 1x 6-8C auf 2x3 oder 2x4C zwingt. Also die Verbindung über die lahme IF muss. Das kostet im Zweifel stark durchsatz durch einfach nur hohe Straflatenzen. -> deswegen ist das alle Nase lang rumschubsen auch nicht förderlich.

Ein Hintergrunddienst kann dann also so eingestellt werden, dass er nur auf den E-Cores bzw. nur auf den energiesparenden Cores läuft. Anwendungen, die wenige aber anspruchsvolle Threads haben, können bzw. sollte man so taggen, dass sie auf den P-Cores bzw. Nicht-SMT-Cores und vielleicht sogar auf den Cores mit Boost laufen.

Das ist reinste Theorie. In der Praxis ist es eher so, dass man anstatt mit einer fixen Anzahl an Threads mit einer Art Pool arbeitet. Das heißt, es gibt nicht "weniger anspruchsvolle Threads". Sondern es gibt einfach nur Aufgaben, die in einen Pool gekippt werden und wo am Ende dann die Gesamtlaufzeit entscheidet. Der Programmierer einer Software wird auch nicht zusätzlichen Programmcode integrieren, der die ganze Zeit den eigentlichen Programmcode überwacht und da große eingreifen. Programmierer sind faul und vor allem ist es viel viel viel einfacher mit Hardware auf das Problem zu schlagen. Sprich läuft es scheiße, kauf mehr Cores und gut ist.

Ich sage nicht, dass man das einfach umsetzen kann, aber unmöglich ist es nicht. Der Prozessor kann nicht entscheiden, welchen Thread es wie behandeln soll, aber der Programmierer kann es.

Der Programmierer könnte es, wenn er es denn wöllte und wenn die Aufgabe entsprechend so gestaltet ist, dass es überwachbar ist.
Beim Gaming ist das bspw. ein Ding der Unmöglichkeit, denn neben Dingen die das Game macht (Programmierer A) kommen noch Dinge dazu, die bspw. der Treiber fabriziert (Programmierer B) - die wissen nix voneinander. A kippt Aufgaben in eine Schnittstelle, die B bereit gestellt hat und am Ende muss der Threadscheduler vom OS wissen, ob jetzt der/die Threads von A oder von B die laufzeitkritisicheren sind. Denn wenn es eng wird, entscheidet sich hier stark wie viel Performance man liegen lässt.

Was macht man also? Man lässt sich nicht auf das Glückspiel ein und wird es nicht eng werden lassen

Oder ein anderes Beispiel: Smartphone CPUs
Die enthalten zwei bis drei verschiedene Core-Arten, um verschiedene Szenarien abzudecken. Was dort klappt, klappt auch in einem PC.

Das ist nicht vergleichbar, da dir der 1:1 Vergleich wie auf dem PC fehlt. Was man auf den PC macht ist wahlweise SMT an oder aus zu knipsen, Wahlweise E-Cores an oder aus zu knipsen oder sogar mit großen CPUs die Core-Skalierung zu ermitteln.
Das gibts auf dem Smartphone in aller Regel nicht. Ein Gerät, eine Konfig. Du wirst nicht rausbekommen, ob der Ansatz keine Ahnung 1+2+4 besser ist als der Ansatz 2+0+4 oder 2+2+8 oder sonstwas. Weil gibt es nicht zu kaufen...

 

[TaurusReloaded]

14% beim Multicore sind okay.
Die Frage ist am Ende der Verbrauch dabei.

Die Restlichen Steigerungen kann man nur als sanft bezeichnen.
Da es nicht gelingt sich deutlich vom Vorgänger abzusetzen oder dem von Testern gescholtenen Zen5/9950X.

 

[sikarr]

Das kann jeder von uns akzeptieren, nur würde ich gerne dazu Beispiele sehen und kein plattes: "16 P-Cores over all!! big.LITTLE ist kein Highend!".

Wo habe ich geschrieben das nur 16P-Cores Overall sein soll, und big.LITTLE keine Highend. Das ist genau das was ich gerade geschrieben habe.

Und welche Anwendung soll das sein

Stell dir vor das muss nichtmal nur eine Anwendung sein es können auch mehrere Parallel sein, WOW.

Du hast nicht 1x was positives über die CPUs geschrieben. Sämtliche Posts von dir sind kritischer Natur und nichts davon basiert auf irgendwelchen Fakten, sondern sind Annahmen/Theorie.

Ja weils auch nix Positives gibt.

Sag doch beim nächsten mal einfach: "Ich hasse Intel und liebe AMD".

Weder das eine noch das andere ist der Fall, und ich habe auch schon geschrieben das aktuell sogar ein Intel bei mir werkelt, sogar mit E-Cores Woohooo, soviel dazu.

Ihr tut immer so als gibt es nur Office gibt, dafür braucht man nix schnelleres als einen Intel® Core™ i3-1315U wie z.B. @GR Supra meint. Oder 8P Cores für Spiele und dann nur noch Unendlich viele für kosmologische Kollsionsimulationen. Dazwischen scheints bei euch immer nix zu geben, wie gesagt mal abseits der eigenen Nutzung schauen.