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

[eastcoast_pete]

Ich traue bei solchen "Pre-Release" Leaks erst mal niemand, egal ob AMD, Intel, Qualcomm oder Apple. Meine Interpretation: Arrow Lake CPUs sind in der Tat in der Produktion, und werden in Q4 erscheinen, was insgesamt eine gute Nachricht ist - Konkurrenz belebt das Geschäft. Alles andere wird man dann sehen, wenn Arrow Lake in der freien Wildbahn gesichtet wird.
@Volker: ist es denn jetzt bereits sicher, ob die iGPU bei Arrow Lake Xe oder Xe2 sein wird? Oder kommen beide Varianten?
Und Lunar Lake steht ja schon früher an (im nächsten Monat), und dann wird's v.a. im Low Power Bereich (Laptops, 2-in-1s) richtig interessant, mit dann 3 neuen APUs/SoCs (Snapdragon - Qualcomm, Strix Point - AMD und Lunar Lake - Intel) die dort konkurrieren. Auf die Vergleichstests freue ich mich schon. Wäre auch schön, wenn hier Hersteller wie Lenovo, ASUS, HP und Dell ansonsten identische Laptops (gleiches Display, Gehäuse, Akku Kapazität) mit jeweils allen drei APUs/SoCs anbieten würden. Denn die doch sehr heterogene Ausstattung macht das Bestimmen, welche APU jetzt wirklich die effizientere und besser angepasste ist, schwierig bis fast unmöglich.

 

[DevPandi]

Zudem sind Intel CPUs meistens vergleichsweise stark im Geekbench. Warum auch sonst, ist das immer gleich Intels erster Anhaltspunkt, um sich zu messen?

Naja, dass sich Zen 5 und Arrow Lake dieses mal auf Augenhöhe bewegen werden, hat sich bereits seit einiger Zeit angedeutet.

AMD hat bei Zen 5 den Vorteil der AVX512-Instruktionen und das einiges an Software damit auch umgehen kann. Je nach Benchmarks wird Zen 5 davon ziehen, oder eben knapp dahinter liegen.

Glück für Intel dass Zen5 eher schwach ist

Zen 5 ist nicht wirklich schwach. In dem Fall zeigt sich halt, dass "Kerne" nur bedingt durch SMT "aufgefangen" werden. AMD schickt 16 Kerne ins Rennen, Intel 24. Für Intel ist das Glück eher, dass AMD aktuell noch nicht vorhat im Desktop über 16 Kerne zu gehen.

Ineffizient und hoch unsicher.

SMT ist ineffizient? Die Aussage ist relativ weitgehend falsch. SMT dient in der Regel dazu, ungenutzte Ressource des Kernes zu nutzen. Mit SMT wird in der Regel die Effizienz einer CPU erhöht, weil ungenutzte Ressourcen nicht einfach verpuffen.

Und "hoch unsicher", auch das ist so nicht richtig. Ja, einige der Sicherheitslücken haben sich Gegebenheiten von SMT zunutze gemacht, gleichzeitig ist das eine Frage der Implementation gewesen. Eine saubere Implementierung von SMT ermöglicht solche Angriffe wie Spectre nicht mehr oder weniger.

Threads springen heute ohnehin zwischen den Kernen hin und her, da der Scheduler sie unterbricht, um die Ressourcen anderen Threads zuzuweisen.

Als Intel CPUs AVX512 hatten, war es der heißeste Scheiß den "jeder" brauchte.

Das Problem an AVX512 ist, dass volles AVX512 relativ viele Transistoren bräuchte. Intel versucht bei den E-Kernen diese Transistoren bewusst zu sparen.

AVX512 führt 32 Register ein, entsprechend aufgestellt werden muss das Register-File im Kern. Dazu muss die Anbindung sein und auch die Breite der Datenpfaden in den Rechenwerken.

Der Nutzen von AVX512 ist dabei überschaubar. Vektorisierung auf 4 und 8 Werte ist schon eine Kunst teilweise. Mit 16 Werte ist es auf CPU-Sicht noch schwieriger. Algorithmen der Mediengestaltung und Co können profitieren, auch Algorithmen die mit vielen Daten arbeiten, im "Alltag" aber eben nicht so viel.

