News Gerüchte zu Alder Lake: Desktop-CPU mit bis zu 5,3 GHz und Leistung eines 5950X

[Kloin]

und wenn der Watt verbrauch extrem hoch ist im Vergleich zu einem AMD kommt der spruch von Intel und von Fans " Ja wer Leistung will verbraucht halt ein Paar Watt mehr

War bei Bulldozer schon so und auch bei Grakas gibts das jedes mal. Wenn eine schneller als die andere ist, aber nur mit wesentlich höherer Leistungsaufnahme, wird das von Fans einfach mal als "doch nicht so wichtig" deklariert. Ist halt jedesmal die gleiche heuchelei. Aber wehe das neue Auto mit 50PS mehr säuft 8 Liter mehr auf 100km. Dann denkt man schon drüber nach ;-)

 

[ZeroStrat]

Bevor jetzt der "Intel schlägt AMD in MT Szenarien mit ein paar Little Cores" Hype ausbricht, sollte man bedenken, dass ein Cinebench Run mit voll ausgeschöpftem PL2 nicht unbedingt der Realität entspricht. Rendervorgänge laufen in der Regel länger als 56 Sekunden. Fällt der 12900K auf PL1=125W zurück, konkurriert dieser eher mit dem 5900X. Die ST Leistung ist davon natürlich nicht betroffen. Hier wird Intel, so wie es scheint, wieder deutlich vorne liegen.

Die Gaming Leistung steht allerdings auf einem ganzen anderen Blatt. Das kann man von ein paar Renderbenchmarks keinesfalls ableiten. Ich bin sehr gespannt, wie sich die erste Gen DDR5 bei der Latenz schlägt. Ich sehe das eher pessimistisch, wenn ich ehrlich bin. AMD wird mit einer 3D Cache Variante leichtes Spiel haben, Alder Lake in Gaming Workloads zu schlagen. Was anderes würde mich stark wundern. Allerdings sind die Caches ja deutlich gewachsen, so dass schlechte RAM Latenzen einigermaßen kompensiert werden können. Kompensation klingt eher nach Seitwärtsbewegung, wäre also leider nicht der deutliche Schritt nach vorne...

 

[DJMadMax]

Gemessen an den von CB ermittelten Daten wären das:

Ryzen 5950X (CB)
10435 Multithread
649 Singlethread

Intel 12900KS (QS, Twitter)

11600 Multithread
810 Singlethread

Die Singlethread-Performance würde demnach 25% über dem derzeit schnellsten Consumer-Prozessor der Welt liegen. 25% Zuwachs im Singlethread? Da bin ich aber mal mehr als gespannt.

Der Multithread-Zuwachs gegenüber dem Desktop-Flaggschiff (nicht HEDT) von AMD würde immerhin bei 11% liegen, was schon glaubwürdiger, aber dennoch unerwartet scheint.

Und wie bereits in vielen Beiträgen zuvor erwähnt wurde:
all das bedeutet relativ wenig, wenn dafür ein prozentual höherer Strombedarf von Nöten ist. 25% Leistungszuwachs bei z.B. 30% mehr Strombedarf ist und bleibt ein technischer Rückschritt.

 

[Laphonso]

17 Seiten zu GERÜCHTEN. 🤣

Man merkt, wir alle haben Sommerloch

Bin zumindest gespannt auf die ersten, belastbaren, Infos und Werte.

 

[Shoryuken94]

Wenn eine schneller als die andere ist, aber nur mit wesentlich höherer Leistungsaufnahme, wird das von Fans einfach mal als "doch nicht so wichtig" deklariert. Ist halt jedesmal die gleiche heuchelei. Aber wehe das neue Auto mit 50PS mehr säuft 8 Liter mehr auf 100km.

Und in Realität gibt es mehr als genug Leute, denen der Stromverbrauch der CPU / GPU relativ egal ist. Ist bei mir zumindest so. Für mich muss die Leistung und das Featureset stimmen. Verbrauch ist eher zweitrangig. Ganz egal von welcher Firma. Ich hatte diverse "Stromfresse".... Fermi, Sandy Bridge-E, Big Kepler, Vega, Threadripper... Mir ist aber auch ziemlich egal, ob ich 10 oder 11 Liter verbrauche.

