Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsGerüchte zu Alder Lake: Desktop-CPU mit bis zu 5,3 GHz und Leistung eines 5950X
Ich finde es interessant wie sich die bisher bei der Vorschau der kleinen so Entwickeln. Ich habe mal die Bilder durchgeschaut wo ich den 3970x testen durfte ,denn ich mache zu jeder CPU gerne Bilder. Mir ist aufgefallen das es keine 15 sondern nur 10 % abstand zum 5950x noch ist. Das heißt in wahrheit teste ich also 5950x non oc mit 3970 oc weil 4 ghz ist ja schon ein Oc. Würde man nun nen 3970x mit Luftkühlung betreiben viele die Leistung noch weniger beeindruckend aus und dann non oc dann fällt die Leistung.
Mir war nicht klar gewesen das so 10 % Leistungsunterschied nur herschen.Das ist ja nix. In Zukunft bin ich also auf so Kern Monster garnicht mehr angewiesen. Somit dürfte so ein Little Big CPU durchaus auch überzeugen. Kommt drauf an wie stark solche CPUS aufgebort werden. Nun verstehe ich auch warum sich die meisten nicht so viele Kerner gönnen. Da sogar ein 12 Kerner mit einem 24 Kerne mithalten kann bei mir,so wäre es durchaus beeindruckend wenn die neuen CPUS mit einem 12 Kerner mithalten könnten.
Irgendwann wird dann die Leistung ein 8 kerner ohne kleine Kerner bezwingen,sofern es denn in der Praxis möglich ist.
Hier entscheidet aber sehr wie stark sich Intel und AMD ins Zeug legen.Und die weniger Kerner lassen sich Ordentlich Takten. Denke mal Takt ist hier wirklich Trumpf. Und in Richtung 5 ghz Allcore hört sich durchaus schon der Hammer an. Damit schlägt man ja dann jeden noch Vielmehr Kerner deutlich. Der Preis wird halt der hohe Stromverbrauch sein. Aber dafür sind die kosten weit weniger hoch. Hier zahlt sich also am Ende der Kaufpreis der CPU aus. Ist auf jedenfall mir lieber als 2100 Euro für nur 1 CPU auszugeben.
Das hört sich mal wieder nach einer zusammengeschusterten, unappetitlichen Hybriden Notlösung an.
Das es Intel selbst mit 10 nm nicht schaft, 12 oder schon erst gar nicht daran zu denken 16 vollwertige Kerne zu liefern ist schon ein Armutszeugnis. Bzw. ein Bauernfängertrick. Aber klar wie viel soll denn so einer dann saufen 460W?
Ich mein wer soll sich dies, selbst wenn die Werte stimmen sollten am Desktop schon antun wollen.
Mal davon abgesehen, das es bei Intel eh nur für einen Durchgang für maximal 56s reicht. (oder haben sie mittlerweile das Unmögliche geschafft und die 60s Schallmauer durchbrochen?)
Es ist doch immer das gleiche, Intel macht zuerst auf dicke Hose und danach kommt wieder nur jede Menge heiße Luft und es steckt nichts dahinter.
Amd wird hingegen mit Vollwertigen Kernen und 3D Cache Alder Lake mickrig erscheinen lassen.
AMD Shows New 3D V-Cache Ryzen Chiplets, up to 192MB of L3 Cache, 15% Gaming Improvement 15% Gaming Improvement
Von Zen 4 ganz zu schweigen, selbst wenn Alder lake 20% IPC zulegen sollte, ist dies doch nur eine Tropfen auf dem heißen Stein.
Sorry aber das ist schlichtweg Blödsinn, dann könnte man doch auch problemlos jegliche Android oder iOS Apps portieren, die laufen doch allesamt unter ARM.
Nochmal, es geht nicht um iOS/Android-Anwendungen. Es geht um Anwendungen, die bislang auf macOS/Windows x86 liefen. Die Motivation, solche Anwendungen auf Windows ARM zu portieren ist klein, und der Aufwand dafür war früher zu groß.
Seit Apple M1 ist die Motivation, Anwendungen auf macOS von x86 nach ARM zu portieren groß, und deshalb passiert es in großem Umfang. Das hat nichts mit iOS zu tun. Und im Fahrwasser dieser Umstellung bekommt Windows ARM die Anwendungen auch gleich nativ ab, denn wenn man schon Windows x86 und macOS x86+ARM unterstützt, ist Windows ARM relativ trivial.
xexex schrieb:
Wer schreibt denn heutzutage noch Programme mit Assembler, in Visual Studio reicht ein Haken und das Teil spuckt ARM Binaries raus.
So einfach ist das teilweise leider nicht, sonst hätte Microsoft kein ARM64EC eingeführt. Dann gibt es noch das Problem, dass manche Programme binäre Plugins unterstützen. Und besonders was SIMD/Vektorisierung (SSE, AVX, usw.) angeht, gibt es weiterhin deutliche Vorteile, Assembler von Hand zu schreiben.
xexex schrieb:
Einzig bei speziell auf CPU optimierter Software müsste man gezielt Anpassungen machen und da hilf die geschlossene Apple Plattform eben wenig, da wir nie einen M1 in einem Windows Rechner sehen werden und die Optimierung dann auf einen Snapdragon oder ähnliche CPUs gemacht wird.
Der M1 unterstützt einige Spezialbefehlssätze, aber ansonsten z.B. was SIMD angeht ganz normal NEON. Es ist kein Problem, optimierte ARM-Software zu schreiben die auf Qualcomm und Apple schnell läuft.
Ich möchte mal darauf hinweisen, dass der PL2 nicht immer voll ausgeschöpft werden muss. Cinebench ist auch kein Prime95. Was du schreibst ist sehr spekulativ. Bis jetzt gab es keine 10nm CPUs für den Desktop von Intel.
Natürlich sind meine Ausführungen spekulativ, nicht zuletzt, weil es sich am Ende auf Gerüchte stützt. Zumindest bei Cinebench Runs kommen der 10900K und der 11900K sehr nahe an die 250 Watt PL2 ran oder sogar drüber, falls kein PL gesetzt ist (RKL), so dass der 12900K sehr wahrscheinlich die 228 Watt ausschöpfen wird, auch wenn es 10nm ist und 8 Little Cores zum Einsatz kommen.
mkl1 schrieb:
Auch möchte ich darauf hinweisen, dass die PL2 beim 8C RKL-S sogar bei 251W liegt und dennoch gerade mal 6000 Punkte damit erzielt werden. Die hohe Punktzahl lässt sich damit nicht erklären, zumal die PL2 schon bekannt gewesen ist und nichts Neues darstellt.
Die hohe Punktzahl setzt sich aus mehreren Faktoren zusammen wie IPC, Kernanzahl und Power Budget.
mkl1 schrieb:
Und übrigens kommen die 8 big cores bei 5.0 Ghz laut Raichu auf ~8250 Punkte. Das ist also schon erheblich besser als das, was RKL-S oder Zen 3 mit 8 Kernen schaffen. Dabei kann man ruhig mal erwähnen, dass der Cinebench in den letzten Jahren oder überhaupt seit Zen eine Paradedisziplin von AMD gewesen ist und aus dem Grund AMD sehr oft mit Cinebench ihre CPUs vermarktet hat.
Hui, da lag ich mit meinen 8000 Punkten gar nicht mal so weit weg. Ich folge Raichu auf Twitter, hatte das aber nicht mitbekommen.
mkl1 schrieb:
Jede Wette, sollte sich das drehen und für big+little zur Paradedisziplin werden, wird Cinebench zukünftig wieder zum verhassten Benchmark werden, wie er es schon vor Zen gewesen ist.
Wird es zumindest mit Alder Lake (noch) nicht. Wenn der 12900K auf 125 Watt zurückfällt, wird's gerade mal für den 5900X reichen. Raptor Lake könnte das Blatt wenden.
Ja und Nein. Das Hauptproblem bei Windows ist immer noch die Win32-API, die über die Jahre, teilweise auch undokumentiert gewachsen ist und die irgendwann nur noch auf x86 hin entwickelt wurde.
Microsoft hat in den 00er-Jahren auch dafür extra mal studentische Hilfskräfte und Bachelor-Absolventen eingestellt, die die Win32-API dokumentieren sollten, auch den Quellcode, damit man diesen auch effektiv weiter entwickeln und anpassen kann.
WinRT sollte entsprechend von einigen Altlasten und Co los gelöst werden, dann aber die "App"-Welt bei Microsoft getrennt und aktuell muss man bei der Entwicklung aufpassen, welche API man wie verwendet.
Microsoft arbeitet aber nun daran Win32 + WinRT wieder zu vereinen und gleichzeitig auch die Bestandteile der Win32-API für ARM fit zumachen, die es noch nicht sind.
xexex schrieb:
Sorry aber ein Office gibt es schon seit Jahren für ARM und auch von Adobe gab es eine ARM Variante.
So nicht richtig, weil zwar nach außen der gleiche Name verwendet wird, unter der Haube aber teilweise ganz andere Entwicklungen stecken. Genauso bei Adobe.
Wirklich "Desktop"-Programme auf ARM-Basis kommen quasi jetzt erst, weil Apple durch den Wechsel manchen Entwicklern auch zwingt. Wobei Apple es den Entwicklern etwas einfacher gemacht hat als es MS könnte. Apple hat wesentlich mehr Erfahrung, was Architekturwechsel angeht, da sie von 68k auf PowerPC und eben PowerPC zu x86. Entsprechend sind ja erst mal Carbon und später dann Cocoa entstanden als sehr sauere APIs, die gut dokumentiert sind. Wenn man nicht gerade wirklich plattformspezifischen Code bei Apple seit 2010 geschrieben hat, sondern Cocoa, OpenCL und später Metal, ist man eigentlich fein raus, weil einfach ein neu compilieren reicht.
xexex schrieb:
Unter Windows gibt es aber Millionen von Programmen für die es "nie" eine ARM Version geben wird und die sind entscheidend.
Von diesen Millionnen von Programmen wird ein Großteil heute auch überhaupt nicht mehr aktiv gepflegt, sondern entspringt noch der Zeit, als Win32 grausam war und Entwickler gerne mal auf nicht dokumentierte Befehle zurück gegriffen haben.
xexex schrieb:
Ich kann es nur nochmal wiederholen, Apple hat hier den iOS Vorteil und es dürfte mehr Software für iOS als für macOS geben, womit man grundsätzlich den Entwicklern sogar entgegen gekommen ist.
Natürlich spielt iOS durchaus hier eine Rolle, aber wesentlich wichtiger ist, dass Apple bereits in den 90er erste Erfahrungen mit Architekturwechsel hatte und damals gelernt hat, dass sie eine saubere gut dokumentierte API brauchen und Entwickler in Progrmamen möglichst keinen plattformspezifischen Code verwenden sollten, damit man den Unterbau jeder Zeit ändern kann.
Auch wichtig ist, dass Apple relativ früh schon ermöglichte Bibliotheken plattformübergreifend zu entwickeln, so dass man den Kern eines Programmes auf MacOS, iPad OS und iOS verwenden kann, während mann nur noch Gerätespezifischen-Code in die App schreiben musste.
xexex schrieb:
Auf die Windows Welt ist sowas nicht mal im Ansatz übertragbar und es "hilft" auch Microsoft nicht, wenn die Entwickler für ein vernageltes System und proprietäre Apple Hardware optimieren.
Vieles davon ist auf die Windowswelt übertragbar, weil die meisten Aspekte nichts mit dem vernagelten System zutun hat oder der properitären Apple Hardware, sondern einfach mit guter Softwarearchitektur zutun hat: Saubere und gleichzeitig möglichst flexible APIs, die es Entwicklern ermöglichen weitgehend ohne plattformspezifische Anpassngen auszukommen. Klare Trennung zwischen allgemein gültigem Code bei der API-Implementierungen und plattformspezifischen Code. Guten Compiler, der entsprechend auch eine saubere Trenung ermöglicht. Entsprechende Formate für Bibliotheken und Programme, die kombinierte Binaries zulassen.
All das hätte MS und kann MS machen und genau das machen Sie nun auch. Klar, bei alter Software bringt das nicht, da hier oft dann die ganze Codebasis umgestellt werden müsste, aber moderne Software ermöglicht das schon.
flo36 schrieb:
ARM sind deswegen Effizienzwunder, da diese wesentlich weniger können als x86 bzw. x64 CPUs.
Ach, was können den ARM-CPUs weniger, als x86/x64 CPUS? Oder wird hier einfach mal wieder pauschal etwas behauptet? Was du schriebst ist sowas von falsch!
Moderne ARM-CPU-Kerne sind alle OoO, besitzen Spekulative Ausführung von Befehlen, können mit verschiedensten Datenformaten umgehen, bieten passende Befehle für Verschlüsselung, zur Bit-Manipulaton, Bit-Masken, SIMD-Befehle mit 128 Bit - NEON, eine flexible SIMD-Extension, die weitgehend flexibel ist, SVE und sogar nun eine, die die Vorzüge von NEON mit SVE verbindet, alias SVE2. FMA-Befehle sind ebenso möglich.
Und all das schaffen viele ARM-CPUs immer noch mit weniger Energie als moderne x86-CPUs. Vom Featureset stehen moderne ARMv8-CPUs und erst recht später ARMv9-CPUs den x86-CPUs in nichts wirklich nach.
Verwechelt nicht immer die ISA und deren Möglichkeiten mit den späteren in Silizium gegossenen Schaltungen. ARMv8 hat einige Erweiterungen, die sogar über die Mögichkeiten von x86 + AVX512 hinaus gehen und mit ARMv9 werden zumindest vom Extensionset einige der Erweiterungen verpflichtend.
Frühere ARM-CPUs waren nicht so leistungsfähig, weil sie oft noch In-Order-Execution verwendeten, manche CPU-Kerne bei ARM sind heute noch nicht so leistungsfähig wie x86-CPUs, weil sie statt 4-fach Skalar nur 3-fach oder gar 2-fach Skalar ausgelegt sind. Genau so bei den SIMD, dass man halt nur 1 * 128Bit-SIMD-ALU in den Kern einfügt, statt 2 * 256 Bit bei AMD oder Intel (Intel scheint aktuell die AVX512 über 2*256 zu lösen). Apple zeigt mit dem M1 aber, dass man ein 6-fach Skalares Design mit 4 * 128 Bit umsetzen kann und dennoch weniger Energie benötigt, als eine moderne x86-CPU der Marke IceLake oder TigerLake.
flo36 schrieb:
Das würden die meisten Benutzer aber nicht merken. Je mehr aber die ARM CPUs mit div.
Codesets usw. kann, umso mehr Strom werden diese auch brauchen.
Auch das ist so nur zum Teil richtig: Entscheidend am Ende ist immer, wie Breit und Tief gestaltet man eine CPU und kann man alles passend auslasten.
x86 hat ein paar konzeptionelle Schwächen, die aus den späten 70er stammen und da schreibe ich nicht nur von CISC und den dadurch immer noch komplexeren Decoder für die µOPS, sondern auch von handfesten Nachteilen, die dazu führen, dass x86-CPUs früher auf Caches und den RAM zugreifen müssen, was auchd dazu führt, dass breitere Backends bei x86-CPUs mit einem deutlich größeren Rattenschwanz verbunden sind, als bei ARM-CPUs oder nun RISC-V.
Ich weiß, dass manche das hier nur ungern lesen, aber ARM muss sich vor x86 nicht verstecken. AMD und Intel müssen bei modernen x86-CPUs schon teilweise tief in die Trickkiste greifen, damit sie die 4-fache Skalarität überhaupt auslasten - µOP-Cache usw. - während Apple mit der ARM-ISA einfach einen 6-fach Skalaren Kern schafft, der aner bei der Infrastuktur der Load und Store-Einheiten ähnlich aufgestellt ist.
xexex schrieb:
Sorry aber das ist schlichtweg Blödsinn, dann könnte man doch auch problemlos jegliche Android oder iOS Apps portieren, die laufen doch allesamt unter ARM.
Ja, die meisten verstehen nicht, dass die Softare-Architektur heute oft wichtiger ist, als die ISA der CPU.
xexex schrieb:
Entscheidend für die Portierung aktueller Software ist selten die CPU Architektur, sondern die genutzte Programmierumgebung und die "Lust" der Programmierer.
Nur kann MS genau diese Programmierumgebung auch maßgeblich beinflussen. Sie haben aber Mitte der 90er aufgehört sich um die Portierbarkeit der Programme zwischen den Architekuren zu kümmern und haben in den 00er überhaupt nichts gemacht, was das angeht.
Erst jetzt bemüht sich MS wieder darum und muss aufholen, aber das wird schon werden. Nur wirkt sich das - wie geschrieben - nur auf aktuelle Entwicklungen aus, nicht auf vergangene.
Ergänzung ()
chithanh schrieb:
Die Motivation, solche Anwendungen auf Windows ARM zu portieren ist klein, und der Aufwand dafür war früher zu groß.
Der Aufwand dafür ist immer noch groß. Nur zwingt Apple mit dem Umzug auf ARM Adobe und manche andere Anbieter nun dazu ihre Software erneut anzupassen, sofern sie vorher noch teilweise Carbon-Aufrufe verwendet haben oder wirklich noch spezialisierten Assembler.
chithanh schrieb:
Und im Fahrwasser dieser Umstellung bekommt Windows ARM die Anwendungen auch gleich nativ ab, denn wenn man schon Windows x86 und macOS x86+ARM unterstützt, ist Windows ARM relativ trivial.
So trivial ist es nicht, aber wenn man schon dabei ist alten Code der eine direkte neu Compilierung nach macOS ARM verhindert, zu ersetzten, dann nimmt man natürlich auch für Windows ARM die Stelle gleich mit. Man muss aber auch bei Windows in dem Fall ggf. auch noch etwas mehr Arbeit investieren und Stellen anpassen.
chithanh schrieb:
Dann gibt es noch das Problem, dass manche Programme binäre Plugins unterstützen.
Was aber auch wieder eher ein Problem des Compilers, der Programmiersprache sowie der API des OS ist.
Apple hat für SIMD/Vektor-Operationen auch eine entsprechende API/Framework, dass man verwenden kann, was ab diesem Zeitpunkt auch die meiste Optimierungen entsprechend selbst übernimmt. Das Framework von Apple unterstützt dabei aktuelle Vektoren bis zu 512 Bit und passt diese passend an die Zielplattform sogar an, so dass für ARM die passende 128 Bit-NEON-Operationen heraus kommen, während man bei modernen Intel CPUs sogar AVX2 mit 256 Bit heraus kommt.
Der sinnvolle Nutzen erschließt sich mich auch nicht. Ich kauf doch kein I9 und dann ums verrecken nicht aus dem Pott zu kommen. @v_ossi: Wenn nun die Leistung der Mogelpackung bei einem 5950X liegt, dann liegt theoretisch diese bei 16 vollwertigen Kernen wo?
Ich verteufle das nicht voll und ganz, im Mobilen Sektor mag sowas sinnvoll sein. Aber nicht wenn man diese Leistung möchte...
Der Aufwand dafür ist immer noch groß. Nur zwingt Apple mit dem Umzug auf ARM Adobe und manche andere Anbieter nun dazu ihre Software erneut anzupassen
Was ich meinte ist dass früher der Aufwand groß war, weil noch keine ARM-Portierung vorlag. Jetzt ist sie da (für macOS), und dadurch sinkt die Hürde es auch für Windows ARM zu portieren. Deshalb kommen gleichzeitig oder mit etwas Verzögerung zu den macOS ARM Versionen auch die Windows ARM Versionen vieler Softwareprodukte raus, M1 sei dank.
DevPandi schrieb:
So trivial ist es nicht, aber wenn man schon dabei ist alten Code der eine direkte neu Compilierung nach macOS ARM verhindert, zu ersetzten,
Es geht nicht nur darum, dass es kompiliert, sondern auch darum dass es wie erwartet läuft und interoperabel ist. Manche Programme nutzen als "Dateiformat" etwa nur eine Art Speicherdump, den sie wieder einlesen (z.B. Microsoft Office hat das früher so gemacht). Wenn sich aber zwischen ARM und x86 jetzt das Alignment oder andere Dinge ändern, funktioniert es nicht mehr so wie erwartet, eine Datei mit der ARM-Version abzuspeichern und mit auf x86 wieder einzulesen oder umgekehrt.
Noch schwieriger wird es, wenn Berechnungen mit Gleitkommazahlen reproduzierbar bleiben sollen.
DevPandi schrieb:
Man muss aber auch bei Windows in dem Fall ggf. auch noch etwas mehr Arbeit investieren und Stellen anpassen.
Das ist vergleichsweise wenig, und der größte Aufwand dürfte beim Testen anfallen da die Betriebssystem/CPU-Architektur-Matrix jetzt doppelt so groß ist wie früher.
DevPandi schrieb:
Das ist ja nicht direkt ein Problem, das eigentliche Programm lässts ich ja übersetzen. Das Problem hat dann eher das Plugin. Ist aber relativ.
Das Problem ist, dass beides nicht mehr zusammen läuft. Und dieses Problem ist groß genug, dass Microsoft es zum ausdrücklichen Designziel von ARM64EC erklärt hat, diesen Fall zu unterstützen.
DevPandi schrieb:
Apple hat für SIMD/Vektor-Operationen auch eine entsprechende API/Framework
Ist doch vollkommen egal. Dieses theatralische Diskutieren um große und kleine Kerne, Mogelpackungen und 'richtige' Kerne ist doch das reinste Kindergartenniveau.
Zumal das im Smartphone oder bei Apple (M1) schon gang und gäbe ist und Niemanden stört. AMD steuert auch darauf zu.
Du wirfst ne Aufgabe drauf, CPU X erledigt sie in Zeit A mit Leistungsaufnahme B und CPU Y erledigt sie in Zeit C mit Leistungsaufnahme D.
Überspitzt formuliert:
Meinetwegen kann Intel mir auch nen Hamster mit nem Abakus verkaufen, wenn der schneller als ne AMD CPU rechnet, soll's mir recht sein.
Ist doch vollkommen egal. Dieses theatralische Diskutieren um große und kleine Kerne, Mogelpackungen und 'richtige' Kerne ist doch das reinste Kindergartenniveau.
intel lag immer 5-10% hinter den versprechungen soweit ich das die letzten jahre beobachten konnte,
dürfte aber niccht mehr lange sein bis wir es wissen, so Nov. hatte ich mal gelesen.
Bei 4K ist das sowas von Schnuppe. Hauptsache Intel kommt diesmal früher mit einer neuen PCIe Schnittstelle.
Was mich nur ärgert ist das bei Vollausbau der Preis nun bis Meteor Lake Release wohl erstmal beim i9 Segment bleibt :/ das hatte Intel bis dato besser gelöst (i7 Segment).
ich bin mal gespannt wie das mit dem OC abläuft...ob man Gefahr läuft die kleinen Kerne zu grillen wenn man nur die 8 großen hochprügeln will. Zum Zocken reichen ja 8 Kerne immer noch mehr als aus und die kleinen Kerne helfen ja für den Anwendungskram drum herum....laut einigen AMDLern sind ja mehr als 8 Kerne super wichtig für Teamspeak und so.
Ja was ist denn dann mit denen die wie ich 2x Videoumwandelt und gleichzeitig zocken tut. Da reichen 8 Kerne nicht mehr aus.Bin gespannt wie es sich dann da bei mir dann verhalten wird die kleine Kerne. Ich werde alle Kerne auch die kleinen Kerne zu 100 % voll auslasten. Ob ich da dann Leistung verlieren werde,ist ne andere Frage.Ich hoffe ja mal nicht das ich die Verliere.Achja L1 und L2 Cache wird auch entschieden bei mir ob ddie 3 gleichzeitig funktionieren werden oder nicht. Ist halt die Frage wieviel L1 und L2 Cache werden denn die kleinen Kerne bekommen.Das ist die andere Frage bei mir.
Artikel-Update:Core i9-12900K mit 11.600 Punkten im Cinebench R20
Einmal mehr ist es der Twitter-Nutzer @OneRaichu, der weitere Benchmark-Ergebnisse eines Qualification Sample („QS“), wie OEMs es zum Testen der Plattform in ihren Systemen erhalten, des Core i9-12900K liefert.
Hier kann die Top-SKU vom Typ Alder Lake-S sogar noch einmal zulegen und erreicht 810 Punkte im Single-Thread- respektive 11.600 Punkte im Multi-Thread-Test von Cinebench R20. Laut den Informationen lief die CPU dabei ohne OC.
[Embed: Zum Betrachten bitte den Artikel aufrufen.]
Wie immer sollten solche Ergebnisse von Vorserien-CPUs, Engineering- und Qualification-Samples mit einer gewissen Vorsicht genossen werden, zeigen aber in der Regel auch, wohin die Reise gehen kann.
116xx Punkte packt der 5950X bei 4,5 GHz Allcore. Mit den pauschal gewählten 1,28V eingestellten und 1,20V anliegend sind das 200W nach HWiNFO
Oh Cinebench liest es sogar richtig aus
Mit 1,16V anliegend sind es 176W, da geht wohl noch weniger🤷♂️
Der 10xxx Serie meinst du wohl, Comet Lake war schon 6 Monate auf dem Markt, als Zen3 kam und 4 Monate danach kam Rocket Lake.
Zeitlich liegen Ryzen 5xxx und Core 11xxx also am dichtesten beieinander.
Das sind natürlich hervorragende Nachrichten und somit endet AMD´s Höhenflug schneller als man es für möglich gehalten hätte. Intel ist zurück! Holt den Champagner aus dem Keller.
Nun ist auch klar, warum AMD ihre TDP mit der nächsten Generation deutlich anhebt.