Intel führt deswegen AVX10 ein, dass die "Befehle" von der "Breite" trennen. Damit kann Intel die Vektorpfade in den E-Kernen auf 256 Bit breite lassen, in den P-Kerne auf 512 Bit verbreitern und am anhand der Menge der "Daten" entscheiden, ob sie eben auf den E-Kernen in "2" Durchläufen ausgeführt werden, während in den P-Kernen nur einer gebraucht wird.

Außerdem bedingt HT, dass eine längere Pipe unter Spannung steht, das ist ineffizient, wie ein Vorheizen ohne dann zu Backen.

Seit wann wirkt sich HT/SMT auf die Länge der Pipeline aus und was dann unter Spannung steht.

Zudem wäre es mir neu, dass Intel als auch AMD so fein granuliert die Bestandteile ihrer CPUs aktivieren bzw. deaktivieren können. HT/SMT benötigen in der Regel zwar ein paar zusätzliche Transistoren zur Ausführung, das bezieht sich aber in der Regel darauf, dass man das Registerfile mit einem "2 Satz" an Registern ausstatten muss. Dazu kommt ggf. noch "Prefix"-Bits, damit man die Register und die Befehle dem Thread zu ordnet, der läuft.

Da die Kerne in der Regel nie "so" fein granular gesteuert wird, erhöht man mit SMT in der Regel sogar die Effizienz des einzelnen Kernes, da der Output durch den zweiten Thread erhöht wird. Je nach Workload und Implementation kommt im Mittel 120 - 125 % heraus. Ja jeder einzelne Thread "leistet" dann zwar weniger, aber in Kombination mehr.

Wenn eine Software SMT Threads nutzen kann, kann sie auch physische Kerne nutzen. Das heißt, es macht eigentlich keinen Sinn SMT zu nutzen wenn man auch Kerne dran bauen kann. Es sei denn, das Design gibt Limits vor.

SMT war ja auch in der Form nie dafür gedacht wirklich ein "zweiter" Kern zu sein, sondern es war immer dazu gedacht, die Auslastung der Kerne zu erhöhen. In den Kernen entstehen "Wartezeiten", weil auf Daten gewartet wird oder eine Berechnung auf eine vorherige Warte. Mit OoO und Co hat man das "minimiert". Gleichzeitig ist es aber immer noch vorhanden. SMT ist dazu gedacht, dass sich ein zweiter Thread in diese Warteschlitze "zwängt", damit kein Leerlauf entsteht.

Genau so. Viele E-Cores mit kurzer Pipe und ohne HT, das ist das optimale Ziel.
Und natürlich ein OS und Software die das gut Nutzen können.

Warum ist das bitte das optimale Ziel? Weißt du überhaupt, was die Pipeline ist, was deren "Länge" bedeutet oder deren Breite?

HT hat so absolut gar nichts mit einer Kurzen "Pipe" zutun, oder mit einer langen "Pipe". Pentium 3 hatte eine kurze "Pipe". Pentium 4 hatte eine lange Pipe und das schon damals ohne HT.

Jede Stufe der Pipeline stellt einen "Arbeitsschritt" dar, denn ein Befehl durchläuft. Je kürzer eine Pipeline ist, des so mehr muss - vereinfacht ausgedrückt - in der aktuellen Stufe ausgeführt werden. Je länger die Pipeline ist, umso einfacher die Aufgaben pro Stufe, um so schneller kann die CPU takten.

Die Breite wiederum bestimmt, wie viele Befehle zur gleichen Zeit abgearbeitet werden können. Und Lion Cove wird, trotz dass es kein SMT hat, ein relativ "dicker" Kern und ist nach den aktuellen Informationen sogar etwa breiter als Zen 5. Lion Cove liefert 18 Ports mit 6 AGU, 6 ALU und 4 FP-ALU und 2 "Store"-Units. Zen 5 kommt auf "16 Ports".

Und damit merkt man auch, dass Lion Cove weitgehend so auch in Servern, dann mit HT zum Einsatz kommt.

 

[BloodGod]

Lustig, wie emotional geladen es hier zugeht.
Es wird gebissen, geschnappt und gejault.

IT‘ler halt, meist sehr putzige und völlig harmlose Tastaturkrieger, sagt jedenfalls meine Frau immer 😏

 