Zum Thema:
Ob Alder Lake wirklich mithalten kann muss sich erst zeigen. Aber es geht zumindest in eine gute Richtung, wenn die Werte stimmen. Denn dann dürfte die IPC der Kerne wirklich ziemlich ordentlich sein. 8 wirklich schnelle Kerne finde ich interessanter als die Tatsache, dass man angeblich den 5950x schlagen kann. Wird aber am Ende auch auf den Preis ankommen.

 

[ZeroStrat]

Mir ist aber auch ziemlich egal, ob ich 10 oder 11 Liter verbrauche.

Ich hab gerne ein effizientes Auto im Alltag, das ich bei Bedarf auch mal richtig treten kann. ^^

 

[Kloin]

Und in Realität gibt es mehr als genug Leute, denen der Stromverbrauch der CPU / GPU relativ egal ist. Ist bei mir zumindest so. Für mich muss die Leistung und das Featureset stimmen. Verbrauch ist eher zweitrangig. Ganz egal von welcher Firma. Ich hatte diverse "Stromfresse".... Fermi, Sandy Bridge-E, Big Kepler, Vega, Threadripper... Mir ist aber auch ziemlich egal, ob ich 10 oder 11 Liter verbrauche.

Der Verbrauch kann einem ja egal sein, jeder soll das kaufen was er für richtig hält. In einem Techtest erwarte ich allerdings, dass so ein Teil abgestraft wird im Rating wenn es eine ineffiziente Architektur verwendet und säuft wie ein Loch und zwar ohne Diskussion.

 

[k0n]

Wenn man P1 mit den 105 Watt TDP des 5950X vergleicht, so ist die Mehrleistung auf Kosten des Verbrauchs gestiegen.
Ca. 19 Prozent mehr Verbrauch (105 zu 125), dafür 8,3 Prozent mehr Leistung (11.300 zu 10.435).

Ja, wenn man Intels ''P1'' mit AMD's ''TDP'' vergleicht. Aber 105W TDP bedeutet bei AMD (Ryzen 3000/5000) bis zu 142W...

 

[.Sentinel.]

Und um das im Fall von IPC zu tun muss man eben einen gemeinsamen Nenner finden und der ist es tatsächlich, alle CPUs auf 3 oder 4ghz zu nageln und einen CB Single Thread Run zu starten.

Korrekt, wobei Du dann auch nur die IPC in dieser speziellen Applikation erhältst. Die wird ja auch nach Art der Rechenoperation variieren.

 

[DevPandi]

Es geht nicht nur darum, dass es kompiliert, sondern auch darum dass es wie erwartet läuft und interoperabel ist.

Ich hab jetzt doch etwas überlegt, ob ich auf das eingehe, was du schreibst, weil es grundlegend ja nicht falsch ist, aber zu weite teilen sehr ungenau und ich wichtige Aspekte bereits genannt habe, die hier wichtig sind.

Im großen und ganzen bleibt die Antwort daher hier auch gleich: Solange man in seinen Programen plattformspezifischen µArch-Code vermeidet - also das was wir auch gerne mal als Assembler bezeichnen - ist es heute kein Problem ein Programm nur mithilfe des Compilers auf verschiedenen µArchs zum laufen zun bringen. Ich habe es bereits oft genug gemacht.

Dafür entscheidend ist es auch, dass das Betriebssystem - die mit ihrer API heute weit mehr einfluss auf die Portabilität von Software haben als die µArch - entsprechend saubere APIs anbietet und auch weite Felder abdeckt. Apple macht das mit Cocoa und den weitere Frameworks, so dass man eben keinen plattformspezifischen Code braucht.

Adobe hatte im übrigen unter Mac OS X auch bereits 2006 - 2010 Probleme mit der Umstellung von PowerPC auf x86, weil Adobe Carbon damals verwendete und auch noch recht viel plattformspezifischen Code nutze. Das es jetzt so schnell ging, hat aber auch damit zutun, dass sie in der Zeit 2006 - 2010 den MacOS-Code auf Cocoa umgesetzt haben.

Manche Programme nutzen als "Dateiformat" etwa nur eine Art Speicherdump, den sie wieder einlesen (z.B. Microsoft Office hat das früher so gemacht).

Ja und Nein. Office hat als Dateiformat früher keine art Speicherdump verwendet, sondern ein binäres Format. In den Anfangstagen von Office kam es da gerne zu Problemen, weil man sich in den Programmen um gewisse Sachen einfach nicht gekümmert hat im Format, so hat man einfach die Bytereihenfolge genommen, die der Prozessor geliefert hat - Big- und Little-Endian-Problem. Genau so kam es dazu, dass man Speicheradresse mitgenommen hat usw.