[danyundsahne]

Im GB ist man wohl etwas hinter der MC Leistung des 9950X zurück. Aber im gesamten Anwendungsparcour ist der 9950X 10% sim Schnitt schneller als der 14900K.
Also da muss dann der 285K erst hinkommen.

Dass beide Top CPUs hier wohl auf Augenhöhe agieren werden, sollte jedem klar sein.
On Top kommt halt noch AMDs AVX-512 Support, den Core 200 nicht liefern wird. Hier wird AMD auch deutlich vor der Intel CPU sein.
Und dann sieht man bei welchem Verbrauch das alles geschieht. Das ist ja das große Thema.

Ansonsten wird Core 200 im Gaming schneller werden als die Non-X3D Varianten. Und die X3D Varianten werden wohl wieder etwas schneller und deutlich effizienter als Core 200.

Lets see....

 

[TaurusReloaded]

das Zitat suckt aber.

Stammt halt nicht von mir.

Wer am PC überwiegend surft, Emails checkt, YT klotzt ... der ist quasi im Idle Zustand. Idle != Standby.

Lt. PCGH ist das kein Idle. Idle=Leerlauf halt.

In der Praxis bedeutet nämlich Surfen, Videos sehen, Buchhaltung, Programmieren etc... sehr oft nahezu Idle-Verbrauch

Per Definition halt nicht. Praktisch auch nicht, eben weil die CPU keinen Leerlauf hat sondern eben doch, wenn auch nur etwas Last anliegt.

ür sehr viele ist der entsprechende Verbrauch nicht zu vernachlässigen.

Erzeugt aber auch keine horrenden Mehrkosten.

 

[fdsonne]

Bei mir (Linux) sind es 163 Tasks, 1373 Threads und 179 Kernel-Threads. Davon laufen bei meiner üblichen Nutzung 1-6 Tasks tatsächlich gleichzeitig (laut htop). Der Rest liegt nur bereit und wartet auf seinen Einsatz.

Die anderen laufen auch "gleichzeitig". Der Knackpunkt ist, die laufen in einer Art Wartestate und damit kann der Scheduler diese eben einfach in diesem belassen. Aber wehe, wenn da mal welche was wollen, dann braucht es entweder genug freie Cores oder es wird bis hin zu einer fast vollständig gleichen Verteilung pro Task runter gebrochen. Drei Tasks auf einem Core = 1/3tel für jeden, vereinfacht gesagt.

So läuft es doch im Moment. Fast alle Threads haben die Standardpriorität, sehen sich also als gleich wichtig an. Da ist fast keine Differenzierung vorhanden, obwohl genau die der Schlüssel zu einer besseren Ressourcenverwaltung ist.

Wenn du nur zwei eine Ebene höher setzt und diese gleichzeitig die selben Ressourcen beanspruchen, bleibt das Verteileproblem weiterhin vorhanden. Was hast du damit gekonnt? Nix...

In dem Fall greift man auf die bekannten Standardtechniken zurück, Round Robin usw.

Du verstehst scheinbar das Problem nicht. RR bedeutet 50% links, 50% rechts. Das ist keine Prio, sondern das ist ein gleichsames Verteilen von 100% Ressourcen zu möglichst gleichen Teilen. Am Ende hast du damit gar nix gekonnt. Es bleibt beim Problem, dass der "Verteiler" nicht weiß ob A jetzt wichtiger als B ist wenn beide meinen die selbe Prio rein geschrieben zu haben. Und das ist zwangsweise so, wenn völlig unabhängige Entwickler ihren eigenen Kram zusammen coden.

Wie oben schon geschrieben, ist es gerade dann um so wichtiger zu wissen, welcher Thread wie wichtig ist.

Bitte erklär doch mal wie das gehen soll? Das funktioniert nicht, wie ich dir nun x-fach aufgezählt habe. Das geht bestenfalls auf eine Art "Wunschliste" hinaus. Aber der, der letzlich entscheidet wer welche Ressourcen nutzen darf ist OS Seitig der Threadscheduler, der hat aber keine Deutungshoheit in der Form, dass er weis was der Anwender will.

Simples Beispiel. Ich spiele und rendere. Will ich jetzt dass das Spiel möglichst unbeeindruckt vom Renderjob läuft, dann ist das Möglichkeit 1, will ich aber möglichst effektiv rendern und das Spiel ist mir egal, gibts Möglichkeit 2. Woher soll das wer wissen? Das ist einzig und allein Anwendersache. Kein Programmierer, kein Scheduler, Niemand anderes kann das wissen.

Wenn ich 8 Tore (P-Cores), 8 Türen (E-Cores), 8 Lüftungsschächte (HT) und 100 Postboten habe, wovon die eine Hälfte Lebensmittel und die andere Hälfte Klopapier transportieren: In welcher Reihenfolge schickt man welche Postboten zu welchem Ausgang?
Das zu bestimmen, ist genau die Aufgabe, die ein Scheduler hat. Das fällt alles in die Pareto-Optimierung und das ist ein gut untersuchtes Feld.

Unpassendes Beispiel. Denn so funktioniert die Technik nunmal nicht.
Es gibt nicht Tore und Türen mit ner fixen Größe und Lüftungsschächte, die wahrscheinlich der Wahl des Wortbeispiels zu entnehmen, deiner Ansicht nach nur kleine Öffnungen sind. Sondern es gibt acht große Löche und acht bzw. 16 kleien Löche. Wenn durch ein großes Loch eine Person durch steigt, dann ist da noch "Luft", wo sich eine zweite dünnere Person mit durchschlängeln kann. Aber beide werden sich gegenseitig behindern! Mal mehr, mal weniger stark. Wie stark, hängt davon ab, wie dick die beiden Personen sind.
Bei den kleinen Löchern wird exakt immer nur eine Person durchgelassen, die ist dann so schnell oder langsam wie sie ist.

Die Frage ist hier am Ende, ist es sinnig, an den großen Löchern festzuhalten, wenn da zwar zwei gleichzeitig durch passen, aber durch die Behinderung schlicht der eine, der aonst alleine durch gehen würde, mehr Zeit braucht? -> DAS ist mMn fraglich.
Und was noch dazu kommt, selbst wenn du jetzt NACH den Löchern etwas plazierst, was die Briefempfänger befragt, ob der Brief schnell genug ankam, dann hast du lange noch nicht den nächsten Brief, der blickdicht verschlossen ist, durchs richtige Loch geschickt. Du kannst nicht Hellsehen. Ich auch nicht. Auf dem Brief steht es von außen nicht drauf. Und selbst wenn du es drauf schreiben lässt, weis der Absender nicht wie wichtig dem Empfänger der Briefinhalt wirklich ist... Ergo, das bringt nix.

 

[foofoobar]

Intel führt deswegen AVX10 ein, dass die "Befehle" von der "Breite" trennen. Damit kann Intel die Vektorpfade in den E-Kernen auf 256 Bit breite lassen, in den P-Kerne auf 512 Bit verbreitern und am anhand der Menge der "Daten" entscheiden, ob sie eben auf den E-Kernen in "2" Durchläufen ausgeführt werden, während in den P-Kernen nur einer gebraucht wird.

Zen4 kriegt dieses Verhalten ohne AVX10 hin und die Mobilversion von Zen5 schiebt AVX512 auch über 256-Bit ALUs.

 

[Moritz Velten]

Glückwunsch an Intel

 

[TigerherzLXXXVI]

Erst einmal sehen, wie hoch die tatsächliche Leistungsaufnahme bei den Intel-CPUs sein wird und ob das Geekbench-Ergebnis nicht doch ein wenig geschummelt ist.

Stichwort: der Core i9-14900K mit maximal möglicher Übertaktung (inkl. extrem schneller CPU-Degradation) vs sichere Intel Base Line Settings (P1=125W; P2=188W)... Das macht in den jeweiligen Benchmarks schon einmal einen Performanceunterschied von über 20% aus.

Intel wäre gut beraten nach dieser katastrophalen Entscheidung, unbedingt die Balkendiagramme mit Hilfe der ultimativen Brechstange anführen zu wollen, jetzt "ein wenig kürzer zu treten".

 

[Piktogramm]

Intel führt deswegen AVX10 ein, dass die "Befehle" von der "Breite" trennen. Damit kann Intel die Vektorpfade in den E-Kernen auf 256 Bit breite lassen, in den P-Kerne auf 512 Bit verbreitern und am anhand der Menge der "Daten" entscheiden, ob sie eben auf den E-Kernen in "2" Durchläufen ausgeführt werden, während in den P-Kernen nur einer gebraucht wird.