Aber auch hier gilt heute: Solange man µArch vollständig vermeidet und sich auf die APIs und Bibliothekn verlässt, dann hat man diese Probleme nicht und kann sein eigenes Programm sehr wohl ohne hohen Aufwand zwischen den µArch hin und her schieben.

Und auch wenn man Formate definiert heute, dann legt man die Byte-Reihenfolge heute für das Format als ganzes fest und entwickelt einen entsprechenden Writer und Reader, dann das Format entsprechend der Definition speichert und beim Lesen passend umwandelt, so dass man als Entwickler komfortabel damit arbeiten kann.

Ansonsten: Big- und Little-Endian können heute die Compiler selbstständig passend wählen, so dass man als Entwickler sich in seinem Programm entscheiden kann, was man verwendet.

Die von mir gemachten Hinweise zum Codeaufbau gelten also weiterhin.

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.

Das Problem hast du bereits oben in gewisser Form angesprochen und daher wiederholst du dich. Aber auch hier gilt: Vermeidet man in seinem Code µArch spezifische Teile, kann ein moderner Compiler diese Anpassungen selbst vornehmen. Ansonsten gilt auch hier wieder, dass die Betriebssystems APIs in der Regel diese Arbeit übernehmen, so dass man als Entwickler nichts mitbekommt.

Da aber x86, RISC-V und ARM mit Little-Endian arbeiten, sind die Probleme ohnehin eher theoretischer Natur und für die meisten Entwickler irrelevant.

Probleme könnten hier höchstens noch entstehen, wenn man meint mit µArch-Adressen im Code zu arbeiten, solche Sachen sollte man dann immer in eine passende Funktion/Klasse/Subroutine auslagern, damit man solche Anpassunge nur an einer Stelle vornehmen muss.

Noch schwieriger wird es, wenn Berechnungen mit Gleitkommazahlen reproduzierbar bleiben sollen.

Ach, wird es das? Nun, dafür gibt es den Standard IEEE 754-2008 und fast alle heutigen CPUs laufen mit diesem Standard. Da wird alles vom Datenformat bishin zu den notwendigen Rundungen bei der Berechnung definiert.

Auch hier gilt im übrigen bereits erneut: Es gibt genug Bibliotheken und auch Frameworks, die sich genau um solche Sachen kümmern, damit das eigene Programm protabel bleibt.

Garantiert es denn auf allen Plattformen auch das exakt gleiche Ergebnis? Ich denke nicht, aber lasse mich gerne eines Besseren belehren.

Apple wird sich etwas dabei gedacht haben, dass sie das entsprechende Framework für Vektorisierung entwickelt haben. Bei den ganze INT/WORD-Formate sind die ergebnisse auch auf IA32 und Aarch32/64 gleich.

Bei Gleitkommazahlen sieht das alleine schon Systembedingt anders aus und das solltest du wissen, wenn du es hier versucht anzusprechen. Natürlich hat sowohl IEEE 754 sowie IEEE 854 entsprechende Regeln auch definiert - an die sich auch heute die meisten Prozessoren halten, egal ob nun aarch, IA32 oder NVIDIA und AMD mit ihren Grafikkarten.

Aber alleine das Zahlenformat bedingt schon, dass man hier mit gewissen Ungenaugikeiten leben muss und entsprechend gibt es auch Empfehlungen, dass man mit Deltas arbeiten soll, die den Grad der Ungenauigkeit definiere soll, mit der man leben kann.

Wenn du aber zu den gehörst, die bei Gleitkommaberechnungen erwarten, dass a == b ist, wirst du in der Regel selbst auf der selben Plattform enttäuscht werden. Ich hab es schon oft genug erlebt - auch auf IA32 - dass eine ansich gleiche Berechnung am Ende minmal sich unterschieden hat, weil die Zahl zwar als reelle Zahl gleich waren - Anzeige - aber intern ein minimaler Unterschied herrschte. 0.1 ist eben nicht 0.1 bei Gleitkommazahlen.

Das Problem ist, dass beides nicht mehr zusammen läuft.

Das ist mir schon klar, aber danke für eine unnötige Erklärung.

Das alles ändert aber nichts an meiner Aussage, dass das Problem nicht das Programm ist, sondern das Plugin und dieses Problem relativ ist. Sofern man das Programm sowie die Plugins passend programmiet unter gewissen Gesichtspunkten - die ich jetzt nicht noch mal wiederholen würde - würde in der Regel einfach ein erneutes kompilieren reichen.

Das Problem hier ein anders, mit dem auch Apple zukämpfen hat und dass heißt: So manche Plugins sind sehr alt und wurden damals nur - bei Apple damals PowerPC, davor 68k - und bei MS eben x86 geschriebe und zwar oft mit sehr plattformspezifischen Code - die Gründe warum wieso weshalb hab ich auch ausgeführt - und man möchte diese Plugins mitnehmen - besser so manche Firmen. Da die Entwickler dieser Plugins aber heute oft nicht mehr existieren, kann man sie auch nicht einfach anpassen.

Und dieses Problem ist groß genug, dass Microsoft es zum ausdrücklichen Designziel von ARM64EC erklärt hat, diesen Fall zu unterstützen.

Und auch hier: Eine absolut unnötige Erklärung, die auch nichts an meinen Ausführungen ändert. Die Probleme hier liegen auf einer anderen Ebene und haben teilweise auch andere Gründe, aber auch die hab ich alle bereits einmal erläutert und jetzt auch.

Auf der einen Seite trivalisierst du Probleme der Umwandlung, auf der anderen Seite werde dramatisierst du diese Probleme und versuchst Probleme herbeizureden, die so nicht existieren oder die allgemein - also kein µArch-Problem - ein Problem sind, weil sie mit dem Datenformat zusammenhängt.

 

[Tinpoint]

Also nur die Singe Core 800P sind getestet die Multi hochgerechnet?
Dann stimmt da doch was nicht!

Pi mal Daumen Milchmädchenrechnung
5,3GHz =800P nur 2Kerne =>1600
5GHz =755P-> 6Kerne ->4530

Summe 6128

Jetzt kommt die Annahme das die kleinen Kerne die gleiche Leistung pro Takt erbringen wie die Großen

3,9Ghz = 589P x4=2354
3,7GHz x4=2234

Summe insgesamt 10718P und die Rechnung ist ja auch noch Falsch, da bei volle auslastung ja nicht mal der max takt erreicht wird XD sondern nur der max All Core takt oder wird da wieder all Core Turbo Blödsinn eingeschaltet wäre OC

Korrigiert mich wenn ich Falsch liege bei der Milchmädchen Rechnung, hatte meinen Kaffee noch nicht

Aber das ganze riecht nach Blödsinn

 

[Shoryuken94]

Ich hab gerne ein effizientes Auto im Alltag, das ich bei Bedarf auch mal richtig treten kann. ^^

Mag ich auch sehr gerne. Ich kann meinen Wagen mit 6,X Litern fahren, aber auch mit 15+. Der absolute verbrauch sagt wenig aus. Zumal alle Verbrenner unter sehr hoher Last extrem ineffizient werden. Nicht falsch verstehen. ich bin ein großer Fan von effizienz, aber das ganze hat nichts mit dem Maximalverbrauch zu tun

In einem Techtest erwarte ich allerdings, dass so ein Teil abgestraft wird im Rating wenn es eine ineffiziente Architektur verwendet und säuft wie ein Loch und zwar ohne Diskussion.

Auch hier noch mal der Hinweis. Effizienz ist nicht Verbrauch. Das ist definitiv ein Thema was in die Wertung einfließen sollte und der Kunde kann dann am ende entscheiden, ob es für Ihn ein Faktor beim kauf ist.

Von einem guten Test erwarte ich mir neben den Standardsettings, maximaler Leistung aber auch ein auf Effizienz getrimmten Test. Je nach Settings ändert sich das Blatt manchmal schnell. Daher kann man eine Architektur auch nur in einem breiten Test wirklich beurteilen. Aber meine Prognose, in 10nm wird Intel auch weiterhin nicht an die Effizienz von AMD in 7nm rankommen. Sollten die geleakten 170 Watt von Zen4 stimmen, wird es ab nächstem Jahr aber sehr spannend.

 

[Krautmaster]

hört sich ganz gut an, gerade für nur 8 kleine Kerne. Ich hätte davon lieber 32 kleine und 8 große damit auch was bei rumkommt.

 

[k0n]

was alle hier wieder vom verbrauch rumheulen xD