AVX10 ist nach meinem Verständnis kein Vektorbefehlssatz mit variabler Länge. Die Instruktionen sprechen immer noch 128, 256 und 512bit Register an. Es können also auch künftig keine x86 Kerne gebaut werden, wo man einen Thread der ZMM? anspricht auf einen kleinen Kern schieben kann, der nur YMM? bietet. Der kleine Kern muss dann schon die breiten Vektorbefehle implementieren bzw. die entsprechenden Register kennen. Bei den kleinen Kernen kann intern die 512bit Instruktion als 2x 256bit abgebildet werden, was ja aber mit dem alten AVX2/512 auch schon geht.

Edit: Das AVX10 die Vektorbefehlssätze aufräumt ist aber Imho extrem sinnvoll.

 

[maximus_hertus]

Tatsächlich ist es eher so in der Wirtschaft, dass man die Preise senkt um die Nachfrage und somit Produktion künstlich zu steigern was wieder die Kosten senkt.

Genau so war es ja auch bei AMD und Bulldozer, die wurden extrem günstig verkauft. Nicht weil sie günstig zu produzieren waren, sondern weil dass die einzige Möglichkeit für AMD war, am Markt zu bleiben.

Intel fertigt aber nicht selber, sondern bei TSMC.

Bei Bulldozer war ja das Hauptproblem, dass man nirgendwo wirklich Konkurrenzfähig war. Arrowlake wird wahrscheinlich die Spitze übernehmen, also eine komplett andere Situation.

AMD musste irgendwie eine Mindestabnahme hinbekommen (man musste eine garantierte Mindestmenge bei GloFo produzieren lassen). Daher gab es auch ordentliche Strafzahlungen, weil man das NICHT geschafft hat.


Mein Posting sollte nur darauf hinweisen, dass es keine Überraschung wäre, wenn Intel versuchen wird, die Margen so gut es geht zu erhöhen.


Arrowlake wird wahrscheinlich (wieder) lange durchhalten müssen (wie Raptorlake wohl 2 Jahre) und da wird man sicherlich eher zu hoch als zu niedrig (bei den Preisen) einsteigen.

 

[gaelic]

Phoronix, auch gern mal als "Linux Bild" bezeichnet.

Hmm, poronix berichtet sehr ausführlich und oftmals im Detail. Was soll daran "Bild" mäßig sein. bzw. wer bezeichnet phoronix "gern" so?

 

[iNFECTED_pHILZ]

Intel CPU ist in Intels lieblingsbenchmark vor der. Konkurrenz... Und das als headliner.. Echt jetzt?
@Volker sah dich echt auf einem guten Weg bzgl Neutralität, aber das ist leider wieder richtiger blauer Mist.

 

[Morpheus101]

100% mehr Stromverbrauch für 2% mehr Leistung oder wie ist der Deal für die Intel-Aktienbesitzer jetzt so? Naja, irgendwer wird sich das schon kaufen weil es bei ihm erotische Gefühle auslöst.

 

[stefan92x]

Intel CPU ist in Intels lieblingsbenchmark vor der. Konkurrenz... Und das als headliner.. Echt jetzt?
@Volker sah dich echt auf einem guten Weg bzgl Neutralität, aber das ist leider wieder richtiger blauer Mist.

Nach dem Chaos-Launch von Ryzen 9000 habe ich volles Verständnis, wenn Volker erstmal die Schnauze von AMD voll hat

Davon abgesehen: Klicks bringen Umsatz, und wir alle wissen, dass nichts hier mehr Klicks bringt, als AMDBase in Aufruhr zu versetzen

 

[foofoobar]

Lt. PCGH ist das kein Idle. Idle=Leerlauf halt.

Es ballern sowieso permanent Timer-Interrupts auf die CPU, demnach gibt es also kein Idle?
Und was juckt mich "PCGH"?

 

[Kopiervorlage]

Stammt halt nicht von mir.

Lt. PCGH ist das kein Idle. Idle=Leerlauf halt.