wer so eine cpu kauft für den spielt der verbrauch keine bzw eine sehr untergeordnete rolle (mich eingeschloßen)

Jetzt mach nicht jetzt schon den 12900K schlecht oder Leute die daran interessiert sein könnten xD

Es geht hier um die Effizienz. Wenn ich 5% mehr Leistung habe bei fast doppeltem Verbrauch dann komme ich zumindest mir dämlich vor. Beim i9-9900K gab es glaube ich auch das Szenario dass er 3700X gleich auf war sobald man beim Spielen nebenher streamt... Das heißt wenn der 8 Kerner beim Spielen auf allen 8 Kernen wirklich beansprucht wird, dann bricht die Spieleleistung ein. Als Quad-Core für ältere Titel ist er aber super... Ich meine man sieht mit Alder Lake eine Schlussfolgerung darauß. Nämlich nicht mehr als 8 große Kerne.

 

[Wishbringer]

Ja, wenn man Intels ''P1'' mit AMD's ''TDP'' vergleicht. Aber 105W TDP bedeutet bei AMD (Ryzen 3000/5000) bis zu 142W...

Du hast es selbst geschrieben: bis zu 142 Watt.
Diese 142 Watt sind die PPT (max. elektrische Leistung)
Und die würde ich wieder mit PL2 (maximal erlaubte Leistungsaufnahme) bei Intel gleichsetzen, die dort 228 Watt ist.

 

[kingphiltheill]

Und ich nie im Leben AMD

Das steht dir auch völlig frei.
Man muss allerdings auch anerkennen, dass ohne AMDs Leistungen Intel heute einen 11900k für 800€ mit 4 Kernen und HT verkaufen würde. Einfach weil sie es könnten.

Ergänzung (21. Juli 2021)

Und dann trotzdem den i7 - 4790K gekauft? Als die Verarsche lief und AMD am Boden lag..?

Gegenfrage: Was hätte man denn vor 8 Jahren stattdessen kaufen sollen wenn man spielen wollte?

Ich sehe das so: Ich beschäftige jemanden viele Jahre vertrauensvoll. Irgendwann stellt sich heraus, dass dieser jemand mich jahrelang belogen hat. Ich beende das gemeinssame Verhältnis und sehe mich nach einem neuen Mitarbeiter um.
Was ich garantiert nicht tun werde: Den Lügner nach 3 Jahren wieder einstellen weil er gelobt sich zu bessern.

Ich spare aktuell noch etwas auf ein AMD-System.

 

[Taxxor]

Du hast es selbst geschrieben: bis zu 142 Watt.
Diese 142 Watt sind die PPT (max. elektrische Leistung)
Und die würde ich wieder mit PL2 (maximal erlaubte Leistungsaufnahme) bei Intel gleichsetzen, die dort 228 Watt ist.

Nein da PL2 nur eine kurze Zeit Anliegen darf und dann auf PL1 gedeckelt wird. TDP ist hier immer auch die Gremze für die Leistungsaufnahme.

Bei AMD hast du mit 105W TDP aber konstant 142W als Limit.


Wenn du beide CPUs ne halbe Stunde rendern lässt, braucht Intel eine Minute lang 228W und 29 Minuten lang 125W
AMD verbraucht 30 Minuten lang 142W

 

[k0n]

Diese 142 Watt sind die PPT (max. elektrische Leistung)
Und die würde ich wieder mit PL2 (maximal erlaubte Leistungsaufnahme) bei Intel gleichsetzen, die dort 228 Watt ist.

Kannst du so machen, wenn du mit einem Intel vergleichst der 24/7 im PL2 ist. Das bedeutet nämlich PPT bei AMD.

@kingphiltheill ...bei mir blieb es bei einem Ivy Bridge oder Sandy Bridge i3. Und dann hatte ich bis Ryzen das Interesse verloren. Hätte es damals die Boards (mini-ITX) dazu gegeben hätte ich mir vielleicht sogar den Bulldozer angetan... xD

 

[blubberbirne]

Leistung hin oder her. Wenn die CPU nicht in 5 bzw. 7nm gefertigt wird, ist es ein Fail in meinen Augen.
Eine Technologisch Hervorrangende CPU in einen steinzeitlichen Fertigungsverfahren

 

[R2D2]

Abwarten und tee trinken und warum soll intel nicht amd überholen.zum zocken braucht die eh kein mensch steht dann 30 prozent cpu auslastung.