Per Definition halt nicht. Praktisch auch nicht, eben weil die CPU keinen Leerlauf hat sondern eben doch, wenn auch nur etwas Last anliegt.

Erzeugt aber auch keine horrenden Mehrkosten.

Unter Windows ist die CPU nie im wörtlichen "Leerlauf", auch nicht im Idle. "Leerlauf" im wörtlichen Sinne wird auch nicht getestet. Auch wenn ein PC einfach nur an ist ohne "irgendetwas zu tun" (in Dummy Sprache) werden trotzdem viele Millionen an Instruktionen pro Sekunde abgearbeitet, alleine schon da u.a. der Scheduler auf der CPU ausgeführt wird. Praktisch bedeutet dies folgendes: Der Verbrauch steigt nur minimal, wenn durch surfen jetzt z.B. 10 Prozent mehr Instruktionen je Sekunde ausgeführt werden müssen als ohne (Also die CPU z.B zu 1,1 Prozent statt 1 Prozent ausgelastet ist).

 

[Vortox]

Ich bin gespannt ob noch eine CPU mit nur E-Cores kommt, meinen Heimserver würde es freuen.

 

[iNFECTED_pHILZ]

Nach dem Chaos-Launch von Ryzen 9000 habe ich volles Verständnis, wenn Volker erstmal die Schnauze von AMD voll hat

Das ist ein Punkt. Hier scheint einiges nicht rund gelaufen zu sein.

Davon abgesehen: Klicks bringen Umsatz, und wir alle wissen, dass nichts hier mehr Klicks bringt, als AMDBase in Aufruhr zu versetzen

Meh. Geekbench ist halt bekannt dafür dass er null Aussagekraft hat. Und dann nen headliner draus zu machen..

 

[fdsonne]

SMT war ja auch in der Form nie dafür gedacht wirklich ein "zweiter" Kern zu sein, sondern es war immer dazu gedacht, die Auslastung der Kerne zu erhöhen. In den Kernen entstehen "Wartezeiten", weil auf Daten gewartet wird oder eine Berechnung auf eine vorherige Warte. Mit OoO und Co hat man das "minimiert". Gleichzeitig ist es aber immer noch vorhanden. SMT ist dazu gedacht, dass sich ein zweiter Thread in diese Warteschlitze "zwängt", damit kein Leerlauf entsteht.

Mir ist das ja bewusst, aber scheinbar gibts hier Leute, die da lieber gern auf Biegen und Brechen mehr Auslastung hätten und dafür die Laufzeit der einzelnen Sachen eingrenzen als anders herum. Denn man verargumentiert ja die bessere Auslastung nicht als solche, sondern mit dem Seiteneffekt der in Summe dann höheren Leistung (auf die Zeiteinheit kumuliert)

Perse ja OK, aber mittlerweile ist es eben sehr einfach mehr Ressourcen dran zu bauen, sodass man mehr erreicht in Summe, wenn man dann so Einschränkungen wie SMT außen vor lässt. Das heißt nicht, dass man das unbedingt wegknipsen sollte, ganz und gar nicht. Aber ein Beinbruch ist es letztlich nicht.

Ist jetzt vielleicht nicht mehr ganz aktuell, seit dem dürfte sich in diesem Bereich aber nicht allzu viel getan haben.

Wobei das auch nur das übliche generische Volllast 1 Task auf die gesamte CPU ist.
Was damit leider nie beleuchtet wird ist die Threadlaufzeit bei Mixed Workloads oder bei Workloads, wo verscheidene Anwendungen gleichzeitig laufen.

Wie gesagt, Gaming + Rendern ist so ein Paradebeispiel, wo SMT stark hinderlich sein kann und wo meist Render-Threads die "falschen" Threads des Games beeinflussen, wenn man das nicht aktiv durch Threadpinning oder sonstwas als User manuell verbietet.
Die 10, 20% mehr SMT MT Leistung nutzen wenig wenn das Game dann die Hälfte der FPS einbüßt, vereinfacht ausgedrückt. Dann doch lieber auf 10, 20% MT Speed verzichten und das Game in Schnell haben.

Die Prio im Taskmanager bringt da auch nix, weil für den Taskmanager zwei Threads auf dem selben Core trotzdem zwei Threads sind. Prio hingegen ohne SMT würde wieder funktionieren.