Alder Lake (7 nm, big.LITTLE, 8C + 8c "Golden Cove"/"Gracemont" CPU-Kerne, Ende 2021)

[Loeschzwerg]

Per Definition etwas zu schwammig. Den PPro gibt es als Variante mit einem oder zwei SRAM (512KB oder 1MB) und das Design hat man von Anfang an darauf ausgerichtet.

Chiplet ist für mich auch ein Modewort, denn wenn du es auf Funktionsblöcke herunterbrichst, dann passt das wunderbar auf alte ECL Mainframes mit den unterschiedlichen Trägervarianten. Spitzfindigkeiten ^^

[BlacKi]

hat sich amd das wort "chiplet design" markenrechtlich schützen lassen?^^

nehalem hat auch mehr als ein die unter dem heatspreader. but its the gpu.

es hat aber wohl seinen grund warum man nun selbst die gpu monolithisch integriert. vermutlich weil die kosten einfach zu teuer sind. jetzt davon abzuleiten, intel muss es wegen amd auch wieder tun, fällt mir deshalb etwas schwer nachzuvollziehen.

[robbitop]

Power 8 ist ein Chiplet Design mit 6 bzw. 12 Chiplets. Vorher hat man eher on package edram verwendet und das auch nicht chiplets genannt.
Sonst wäre noch die CEA Leti Tarslet Architektur von ST Mirco erwähnenswert.
Davor war das noch kein bekanntes Konzept und es hat auch keiner das Wort "Chiplet" in den Mund genommen wenn irgendwie mehrere Dies auf ein Package vereint wurden.



Edram oder Cache auf das package zu packen ist keine Chiplet strategie.

Lynnfield, Kabylake-G, Lakefield etc. sind alles keine Chiplet Designs, denn ihnen fehlt Reusable IP, bzw. mehrere identische DIEs.

A chiplet is an integrated circuit block that has been specifically designed to work with other similar chiplets to form larger more complex chips.
In such chips, a system is subdivided into functional circuit blocks, called "chiplets", that are often made of reusable IP blocks.
https://en.wikichip.org/wiki/chiplet

Darüber hinaus sind Chiplets eine Designstrategie zur Yieldverbesserung.
Das ist ein ganz anderer Grund als vorgangene Strategien wo man MCMc verwendet hat um SOCs zu kreieren, kleinere packages für mobile zu bauen oder eine GPU oder edram zu integrieren.

Für AMD ist Zen1 auch keine Chiplet Strategie, da das Design aus anderen Strategischen gründen (masken kosten, validation, Risikomanagement etc.) aus mehreren Chips zusammengebaut ist. Außerdem sind die Zen1 Einzel-DIEs für ihre Zeit und Node verhältnismäßig groß. Chiplet Strategie bezieht sich aber konkret auf sehr kleine, einfach zu validierende kleine DIEs die in großer Zahl parallel auf einem Package zusammengefügt werden können.

Die Herangehensweise in der Entwicklung ist eben eine ganz andere: a system is subdivided into functional circuit blocks
Bei Chiplets designt man zuerst das Gesamtsystem, nämlich Epyc mit 64Cores und teilt das dann in Building Blocks auf aus denen man auch andere Konfigurationen bauen kann. Bei Zen1 oder Core2 wurden zuerst separate in sich funktionierende Systeme definiert und dann mehrere davon aneinandergereiht. Das ist ein Paradigmenwechsel in der Entwicklung bzw. auch dem Projektmanagement.

Intels erstes echtes Produkt mit Chiplet-Strategie ist Ponte Vecchio bzw. Sapphire Rapids je nachdem was zuerst kommt.

Sapphire Rapids ist imo auch ein Chiplet Design, selbst wenn die Chiplets ziemlich groß werden und kein i/o die wie bei Zen2/3 verwendet wird. SR verwendet aber 4x identische Dies um mit den Yields von 10SF klar zu kommen und wurde imo auch von Anfang an als 4chip komplex geplant. Man hat sich mit EMMIB/Foveros auch einiges zur schnelleren Verbindung der Chips ausgedacht. Das ist was anderes als einfach zwei oder vier Dies auf ein MCM-Package zu packen, was leistungsmäßig ja identisch zu einem dual oder quad socket system performen würde.




on package SRAM ist kein Chiplet Design.



BTW, der 5800x ist streng genommen auch keine Chiplet CPU. Man kann sich aber drüber streiten ob er ein "chiplet" enthält, da der 8-Core CCD identisch mit den Chiplets in Epycs und dem 5950X ist und damit die single CCD CPUs also ganz klar Teil der gesamten Chipletstrategie sind.
Die Frage ist, ob Namen nicht Schall und Rauch sind und wie viel "Authorität" diese Definition auf Wikipedia hat. Es ist ja vieles evolutionär. Welche Schwelle am Ende entscheident dafür ist, damit es als "chiplets" gilt, erscheint mir hier ein wenig arbiträr.

Grundsätzlich waren die wesentlichen Komponenten dafür schon lange vorher in Serienprodukten vorhanden. Dass man bspw nun mehrere gleiche Chips verbinden muss, damit es gilt, erscheint mir keine wesentliche technische Änderung zu sein, damit es dann als "chiplet" gilt.

Am Ende spielt das auch keine große Rolle sondern vor allem, wie man diese Kombination nutzen kann, um Kosten zu senken.
Die Mischung von 45 nm für IGP+IMC bei Arrandale und 32 nm für die CPU erscheint mir da schon die wesentlichen Komponenten zu beinhalten.
Auch der eDRAM core der X360 tut das. Er nutzt einen spezifischen, günstigeren Produktionsprozess um eDRAM zu ermöglichen UND er die ROPs der GPU und die Compression/Decompression und das I/O Interface sind dort enthalten. Es ist nicht nur "dummer" Memory.

Will damit sagen: die wesentlichen Elemente sind alles andere als neu. Ob es jetzt für die Wikipedia Definition reicht oder nicht -> ist das wichtig?

@Blacki und Loeschzwerg
this

[MiamiNice]

Intel selbst hat das Schlagwort "glued together" (https://www.computerbase.de/2018-10/intel-amd-cpu/) fürs Marketing erfunden, hör auf das auf die Fanboys abzuwälzen. Das war zu 100% Intel selbst.


Ich nehme alles zurück und behauptet frech das Gegenteil.
Da bin ich buff - kannte ich nicht.

Danke :)

[BlacKi]

raptorlake kommt nach alderlake mit einem neuen gaming cache^^ scheint wohl nur ein refresh mit extra cache zu sein. denn die coves und monts bleiben wohl gleich. das wären dann 3 generationen auf einem sockel.
https://cdn.videocardz.com/1/2021/03/Intel-Raptor-Lake-VideoCardz.jpg

[davidzo]

Dass Broadwell schneller als SKL sein soll in Games: hast du dafür Zahlen? Oder meinst du Broadwell mit zusätzlichem eDRAM? Das wäre kein geeigneter Vergleich.


Du bist vielleicht ein Witzbold, Broadwell im Desktop gab es nur mit EDRAM :freak:

Im übrigen habe ich nicht gesagt dass Broadwell schneller ist, sondern dass Broadwell eine höhere IPC in gaming hat. Das ist was anderes, da es von Skylake eben weit höher taktende Modelle gab, was über die schwache IPC hinweg täuscht. FIVR hat Broadwell ausgebremst, was zwar bei den meisten Betriebspunkten bessere Energieeffizienz ermöglicht hat, aber eben auch weniger Takt in der Spitze. Haswell hatte zwar auch FIVR, aber 22nm war da robuster, weshalb Haswell taktmäßig noch mit Skylake konurrieren konnte. Der 4790K war auch nach dem 6700K Launch die schnellste Gaming CPU.


Skylake legte mit schnellem DDR4 nochmal richtig zu, da mit den anfangs lahmen DDR4-2133 Modulen die Memorylatency gut 15% langsamer war als auf den ganz gut getimten DDR3-1600 und sogar 2400.

Deshalb hat Anandtech ja ebenfalls mit schnellem DDR3 getestet und da sieht man dass die gaming IPC von Broadwell, ja sogar Haswell minimal höher ist als die von Skylake.
https://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/10



Grundsätzlich waren die wesentlichen Komponenten dafür schon lange vorher in Serienprodukten vorhanden. Dass man bspw nun mehrere gleiche Chips verbinden muss, damit es gilt, erscheint mir keine wesentliche technische Änderung zu sein, damit es dann als "chiplet" gilt.

Am Ende spielt das auch keine große Rolle sondern vor allem, wie man diese Kombination nutzen kann, um Kosten zu senken.
Die Mischung von 45 nm für IGP+IMC bei Arrandale und 32 nm für die CPU erscheint mir da schon die wesentlichen Komponenten zu beinhalten.
Auch der eDRAM core der X360 tut das. Er nutzt einen spezifischen, günstigeren Produktionsprozess um eDRAM zu ermöglichen UND er die ROPs der GPU und die Compression/Decompression und das I/O Interface sind dort enthalten. Es ist nicht nur "dummer" Memory.

Will damit sagen: die wesentlichen Elemente sind alles andere als neu. Ob es jetzt für die Wikipedia Definition reicht oder nicht -> ist das wichtig?


:facepalm:

Du kapierst es noch immer nicht. Das ist ein ganz anderer Entwicklungsansatz ob ich jetzt a la Arrandale oder Lakefield sage "wir nehmen für eDRAM und i/o DIE einen günstigeren oder optimaleren Prozess und stacken dass" oder ob ich sage "wir wollen ein system mit 40Mrd Transistoren bauen, das würde 2 Jahre Design und 4 Jahre Validation brauchen. Lass uns gucken wie wir das in möglichst viele gleiche Blöcke aufteilen können um nicht über 10Mrd pro Chip heraus zu kommen, was die Validation auf 1/4, also 1 Jahr verkürzt und Masken vereinfacht und den yield verbessert".
Du verwechselst hier MCM aus heterogenen Node Chips mit Chiplets. Chiplet design hat nichts mit heterogenen Fertigungsprozessen zutun, es ist eher Zufall dass Epyc eben beides verwendet.

Und ja, "Chiplet Design" ist keine einzelne technische Errungenschaft die sich z.B. patentieren lässt, sondern ein theoretisches Konzept beim Chipdesign und Fertigung. Damit ist es völlig unabhängig von den peckaging Technologien die du da auflistest. Chiplet kann ich per MCM realisieren, per 2.5D Cowos, per EMIB, etc. - Trotzdem ist nicht alles Chiplet was irgendein dieser Technologien benutzt.

[MiamiNice]

Du machst mir in Sachen Unfreundlichkeit manchmal harte Konkurrenz :tongue:

raptorlake kommt nach alderlake mit einem neuen gaming cache^^ scheint wohl nur ein refresh mit extra cache zu sein. denn die coves und monts bleiben wohl gleich. das wären dann 3 generationen auf einem sockel.
https://cdn.videocardz.com/1/2021/03/Intel-Raptor-Lake-VideoCardz.jpg

Klingt erst mal sexy, like Broadwell. Da bin ich gespannt.

[Loeschzwerg]

Der Entwicklungsansatz ist eigentlich der gleiche, nur das Ziel bzw. die Vorgaben sind anders. Der grobe Vorgang hat sich eigentlich nicht verändert zur Vergangenheit und die vorhandene Technik (Edit: und natürlich auch das vorhandene Budget) definiert wie immer die Rahmenbedingungen. Business as usual ^^

Versteift euch da nicht so blöd auf Namen. Ist wie mit Industrie 4.0 und Co....

[Birdman]

Das ist ein ganz anderer Entwicklungsansatz ob ich jetzt a la Arrandale oder Lakefield sage "wir nehmen für eDRAM und i/o DIE einen günstigeren oder optimaleren Prozess und stacken dass" oder ob ich sage "wir wollen ein system mit 40Mrd Transistoren bauen, das würde 2 Jahre Design und 4 Jahre Validation brauchen. Lass uns gucken wie wir das in möglichst viele gleiche Blöcke aufteilen können
Du versteifst dich aber auch gar sehr auf diese "gleiche und multiple Blöcke"...
Demzufolge basieren ein 5600X oder 5800X also nicht auf einem Chiplet Design?

[HOT]

raptorlake kommt nach alderlake mit einem neuen gaming cache^^ scheint wohl nur ein refresh mit extra cache zu sein. denn die coves und monts bleiben wohl gleich. das wären dann 3 generationen auf einem sockel.
https://cdn.videocardz.com/1/2021/03/Intel-Raptor-Lake-VideoCardz.jpg
Ist natürlich Quatsch, MTL bekommt natürlich einen neuen Sockel. Da hat man sich ja selbst bei dieser Generation strikt dran gehalten, obwohl das eigentlich blödsinnig war für CPUs, die das Featureset überhaupt nicht bieten :freak:.
Intel wird jetzt jedes Jahr direkt zum Jahreswechsel einen neuen S-Chip raushauen. Die Plattformen werden trotzdem alle 2 Generationen gewechselt.

21/22 -> ADL
22/23 -> RTL
23/24 -> MTL
24/25 -> LNL

Da braucht man doch kein Prophet für zu sein, um den Plan dahinter zu erkennen.

Für AMD ist das ja auch sehr berechenbar:

5.5.22 -> Zen4
5Q später wäre Q3/4 2022 für Zen5

[robbitop]

Du bist vielleicht ein Witzbold, Broadwell im Desktop gab es nur mit EDRAM :freak:
Da hast du Recht. Dennoch bleibt das Argument, dass der eDRAM den Vergleich verzerrt, valide.

Im übrigen habe ich nicht gesagt dass Broadwell schneller ist, sondern dass Broadwell eine höhere IPC in gaming hat. Das ist was anderes, da es von Skylake eben weit höher taktende Modelle gab, was über die schwache IPC hinweg täuscht.
Wobei Broadwell durch den eDRAM verfälscht wird. Latency ist unglaublich wichtig für Spiele. Wenn man schon uArchs miteinander vergleicht, dann sollte schon Waffengleichheit herrschen. Idealerweile, sofern nichts dagegen spricht auch mit gleicher Memorylatency.


FIVR hat Broadwell ausgebremst, was zwar bei den meisten Betriebspunkten bessere Energieeffizienz ermöglicht hat, aber eben auch weniger Takt in der Spitze. Haswell hatte zwar auch FIVR, aber 22nm war da robuster, weshalb Haswell taktmäßig noch mit Skylake konurrieren konnte.
Gibt es dazu Quellen, dass es an FIVR lag? Das ist mir neu - was nicht heißen soll, dass ich das bezweifle. Ich wüßte nur gern, ob es dazu konkrete Aussagen gibt, die das korrelieren. IIRC/ mein bisheriger Kenntnisstand ist, dass 14 nm zu Broadwell einfach noch nicht auf dem Level wie 22 nm war was Performance angeht.

Der 4790K war auch nach dem 6700K Launch die schnellste Gaming CPU.


Deshalb hat Anandtech ja ebenfalls mit schnellem DDR3 getestet und da sieht man dass die gaming IPC von Broadwell, ja sogar Haswell minimal höher ist als die von Skylake.
https://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/10

Weiß nicht - irgendwas stimmt mit dem Test bei Anandtech nicht:

1. Skylake zeigt hohe Memorylatency bei gleichem DDR3 Takt - ggf ist der -> siehe Latencyladder hier: https://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/9
Das sind über 10% Latenznachteil bei DDR3. Bei DDR4 sieht es sogar noch schlimmer aus.
Ich weiß aus genug Messungen, dass Skylake durchaus in der Lage ist mit anständigem RAM deutlich unter die Gesamtmemorylatency von Haswell kommen kann.
Mein 4790K bekomme ich mit feinstem DDR3 und Subtiming Tuning auf 45 ns. Ich habe schon Screenshots im Netz gefunden auf 40-42 ns. Bei Skylake erreicht man die 36-40 ns.

Letztenendes wird es zum Lebensanfang vom 6700K wahrscheinlich in der Praxis so gewesen sein, dass er mit der schlechteren Gesamtlatenz leben musste, weil guter DDR4 mit >3200 MHz und CL14/15 ja erst später gut verfügbar und bezahlbar wurde. Aber IMO ist es schon interessant, beide uArchs bei Waffengleichheit zu bewerten. Also den Flaschenhals Memorylatency auf ein gleiches Niveau zu bringen. Bei den Zahlen, die ich bei Anand in der Latencyladder sehe, muss der Skylake Kern eben länger warten als der Haswell Kern, bis er Daten bekommt.

2. Die Spiele Benchmarks mit discrete GPU sehen aus als würden diese häufig nicht im CPU Limit laufen. Der 4770 scheint dort, wo es wenigstens ein Teil CPU Limit gibt den 6700K nicht zu schlagen. Broadwell mit eDRAM liegt dank des eDRAMs vorn.



:facepalm:
Du kapierst es noch immer nicht.
Ich finde es schade, dass du aus einer sachlichen Diskussion heraus unfreundlich/überheblich reagieren musst.

Natürlich verstehe ich deinen Punkt. Es wäre schlimm, wenn ich so Zusammenhänge dieser Art nicht verstehen würde. Dann hätte ich beruflich ein ernsthaftes Problem. :D

Ich habe ganz einfach dazu eine andere Ansicht. Es wäre schön, wenn du das respektieren könntest und nicht gleich annehmen würdest, dass dein Gegenüber diese Zusammenhänge nicht versteht, sondern weiterhin sachlich und gerne auch im angemessenen "Ton" deinen Standpunkt vertrittst.


Das ist ein ganz anderer Entwicklungsansatz ob ich jetzt a la Arrandale oder Lakefield sage "wir nehmen für eDRAM und i/o DIE einen günstigeren oder optimaleren Prozess und stacken dass" oder ob ich sage "wir wollen ein system mit 40Mrd Transistoren bauen, das würde 2 Jahre Design und 4 Jahre Validation brauchen. Lass uns gucken wie wir das in möglichst viele gleiche Blöcke aufteilen können um nicht über 10Mrd pro Chip heraus zu kommen, was die Validation auf 1/4, also 1 Jahr verkürzt und Masken vereinfacht und den yield verbessert".

Bei Arrandale wäre die Alternative ein größerer monolitischer SoC gewesen. So konnte man GPU + IO und CPU separat und schneller validieren. Ist IMO ein ähnlicher Punkt. Warum müssen es dazu unbedingt gleiche Blöcke sein? Man profitiert auch davon, wenn man verschiedene Blöcke seperat validiert (und für jeden den dafür passenden Prozess nutzen kann). Je nach dem kann man diese dann sogar in mehreren Produkten kombinieren. Einmal validiert und in mehreren Produkten genutzt.

Natürlich treibt man es mit der Mehrfachverwendung mehrerer CCDs noch weiter. Ohne Frage. Man validiert den CCD 1x und verwendet ihn in mehreren Produkten wieder. Das ist nett. Und man kann auch in der Fertigung effizienter sein. Kleinere Chipsize, größere Ausbeute bei gleicher defect density. Und weniger Vielfalt desto höher die Stückzahl eines Produktes. Bessere Skaleneffekte.

Die Frage ist am Ende - und nochmal: das hat was mit meinem Standpunkt zu tun und nichts mit Verständnis - welche technische Schwelle jetzt legitimer weise überschritten werden muss, damit die IMO völlig arbiträre Definition von Wikipedia (was keine anständige Quelle sein muss) erfüllt wird.

Der Punkt ist: die Voraussetzungen dafür gab es vorher schon. Und bei IBM hat man IIRC auch Chiplets nach der Wikipedia Definition bei POWER verbaut. Vor AMD.


Du verwechselst hier MCM aus heterogenen Node Chips mit Chiplets. Chiplet design hat nichts mit heterogenen Fertigungsprozessen zutun, es ist eher Zufall dass Epyc eben beides verwendet.

Und ja, "Chiplet Design" ist keine einzelne technische Errungenschaft die sich z.B. patentieren lässt, sondern ein theoretisches Konzept beim Chipdesign und Fertigung. Damit ist es völlig unabhängig von den peckaging Technologien die du da auflistest. Chiplet kann ich per MCM realisieren, per 2.5D Cowos, per EMIB, etc. - Trotzdem ist nicht alles Chiplet was irgendein dieser Technologien benutzt.

Das ist mir alles klar. Für mich ist einfach der Punkt mit der Skalierung mehrerer gleichen Kerne arbiträr. Und ich bin mir auch nicht sicher, ob diese Wikipedia Definition wirklich auch eine wissenschaftlich anerkannte Definition ist.
Sicherlich profitiert man durch die Verwendung mehrerer gleicher Blöcke je nach Anwendung nochmal zusätzlich auf einer weiteren Ebene - aber der Effekt der Validierungseinsparung ist auch vorher schon gegeben.
Und dass dazu mehrerer dieser Module auch unbedingt auf einem Träger sein müssen finde ich noch arbiträrer. Beispielsweise wurde Chrystalwell auch nur einmal validiert und wurde mehrere Generationen genutzt. Einmal validiert und mehrfach verwendet.

Aber was sind Definitionen im Grenzbereich schon wert? IMO wenig. Namen sind Schall und Rauch.

IMO müssen wir hier auch nicht d'accord sein. Man kann ja auch unterschiedlicher Ansicht sein.

[davidzo]

Wobei Broadwell durch den eDRAM verfälscht wird. Latency ist unglaublich wichtig für Spiele. Wenn man schon uArchs miteinander vergleicht, dann sollte schon Waffengleichheit herrschen. Idealerweile, sofern nichts dagegen spricht auch mit gleicher Memorylatency.


Also edram gehört deiner Meinung nach nicht zur CPU Architektur?
Am besten noch L3 Cache, lassen wir den auch weg von der Architektur um gleiche Waffen zu schaffen :freak:



Gibt es dazu Quellen, dass es an FIVR lag? Das ist mir neu - was nicht heißen soll, dass ich das bezweifle. Ich wüßte nur gern, ob es dazu konkrete Aussagen gibt, die das korrelieren. IIRC/ mein bisheriger Kenntnisstand ist, dass 14 nm zu Broadwell einfach noch nicht auf dem Level wie 22 nm war was Performance angeht.

Das ist richtig, 14nm kam taktmäßig erstmal nicht an 22nm heran. Erst mit 14nm++ und relaxtem metal stack hat man 22nm schlagen können. Dafür hat man fast 20% an Density aufgegeben.
FIVR war einfach nicht gut für die Kühlung, da das vom TDP Budget abging. Außerdem haben ohne Fivr die mainboadhersteller mehr möglichkeiten spezielle OC boards zu bauen, während FIVR immer gleich ist.
Offizielle Aussagen gibt es zu skylake praktisch keine. Es gibt wohl keine Architektur die mit soviel Geheimniskrämerei gelauncht wurde. Hinter den Türen gab es aber wohl schon Infos dazu: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/36000-intel-streicht-fuer-skylake-und-kaby-lake-den-fully-integrated-voltage-regulator.html



Weiß nicht - irgendwas stimmt mit dem Test bei Anandtech nicht:

1. Skylake zeigt hohe Memorylatency bei gleichem DDR3 Takt - ggf ist der -> siehe Latencyladder hier: https://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/9
Das sind über 10% Latenznachteil bei DDR3. Bei DDR4 sieht es sogar noch schlimmer aus.
Ich weiß aus genug Messungen, dass Skylake durchaus in der Lage ist mit anständigem RAM deutlich unter die Gesamtmemorylatency von Haswell kommen kann.
Mein 4790K bekomme ich mit feinstem DDR3 und Subtiming Tuning auf 45 ns. Ich habe schon Screenshots im Netz gefunden auf 40-42 ns. Bei Skylake erreicht man die 36-40 ns.

Bei gleichen Taktraten? Es ging hier um die IPC, nicht darum wie weit man den RAM übertakten kann oder die CPU Cores.



Ich finde es schade, dass du aus einer sachlichen Diskussion heraus unfreundlich/überheblich reagieren musst.


Tut mir leid. War nur ein emote und nicht so gemeint :wink:


Bei Arrandale wäre die Alternative ein größerer monolitischer SoC gewesen. So konnte man GPU + IO und CPU separat und schneller validieren. Ist IMO ein ähnlicher Punkt. Warum müssen es dazu unbedingt gleiche Blöcke sein? Man profitiert auch davon, wenn man verschiedene Blöcke seperat validiert (und für jeden den dafür passenden Prozess nutzen kann). Je nach dem kann man diese dann sogar in mehreren Produkten kombinieren. Einmal validiert und in mehreren Produkten genutzt.


Natürlich treibt man es mit der Mehrfachverwendung mehrerer CCDs noch weiter. Ohne Frage. Man validiert den CCD 1x und verwendet ihn in mehreren Produkten wieder. Das ist nett. Und man kann auch in der Fertigung effizienter sein. Kleinere Chipsize, größere Ausbeute bei gleicher defect density. Und weniger Vielfalt desto höher die Stückzahl eines Produktes. Bessere Skaleneffekte.


Soweit ich weiß hat Intel bei Arrandale nie über yield optimierungen, Validierungszeiten und Reuse gesprochen. Damals ging es darum wieviel fertigungskapazitäten im cutting edge prozess vorhanden waren bzw. wie man den prozess für eine GPU tauglich machen kann. Dass CPU und GPU in einem prozess nicht immer klappt sieht man ja bei Cannonlake.



Die Frage ist am Ende - und nochmal: das hat was mit meinem Standpunkt zu tun und nichts mit Verständnis - welche technische Schwelle jetzt legitimer weise überschritten werden muss, damit die IMO völlig arbiträre Definition von Wikipedia (was keine anständige Quelle sein muss) erfüllt wird.

Klar, eine feste technische Schwelldefinition gibt es nicht, es ist ja auch keine Technologie sondern eine Strategie. Allerdings ist sich die Silicon Engineering Branche ziemlich einig wer chiplet macht und wer nicht. Du kannst die gerne mal die Talks auf der ISSCC, Hotchips, VLSI etc. dazu ansehen.
Wenn jemand nichtmal das Wort in den Mund nimmt ist es relativ unwahrscheinlich dass das von Ingenieuren als Chiplet Strategie wahrgenommen wird.


Der Punkt ist: die Voraussetzungen dafür gab es vorher schon. Und bei IBM hat man IIRC auch Chiplets nach der Wikipedia Definition bei POWER verbaut. Vor AMD.

ja hier hat auch nie jemand behauptet dass AMD erster war. du wiederholst dich, bzw. habe ich auch genau gesagt welcher IBM Power Chiplet verwendet.
AMD ist aber die erste Firma die mit einem solchen produkt "In production" ist bzw. so in der Breite das es von Massenmarkt und gaming bis zum Server und HPC Chip geht-.
Das hat auch nichts damit zutun dass Intel bisher einfach nicht nach dem Paradigma designt hat und wir deswegen unter anderem auch die gigantischen Verzögerungen bei Icelake SP sehen.
Die erste Chiplet CPU, Sapphire Rapids ist beinahe schneller fertig als sein monolitischer Vorgänger.



Das ist mir alles klar. Für mich ist einfach der Punkt mit der Skalierung mehrerer gleichen Kerne arbiträr. Und ich bin mir auch nicht sicher, ob diese Wikipedia Definition wirklich auch eine wissenschaftlich anerkannte Definition ist.


Wikichip, nicht Wikipedia. Und ja, diese Definition ist wissenschaftlicher Konsens, kannst dir ja gerne die ISSCC präse von CEA leti zu "TSARLET" reinziehen oder den auf der ISSCC 2021 von AMD.
Und ja, es gibt noch unzählige andere Spezialanwendungen in denen eine Chiplet Strategie angewndt wird: https://fuse.wikichip.org/news/tag/chiplet/

Testchips haben sie alle, auch nvidia hat ein Chiplet Forschungsdesign: https://fuse.wikichip.org/news/2456/nvidia-inference-research-chip-scales-to-dozens-of-chiplets/

[y33H@]

Broadwell gibt's auch ohne EDRAM ;-)

[robbitop]

Also edram gehört deiner Meinung nach nicht zur CPU Architektur?
Am besten noch L3 Cache, lassen wir den auch weg von der Architektur um gleiche Waffen zu schaffen :freak:
Skylake gab es auch mit Crystalwell (mobile) und Broadwell auch ohne. IMO passt das Argument nicht so 100%ig. Das war optional für beide.
Wenn man jetzt bspw über Zen 3 vs RKL spricht und man da Latenzen normieren wöllte oder Cache gleichsetzen wöllte, würde ich deinem Argument aber zustimmen.

Eines von vielen Broadwells ohne L4:
E3-1285L v4

Wenn man Lust zu suchen hat, findet man einige hier:
https://ark.intel.com/content/www/us/en/ark/products/codename/38530/broadwell.html?ui=BIG


Das ist richtig, 14nm kam taktmäßig erstmal nicht an 22nm heran. Erst mit 14nm++ und relaxtem metal stack hat man 22nm schlagen können. Dafür hat man fast 20% an Density aufgegeben.
FIVR war einfach nicht gut für die Kühlung, da das vom TDP Budget abging. Außerdem haben ohne Fivr die mainboadhersteller mehr möglichkeiten spezielle OC boards zu bauen, während FIVR immer gleich ist.
Offizielle Aussagen gibt es zu skylake praktisch keine. Es gibt wohl keine Architektur die mit soviel Geheimniskrämerei gelauncht wurde. Hinter den Türen gab es aber wohl schon Infos dazu: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/36000-intel-streicht-fuer-skylake-und-kaby-lake-den-fully-integrated-voltage-regulator.html
Ich sehe ein, dass das sicherlich keine positiven Faktoren für FIVR sind. Aber ob die für Broadwell primäre Hindernisse für den Takt waren? Schwer zu sagen.
5775-C lief doch auch mit super wenig TDP. Auch bessere Kühlung und die Freigabe von mehr TDP (da gab es IIRC einige seltene BIOSe) haben am maximalen OC Takt wenig geändert.
Naja wirklich final wissen wird man es wohl nie außerhalb Intel.


Bei gleichen Taktraten? Es ging hier um die IPC, nicht darum wie weit man den RAM übertakten kann oder die CPU Cores.
Für die IPC in Spielen ist nunmal auch die Memorylatency entscheidend. Was da mit der Memorylatency bei Anand schief gegangen ist, weiß ich nicht.
Aber ja auch bei gleichen Taktraten bekam man mindestens gleich gute Memorylatency hin AFAIK.



Soweit ich weiß hat Intel bei Arrandale nie über yield optimierungen, Validierungszeiten und Reuse gesprochen. Damals ging es darum wieviel fertigungskapazitäten im cutting edge prozess vorhanden waren bzw. wie man den prozess für eine GPU tauglich machen kann. Dass CPU und GPU in einem prozess nicht immer klappt sieht man ja bei Cannonlake.
Kann schon sein, dass die Gründe andere waren. Aber der Effekt war dennoch trotzdem sicherlich vorhanden.


Klar, eine feste technische Schwelldefinition gibt es nicht, es ist ja auch keine Technologie sondern eine Strategie. Allerdings ist sich die Silicon Engineering Branche ziemlich einig wer chiplet macht und wer nicht. Du kannst die gerne mal die Talks auf der ISSCC, Hotchips, VLSI etc. dazu ansehen.
Wenn jemand nichtmal das Wort in den Mund nimmt ist es relativ unwahrscheinlich dass das von Ingenieuren als Chiplet Strategie wahrgenommen wird.
Ja das macht so schon mehr Sinn. IMO fängt Intel seit kurzem an, diese Strategie auch für genau diese Intension zu nutzen. Auch wenn nicht immer mit mehrfacher Blockverwendung auf einem Träger (bei PV allerdings schon).
In deren Roadmap sieht es zumindest so aus.


ja hier hat auch nie jemand behauptet dass AMD erster war. du wiederholst dich, bzw. habe ich auch genau gesagt welcher IBM Power Chiplet verwendet.
AMD ist aber die erste Firma die mit einem solchen produkt "In production" ist bzw. so in der Breite das es von Massenmarkt und gaming bis zum Server und HPC Chip geht-.
Das hat auch nichts damit zutun dass Intel bisher einfach nicht nach dem Paradigma designt hat und wir deswegen unter anderem auch die gigantischen Verzögerungen bei Icelake SP sehen.
Die erste Chiplet CPU, Sapphire Rapids ist beinahe schneller fertig als sein monolitischer Vorgänger.


Damit kann ich d'accord gehen.



Wikichip, nicht Wikipedia. Und ja, diese Definition ist wissenschaftlicher Konsens, kannst dir ja gerne die ISSCC präse von CEA leti zu "TSARLET" reinziehen oder den auf der ISSCC 2021 von AMD.
Und ja, es gibt noch unzählige andere Spezialanwendungen in denen eine Chiplet Strategie angewndt wird: https://fuse.wikichip.org/news/tag/chiplet/

Testchips haben sie alle, auch nvidia hat ein Chiplet Forschungsdesign: https://fuse.wikichip.org/news/2456/nvidia-inference-research-chip-scales-to-dozens-of-chiplets/
OK das ist tatsächlich was anderes als Wikipedia. Mea culpa. Mir kommt es bei der Definition allerdings ein wenig vor, dass man damit das umschreibt und abgrenzt, was AMD als erster im so breiten Massenmarkt tut. Und alles was das nicht vollständig erfüllt ist kein Chiplet. Wenn man letzteren Schluss zieht, empfinde ich die Definition eben aus dem Grund arbiträr.

Wenn man es expliziter benannt hätte. Die "Kriterium XYZ Chipletstrategie" wäre es sicherlich etwas anderes. Aber nun weiß ich, dass damit genau das gemeint ist.

[davidzo]

OK das ist tatsächlich was anderes als Wikipedia. Mea culpa. Mir kommt es bei der Definition allerdings ein wenig vor, dass man damit das umschreibt und abgrenzt, was AMD als erster im so breiten Massenmarkt tut. Und alles was das nicht vollständig erfüllt ist kein Chiplet. Wenn man letzteren Schluss zieht, empfinde ich die Definition eben aus dem Grund arbiträr.

Wenn man es expliziter benannt hätte. Die "Kriterium XYZ Chipletstrategie" wäre es sicherlich etwas anderes. Aber nun weiß ich, dass damit genau das gemeint ist.

AMD war da eher latecomer bzw. Mitläufer. Die Grundlagen haben andere erforscht/getestet. Sowas wird üblicherweise auch immer erst spät veröffentlicht. Man will der Konkurrenz ja nicht auf die Nase binden was man gerade macht. Dementsprechend AMDs präse dazu erst auf der ISSCC2021, deutlich nach dem launch von Ryzen 3K :freak:

Ich sehe das auch nicht als Definition, aber es ist definitiv ein Trend in der Halbleiterbranche der langsam mainstream wird.
Wie bei jedem Trend gibt es viele Mitläufer, Nachahmer und auch Cargo-Cult Imitatoren. Aber wie gesagt, Intel hat sich bis vor kurzem nicht einmal dazu bekannt dass Chiplet für CPUs eine sinnvolle Strategie ist, ganz im Gegensatz zum Rest der Industrie wie nvidia, Qualcomm, Ampere, etc. die allesamt über ihre künftigen Chipletstrategien schwärmen.
Wie kann man bei einem Trend dabei sein wenn man selber nach außen noch dagegen an kämpft?
Naja, das ist eh Geschichte mit Sapphire Rapids und Ponte Vecchio.

[amdfanuwe]

AMD war da eher latecomer bzw. Mitläufer.
Ja, war schon dumm von AMD bereits Anfang 2017 die Konkurrenz darauf aufmerksam zu machen, dass sie mit Chiplets experimentieren:
http://www.computermachines.org/joe/publications/pdfs/hpca2017_exascale_apu.pdf

https://www.heise.de/newsticker/meldung/AMD-Entwickler-beschreiben-CPU-GPU-Kombi-fuer-Supercomputer-3632974.html

P.S.: Eine Woche nach der Publikation erschienen die ersten ZEN 1 Tests am 02.03.2017

[crux2005]

Ian ist kein Fan von Big Little im Desktop. Windows 10 (Scheduler) wurde nicht dafür gemacht:

wt6OH5sdDuY

[y33H@]

Bei Lakefield funktioniert's ziemlich gut.



https://scr3.golem.de/screenshots/2007/Lakefield-Review/Lakefield-Review-11.png

[robbitop]

Ja bei modernen CPUs wird schon eine Menge über den controller gehandelt, so dass der scheduler nicht das sieht, was tatsächlich vor sich geht. Damit werden seine Unzulänglichkeiten ein Stückweit umgangen.

[Dr. Lloyd]

Gemäß den geleakten Intel-Folien wird Alder Lake "Hardware-Guided Scheduling" nutzen. Somit dürfte der Windows Scheduler damit wenig Probleme haben. In Mobilgeräten von/mit Apple/Android gibt's das doch schon seit vielen Jahren.

Sollte AMD dieses Jahr noch nichts mit DDR5 bringen - und danach sieht's leider aus, wird's bei mir mit nahezu 100%iger Wahrscheinlichkeit ein Alder Lake-System. Das Paket an Neuerungen, bestehend aus +20% IPC, 10nm SuperFin (= 1,5- bis 2-facher Fertigungssprung), PCIe5, DDR5 und womöglich noch USB4 über den ebenfalls neuen Intel-Chipsatz, wird alles, was es jetzt gibt, extrem alt aussehen lassen.

Um nicht in Versuchung zu kommen, bis dahin noch irgendwas altes zu kaufen, habe ich bereits meine zahlreichen DDR4-RAM-Kits abgestoßen. Die hatte ich für schlechte Zeiten eingelagert und ließen sich jetzt gut verkaufen.

[memory_stick]

Die Plattform sieht wie ich finde sehr vielversprechend aus mit all den neuen interconnects und DDR5.
Bei der Perf. und vor allem Intels IPC Angaben bin ich dennoch sehr vorsichtig. Die bisherigen Angaben bei TGL (real nahe 0 IPC, dafür Takt ggü. 14nm wieder aufgeholt) sowie RKL (+19% IPC, real sehr durchzogen eher im Bereich 10%, einige edge cases) lassen da leider nicht hoffen. Auch inwiefern ESF ggü. SF noch zulegen kann wird spannend zu sehen sein. Stellt sich halt auch die Frage inwieweit Golden Cove die Fertigungsverbeserungen wieder mitigiert durch mehr Logik/Takt?
Alles sehr spannend um zu diskutieren, nur festlegen würde ich mich da noch nicht bis nicht seriöse Tests vorhanden sind.

[w0mbat]

Das Paket an Neuerungen [...] werden alles, was es jetzt gibt, extrem alt aussehen lassen.
Ich würde erst mal abwarten ob es Intel überhaupt schafft mit ADL Zen3 einzuholen :tongue:

[robbitop]

Kern für Kern ist das in Spielen doch bereits geschehen: https://www.computerbase.de/2021-03/intel-core-i9-11900k-i5-11600k-test/3/#abschnitt_intel_core_vs_amd_ryzen_in_720p

Sieht für mich nach einem pari aus. 11900K ~ 5800X. Natürlich mit höherer Leistungsaufnahme. Aber die Performance ist pari.

Die Frage ist IMO eher wie stark man vorbeizieht. Man muss bedenken, dass 2021 noch Warhol kommt. Der legt sicherlich ~10% auf die 5000er Serie drauf.

[Dr. Lloyd]

Ich würde erst mal abwarten ob es Intel überhaupt schafft mit ADL Zen3 einzuholen :tongue:
Bis 8 Kerne wird Alder Lake sicher Zen 3 schlagen. Womöglich wird AMDs vollwertiger 16-Kerner in irgendwelchen Anwendungen noch seine Vorteile behalten können, aber solche Anwendungen nutze ich eh nicht. Ich bin schon froh, wenn meine Software 8 Kerne zu nutzen weiß.

[w0mbat]

So sicher wäre ich mir da nicht. Du vergisst, dass RKL schon auf der neuen .cove Architektur basiert und das noch im ausgereiften 14nm Prozess. 10nm SF wird wohl deutlich effizienter sein, aber wie es mit den Taktraten aussieht, die RKL ja noch etwas retten, wissen wir nicht. Und ja, ADL wird verbesserte .cove Kerne haben, aber was man auf Intels IPC Angaben geben kann haben wir ja deutlich gesehen. "19% more IPC" waren in manchen Spielen eher "1,9% weniger IPC".

Wenn es gut läuft, hat ADL wirklich nochmal +20% IPC auf RKL, taktet ähnlich hoch, ist dabei deutlich effizienter und der big.LITTLE Ansatz bringt echt was.

Wenn es schlecht läuft ist die reale IPC nicht wirklich besser, der Takt sinkt etwas und dank 10nm SF säuft er zwar nicht mehr so viel, aber die kleinen Kerne sind auf dem Desktop nutzlos.

Ich hoffe ja, dass wir wieder eine gute Intel CPU sehen. Aber nach so vielen Reinfällen bin ich erst dann überzeugt, wenn wir es schwarz auf weiß haben.

[memory_stick]

So sicher wäre ich mir da nicht. Du vergisst, dass RKL schon auf der neuen .cove Architektur basiert und das noch im ausgereiften 14nm Prozess. 10nm SF wird wohl deutlich effizienter sein, aber wie es mit den Taktraten aussieht, die RKL ja noch etwas retten, wissen wir nicht. Und ja, ADL wird verbesserte .cove Kerne haben, aber was man auf Intels IPC Angaben geben kann haben wir ja deutlich gesehen. "19% more IPC" waren in manchen Spielen eher "1,9% weniger IPC".

Wenn es gut läuft, hat ADL wirklich nochmal +20% IPC auf RKL, taktet ähnlich hoch, ist dabei deutlich effizienter und der big.LITTLE Ansatz bringt echt was.

Wenn es schlecht läuft ist die reale IPC nicht wirklich besser, der Takt sinkt etwas und dank 10nm SF säuft er zwar nicht mehr so viel, aber die kleinen Kerne sind auf dem Desktop nutzlos.

Ich hoffe ja, dass wir wieder eine gute Intel CPU sehen. Aber nach so vielen Reinfällen bin ich erst dann überzeugt, wenn wir es schwarz auf weiß haben.

RKL basiert auf Sunny Cove aka Ice Lake, das Design ist doch 2 Generationen hinter ADL, welcher Golden Cove für die Big Cores verwendet.
Dazu wird ADL in "Enhanced" SF gefertigt, was laut Intel doch noch einige Verbesserungen bringen wird. Was 10nm SF bereits an Takt leisten kann sehen wir an TGL (Boost 4.9GHz), da happert es allerdings noch an der Leitungsaufnahme der Cove Kerne.
Was neue Kerne mit neuem, verbessertem Fertigungsprozess an Takt, Perf und Leistungaufnahme bringen werden wird man sehen. Es ist jedoch davon auszugehen, das in mind. 1 dieser Metriken Fortschritte sichtbar werden.

[w0mbat]

RKL = Cypress Cove

Und der Takt liegt nicht nur am Prozess, sondern auch an der Architektur. TGL ist Willow Cove, nicht Golden Cove.

[robbitop]

Bei RKL/Cypress Cove wäre ich mir nicht 100%ig sicher, ob dieser wirklich clock for clock and Sunny Cove heran kommt. Ian sagte, dass es gerade bei den Timings Rückschritte geben könnte.

Wenn man sich TGL im Notebook relativ zu CML im Notebook anschaut, ergibt das ein völlig anderes Bild als RKL vs CML im Desktop.
Ich tippe darauf, dass TGL mit 8C/16T selbst mit weniger Takt im Desktop vorn gewesen wäre ggü RKL. Das war eine klare Kapazitätsfrage.

Intel selbst gibt bereits TGL-H mit 5 GHz Turbo an:
https://ark.intel.com/content/www/us/en/ark/products/197384/intel-core-i7-11375h-processor-12m-cache-up-to-5-00-ghz-with-ipu.html

ADL ist nochmal eine 10 nm Iteration weiter.
Wenn es eine Regression in Taktraten gibt, wird diese ggf. nicht all zu groß werden.

[Dr. Lloyd]

So sicher wäre ich mir da nicht. ...
Meine Hoffnung in die starke Leistung von Alder Lake ist neben 10nm SuperFin auch durch die Nutzung von DDR5 begründet: Bei der Bandbreite fängt DDR5 in der Praxis dort an, wo DDR4 in der Theorie (only on Apex) aufhört. Und die Neuerung, die Spannungsregulierung im RAM und nicht mehr auf dem Mainboard erfolgen zu lassen, dürften bereits zum DDR5-Start starkes RAM-OC möglich machen.

Das wird super werden, da bin ich mir sicher. Somit freue ich mich schon riesig auf September/Oktober, wenn das tatsächlich Realität geworden ist. Und diesmal bin ich von Anfang an dabei. Koste es was es wolle! :-)

[w0mbat]

ADL schon im September/Oktober? Das wären ja keine 6 Monate nach RKL.

[Dr. Lloyd]

ADL schon im September/Oktober? Das wären ja keine 6 Monate nach RKL.
Ja, richtig. So ist zumindest der noch inoffizielle Fahrplan. Und den werde ich natürlich nicht hinterfragen, sondern mich freuen, dass dem so ist. :-)

[fondness]

Kern für Kern ist das in Spielen doch bereits geschehen: https://www.computerbase.de/2021-03/intel-core-i9-11900k-i5-11600k-test/3/#abschnitt_intel_core_vs_amd_ryzen_in_720p

Sieht für mich nach einem pari aus. 11900K ~ 5800X. Natürlich mit höherer Leistungsaufnahme. Aber die Performance ist pari.

Die Frage ist IMO eher wie stark man vorbeizieht. Man muss bedenken, dass 2021 noch Warhol kommt. Der legt sicherlich ~10% auf die 5000er Serie drauf.

Ein 5800X ist halt nicht wirklich alles, was AMD aufzubieten hat, der taktet max. mit 4850Mhz. Oder anders formuliert, der 5950X ist nicht nur wegen den mehr an Kernen in Spielen schneller.

Der 5950X taktet 5% höher, dann legt Warhol vielleicht noch 10% drauf, und dann bleibt die Frage, wieviel von den 20%, die Intel angegeben hat übrig bleiben. Bei RKL waren es nicht viel.

Aber ja, Intel wird auf jeden Fall wieder deutlich konkurrenzfähiger sein, das ist klar. Alles andere wäre auch überraschend bis absurd. ADL ist defacto alles, was Intel aufzubieten hat. Einen Fertigungsnachteil gibt es auch nicht mehr und die letzten 6 Jahre seit Skylake ist hoffentlich dann doch etwas passiert. Eigentlich wäre alles andere als ein klarer Sieg absurd, die können ja nicht seit Skylake die Entwicklungsarbeit eingestellt haben.

[y33H@]

Wieso ist der 5950X dann schneller, wegen den 100 MHz mehr? ^^

[w0mbat]

Jupp, der 11900K ist bis ans Maximum getrieben, bzw. sogar darüber hinaus. Und er kommt gerade so ran. AMD hat keine der Zen3 SKUs ans Maximum getrieben.

Zudem ist Zen3 jetzt auch schon fast 6 Monate alt.

[y33H@]

was man auf Intels IPC Angaben geben kann haben wir ja deutlich gesehen. "19% more IPC" waren in manchen Spielen eher "1,9% weniger IPC"Was soll dieser Unfug? RKL-S mit Sunny Cypress Cove ist pro Kern und Takt durchweg klar flotter als CML-S mit Kaby Lake ... keine +19%, aber +15% (https://www.computerbase.de/2021-03/intel-core-i9-11900k-i5-11600k-test/#abschnitt_ipczugewinne_in_anwendungen_und_spielen) in den allermeisten Fällen schon.

[robbitop]

Naja der 5950X ist, wenn man ehrlich bleibt, kein legitimer Wettbewerber für den 11900K. Der kostet über das doppelte und ist extremst gebinnt.

[Platos]

Der 11900k fairerweise aber auch nicht zum 5800x. Der 11700K ist preislich näher (wenn auch darunter - d.h er kann auch um den Preis weniger leisten).

Der 5800X hat eig. gar keinen richtigen Preiskonkurrent. Der 11900k ist teurer, der 10700k ist günstiger.

[robbitop]

Ja das stimmt. Aber: architektonisch gesehen aber schon. Beides sind die meist ausgereizten 8C/16C CPUs.

[Platos]

Wie sieht das eig. nochmals mit Alderlake aus? Da werden der i7 und i9 doch auch gleichzeitig 8 starke Kerne an der Spitze haben?

Also wird es wohl wieder so ein überteuerten 8 Kerner geben.

[fondness]

Ja das stimmt. Aber: architektonisch gesehen aber schon. Beides sind die meist ausgereizten 8C/16C CPUs.

LOL, schön langsam musst du dich entscheiden. Der 5800X ist eben kein Topmodell, der 11900k schon. Dementsprechend ist der 11900k das höchst gebinnte Model, der 5800X nicht.

[robbitop]

LOL, schön langsam musst du dich entscheiden. Der 5800X ist eben kein Topmodell, der 11900k schon. Dementsprechend ist der 11900k das höchst gebinnte Model, der 5800X nicht.
In Benchmarks kann man aber nicht sicherstellen, dass nicht auch mehr Kerne doch noch einen kleinen Vorteil bieten. Sei es für die Anwendung/das Spiel selbst oder für Hintergrundprozesse (siehe Nvidia Treiber).

Sauber kann man eigentlich nur gleiche Kernzahl vergleichen. AMD hat dieses Mal eben nur 1x 8C Modell. Und das ist eben full-out. Ja ein bisschen geht offenbar noch durch binning.

Was man tun könnte ist beim 5950X 8x Cores zu deaktivieren.

[w0mbat]

Was soll dieser Unfug? RKL-S mit Sunny Cove ist pro Kern und Takt durchweg klar flotter als CML-S mit Kaby Lake ... keine +19%, aber +15% (https://www.computerbase.de/2021-03/intel-core-i9-11900k-i5-11600k-test/#abschnitt_ipczugewinne_in_anwendungen_und_spielen) in den allermeisten Fällen schon.
1. Cypress Cove, nicht Sunny Cove
2. es gibt mehrere Spiele wo CML > RKL liegt
3. Fazit: kein Unfug

[Lehdro]

Was man tun könnte ist beim 5950X 8x Cores zu deaktivieren.
Oder einen 5800X mit PBO +xy MHz Settings ausstatten, mit denen er stabil auf dem CCD Niveau vom schnellen CCD des 5950X liegt. Gibt ja durchaus 5800X die das schaffen. Wobei dann die Frage ist, wie man das ansetzt: Mein 5950X boostet stock schon mit 2 Kernen über 5 GHz und ein paar weitere über den offiziellen Boost von 4.9 GHz.

Zudem stellt sich die Sinnfrage: Wenn man so etwas testen will bietet sich ein Vergleich bei gleichem Takt geradezu an. Mit 4.8 GHz sind beide Architekturen bei den 8 Kernern sicherlich gut bedient.

[y33H@]

es gibt mehrere Spiele wo CML > RKL liegtDann zeigt doch bitte entsprechende IPC-Messungen ... die von CB und meine geben das nicht her.

[aufkrawall]

Mein Takt, Thread und RAM-bereinigter Worst Case vs. Skylake ist bislang Borderlands 2 mit DXVK, da sind es nur ~5% Gewinn. Der ganze andere Gammel mit wenig Threads läuft eindeutig etwas schneller (Valley, HotS, Mirror's Edge DXVK...).

Edit: Man muss halt auch sehen, dass jeder Test mit Gear 2 (standardmäßig hat nur der i9 3200er RAM mit Gear 1 IMC) im Grunde für die Tonne ist.

[Lehdro]

Dann zeigt doch bitte entsprechende IPC-Messungen ... die von CB und meine geben das nicht her.
Das hat mich jetzt aber auch interessiert, also habe ich mal grob über die bekannten Seiten bei den Reviews drüber geschaut. Jeweils 10700k vs 11900k, zu bedenken: Der 11900K hat 4% mehr Boosttakt und (meist) schnelleren RAM. Ich habe so gut es geht versucht zu verlinken:
Bei CB: (https://www.computerbase.de/2021-03/intel-core-i9-11900k-i5-11600k-test/3/#abschnitt_intel_core_vs_amd_ryzen_in_720p)
Zweite Spalte (10700k vs. 11900k). Vier Ergebnisse stehen da mit nur minimalen Differenzen zur Diskussion: BL3, F1 2020, RDR2 & Valorant.

Bei PCGH: (https://www.pcgameshardware.de/Core-i9-11900K-CPU-277110/Tests/11700K-11600K-Test-Rocket-Lake-1369258/3/)

AC:V, 10700k 5% schneller als 11900k. Auffällig: RDR2

Bei TechPowerUp: (https://www.techpowerup.com/review/intel-core-i9-11900k/16.html)

CP2077, Metro & RDR2. Auffällig: SotTR

Bei Techspot (HardwareUnboxed): (https://www.techspot.com/review/2222-intel-core-i9-11900k/)

Star Wars Squadrons. Auffällig: BL3

Bei Guru3D: (https://www.guru3d.com/articles_pages/intel_core_i9_11900k_processor_review,22.html)

Auffällig: F1 2018

Bei Anandtech:

FF14 (https://www.anandtech.com/show/16495/intel-rocket-lake-14nm-review-11900k-11700k-11600k/11),F1 2019 (https://www.anandtech.com/show/16495/intel-rocket-lake-14nm-review-11900k-11700k-11600k/15), RDR2 (https://www.anandtech.com/show/16495/intel-rocket-lake-14nm-review-11900k-11700k-11600k/19), Strange Brigade (https://www.anandtech.com/show/16495/intel-rocket-lake-14nm-review-11900k-11700k-11600k/20)

[aufkrawall]

Die ausgewürfelten Werte von PCGH bei Valhalla im GPU-Limit oder die unsinnige Benchszene für SotTR von TPU sind aber auch sehr facepalmig. Ist zwar technisch interessant. Aber letztlich sind niedrige einstellige Regressions nicht tragisch, wenn es dafür anderweitig Gewinne in Situationen gibt, in denen es stärker drauf ankommt (Anno, Legion...).

[Lehdro]

Die ausgewürfelten Werte von PCGH bei Valhalla im GPU-Limit oder die unsinnige Benchszene für SotTR von TPU sind aber auch sehr facepalmig. Ist zwar technisch interessant. Aber letztlich sind niedrige einstellige Regressions nicht tragisch, wenn es dafür anderweitig Gewinne in Situationen gibt, in denen es stärker drauf ankommt (Anno, Legion...).
Full ack.

Ging aber wirklich eher um die akademische Feststellung das es durchaus auch einstellige Regressions geben kann, je nach Benchszene und Engine.

[y33H@]

Das hat mich jetzt aber auch interessiert, also habe ich mal grob über die bekannten Seiten bei den Reviews drüber geschaut. Jeweils 10700k vs 11900k, zu bedenken: Der 11900K hat 4% mehr Boosttakt und (meist) schnelleren RAM. Ich habe so gut es geht versucht zu verlinkenDas was du da machst, geht nicht - du kannst nicht die nominellen Taktraten nehmen, denn in der Praxis fluktuiert der Turbo. Für IPC-Vergleiche muss die Frequenz identisch sprich fix sein wie bei CB und da ist RKL-S pro Kern/Takt deutlich vor CML-S.

[aufkrawall]

Above 4G Decoding sollte auch komplett aus sein, es scheint damit zwischen Biosen, Treibern und Anwendungen ziemliches Verkackungspotenzial zu geben.

[Lehdro]

Das was du da machst, geht nicht - du kannst nicht die nominellen Taktraten nehmen, denn in der Praxis fluktuiert der Turbo. Für IPC-Vergleiche muss die Frequenz identisch sprich fix sein wie bei CB und da ist RKL-S pro Kern/Takt deutlich vor CML-S.
Dessen bin ich mir bewusst. Allerdings sind 6% avg. (leider in weniger & anderen Spielen als im Testparcours) eben auch keine 19%, immerhin retten es die Frametimes.

Die Beispiele zeigen doch nur das die IPC eben nicht überall 1:1 durchschlägt, ob da nun die Engine schlecht drauf anspricht, oder die Boosts bei RKL weniger gut ausfallen, ist dann eher die Frage die es zu klären gilt. Dass das soweit geht dass der 10700k teilweise gleichauf, oder sogar vor dem 11900k landet, ist trotzdem kurios und technisch interessant.

Ist hier aber eh alles OT.

[Platos]

Müsste eig. DDR5 nicht weniger Strom benötigen wie in etwa gleich schnelle DDR4 Riegel? Mit gleich Schnell meine ich doppelter Takt bei doppelten Timings.

Die Spannung dürfte vermutlich gesenkt werden bei DDR5, nehme ich an. Kann man dann davon ausgehen, dass auch die Leistungsaufnahme sinkt ?

Theoretisch zumindest. In der Praxis werden die ersten DDR5 Boards wahrscheinlich die üblichen "Bling-Bling" Boards sein, die viel zu viel Strom fressen.

[Dr. Lloyd]

Müsste eig. DDR5 nicht weniger Strom benötigen wie in etwa gleich schnelle DDR4 Riegel? Mit gleich Schnell meine ich doppelter Takt bei doppelten Timings.

Die Spannung dürfte vermutlich gesenkt werden bei DDR5, nehme ich an. Kann man dann davon ausgehen, dass auch die Leistungsaufnahme sinkt ?
Die Leistungsaufnahme sinkt bei DDR5 erheblich. Von Asgard sind bereits für die Jahre 2022/2023 bis zu 6400MHz-DDR5 angekündigt, die zwar bei eher schlecht anmutenden Timings, weiterhin nur 1,1V verbrauchen sollen. Der Standard bei DDR4 liegt bei 1,2V.

Siehe hierzu: https://videocardz.com/newz/asgard-lays-its-plans-for-ddr6-memory-128gb-5600-mhz-kits-in-2022

[Platos]

Jap, hab gelesen, dass es 1.1v sind. Aber der Unterschied in der Leistungsaufnahme ist dadurch ja nicht wirklich ablesbar.

[Dr. Lloyd]

Also für mich ist das schon ablesbar. Aktuelle DDR4-5000-RAMs brauchen - zugegeben bei besseren Timings - inakzeptable 1,6V. Da sagt selbst "der8auer" in seinem Rocket Lake Review, dass ihm das für den Alltagsbetrieb zu viel ist.

Das Ganze funktioniert bei DDR4 dann auch nur mit den besten Rocket Lake CPUs, auf speziellen OC-Mainboards wie dem ASUS Apex, und dann auch nur mit halbiertem Speichercontroller-Takt (Gear 2).

[Platos]

Ein DDR 4 5000MHz Modul müsste man aber mit einem 10000MHz DDR5 Modul vergleichen. 6400MHz DDR5 dann entsprechend mit 3200MHz DDR4

[Dr. Lloyd]

Warum?

[Platos]

Weil die Timins sinken bei ner neuen Generation und somit die höhere Taktrate nicht wirklich zu niedrigeren Latenzen führen. Das war schon bei DDR3 zu DDR4 so.

Aber die Bandbreite steigt natürlich an.

Also DDR4 4000Mhz ist auf jeden Fall schneller, wie ein DDR5 4800MHz.

Edit: Hier sieht man, wie man es berechnet (die Timings in den Beispielen sind aber schlecht gewählt): https://www.computerbase.de/forum/threads/so-berechnet-man-die-latenzzeit-von-sdram.1395456/

[Dr. Lloyd]

Was die Timings angeht, muss man erst noch sehen, was G.Skill & Co. da noch herausholen können. Die aktuellen Angaben sind ja noch ohne OC auf Basis von Micron-Chips.

Zudem ist die Frage, ob wir es bei DDR5 dann auch wieder mit Gear 2 zu tun haben oder ob der Speichercontroller 1:1 mit dem RAM-Takt läuft. Wenn Letzteres der Fall ist, hat DDR4 hier gar keine Chance.

[BlacKi]

Weil die Timins sinken bei ner neuen Generation und somit die höhere Taktrate nicht wirklich zu niedrigeren Latenzen führen. Das war schon bei DDR3 zu DDR4 so.

Aber die Bandbreite steigt natürlich an.

Also DDR4 4000Mhz ist auf jeden Fall schneller, wie ein DDR5 4800MHz.

Edit: Hier sieht man, wie man es berechnet (die Timings in den Beispielen sind aber schlecht gewählt): https://www.computerbase.de/forum/threads/so-berechnet-man-die-latenzzeit-von-sdram.1395456/


die memory latenz ist nicht der einzige wert der einfluss auf die gaming performance hat. ich hab schon mit meinem ram tests gemacht die aufzeigen das die speicherlatenz mit 3200 zwar besser war als mit 4000, aber mit 4000 trotz schlechterer latenz bessere gaming performance geboten haben.
deshalb sind diese rechnungen schön und gut, aber nicht 100% aussagekräftig was wirklichschneller ist.

[dildo4u]

Laut dem kommt AL Desktop 2021.


https://www.anandtech.com/show/16629/intel-confirms-tiger-lake-u-refresh-later-in-2021

[w0mbat]

First is that Intel has already announced that its next-generation Alder Lake processors, using a Core + Atom hybrid design, will be coming out later this year for mobile and desktop.
Das ist doch nichts neuen, die wiederholen nur das, was Intel bisher gesagt hat. ADL kommt laut Intel 2021, das ist schon lange so angekündigt.

[dildo4u]

Ian ist immer noch skeptisch, das hat nicht nur mit Intel zu tun sondern wie es mit der Verfügbarkeit von DDR5 aussieht.


https://youtu.be/0T1HBme_F4c?t=203

[Platos]

die memory latenz ist nicht der einzige wert der einfluss auf die gaming performance hat. ich hab schon mit meinem ram tests gemacht die aufzeigen das die speicherlatenz mit 3200 zwar besser war als mit 4000, aber mit 4000 trotz schlechterer latenz bessere gaming performance geboten haben.
deshalb sind diese rechnungen schön und gut, aber nicht 100% aussagekräftig was wirklichschneller ist.

Was waren das denn für Spiele? RT Spiele?

Ich wäre ja begeistert, wenn die Testseiten dann mit DDR5 verschiedene Speicherriegel gegeneinander antreten lassen.

Also z.B DDR4 2400, 2666, 3000, 3200, 3600, 4000 vs die dann vorhandenen DDR5 Riegel. Man müsste aber übliche Timings nehmen bei den jeweiligen Taktraten und nicht die besten.

Ich hab ja nichts dagegen, wenn ich flotten RAM mit 1.1v bekäme. Würde mir äusserst gelegen kommen. Aber dafür brauch die Mainboards gefühlt immer mehr Strom.

[robbitop]

Ich denke, dass wir mit AIDA64 einfach nicht akkurat messen können. Bzw das Messergebnis nicht das volle Bild widerspiegelt. Das liegt daran, dass bestimmte Patterns vom Prefetcher/Cache beeinflusst werden. Genau aus dem Grund hat Anandtech sich ein eigenes Latency tool mit unterschiedlichen Zugriffspattern gebaut.

Ich gehe davon aus, dass die Gesamtmemorylatenz deutlich dominierender ist als die Bandbreite in den meisten Anwendungen und Spielen.
Ich gehe nicht davon aus, dass DDR5 mittelfristig in Spielen einen deutlichen Vorteil bringen wird. Natürlich latenz- und CPU normiert.

[BlacKi]

Was waren das denn für Spiele? RT Spiele?

deus ex md. meine lieblings benchszene, wo es selbst mit schnellsten cpus ein cpu limit gibt.

[Platos]

Ich denke, dass wir mit AIDA64 einfach nicht akkurat messen können. Bzw das Messergebnis nicht das volle Bild widerspiegelt. Das liegt daran, dass bestimmte Patterns vom Prefetcher/Cache beeinflusst werden. Genau aus dem Grund hat Anandtech sich ein eigenes Latency tool mit unterschiedlichen Zugriffspattern gebaut.

Ich gehe davon aus, dass die Gesamtmemorylatenz deutlich dominierender ist als die Bandbreite in den meisten Anwendungen und Spielen.
Ich gehe nicht davon aus, dass DDR5 mittelfristig in Spielen einen deutlichen Vorteil bringen wird. Natürlich latenz- und CPU normiert.

Glaube ich auch nicht. Aber was für ein Tool ist das? Kann man das Downloaden (gratis)?

Aber so wie bei vielen Dingen, die ins Detail gehen: Testseiten testen das einfach nicht (richtig).

[WedgeAntilles]

Ian ist immer noch skeptisch, das hat nicht nur mit Intel zu tun sondern wie es mit der Verfügbarkeit von DDR5 aussieht.


https://youtu.be/0T1HBme_F4c?t=203

Ich glaube nicht, dass es am Markt eine große Aversion gibt statt DDR5 noch mal DDR4 zu kaufen.

IMO ist er (als Hardware Enthusiast) da ein bisschen betriebsblind.
Die Großteil der Käufer weiß doch nicht mal was DDR3, DDR4, DDR5 eigentlich bedeutet.

Dann wird DDR5 auf absehbare Zeit (und das sind doch eher noch mindestens 2 Jahre als nur noch 1 Jahr) wohl merklich teurer als DDR4 sein.
Nur: Wieviel Prozent der Käufer sind denn bereit, 150 Euro oder so Aufpreis beim Ram zu bezahlen?

Sieht man doch alleine daran, was für Ram in den Komplett-PCs verbaut ist. Das ist meist günstigerer Ram, kein teurer.
Stört aber keinen.

Aus Enthusiastensicht mag es nicht attraktiv sein Ende 2021 Alder-Lake mit DDR4 zu kaufen.
Für die überwältigende Mehrheit der Käufer spielt diese Betrachtung aber absolut keine Rolle.

Und die Board-Partner können ja DDR4 Boards anbieten - und wenn dann DDR5 zig Monate später verfügbar ist zusätzlich DDR5 Boards.

Was soll da das unlösbare Problem sein? Warum sollte Intel ein halbes Jahr (oder sogar länger?) mit AlderLake warten, nur weil es zum Start noch kein DDR 5 gibt?
Wer unbedingt DDR5 braucht wird doch nicht gewzungen zu kaufen, der kann ja warten. :confused:

Das Video ist IMO ein Beispiel für eine gute Theorie, die aber vollständig an der Praxis vorbeigeht. Intel interessiert sich nicht für eine handvoll Enthusiasten sondern für die Millionen potentiellen Käufer die sich nicht um DDR 4 / DDR5 scheren.

[Platos]

Wer unbedingt DDR5 braucht wird doch nicht gewzungen zu kaufen, der kann ja warten. :confused:

Das Video ist IMO ein Beispiel für eine gute Theorie, die aber vollständig an der Praxis vorbeigeht. Intel interessiert sich nicht für eine handvoll Enthusiasten sondern für die Millionen potentiellen Käufer die sich nicht um DDR 4 / DDR5 scheren.

Oder aber solche Aussagen widerspiegeln die heutige Gesellschaft, in denen viele Leute nicht fähig sind, auf etwas zu warten, wenn es auf dem Markt ist. Muss gleich gekauft werden ;D Keine Selbstbeherrschung, finde ich ja.

Aber bezüglich DDR5/4: Also ich würde sagen, die meisten Absätze werden durch Komplett-PCs generiert und da entscheidet schlicht die Wirtschaftlichkeit, also der OEM. Ich denke DDR5 wird da dann in sonder-teuren Modellen zu finden sein, die dann aber nur die grössten Spinner kaufen im Komplett-PC Markt.

Und im diy-Markt werden wahrscheinlich auch nur die Enthusiasten DDR5 kaufen, der Rest wird nicht den doppelten Preis bezahlen, tun sie ja schon bei DDR4 nicht, da kauft auch nicht die Mehrheit DDR4 4000-er RAM.

Ich kann mir aber gut vorstellen, dass viele dann sowas wie DDR5 4800 RAM kaufen, weil der (vlt.) bezahlbar ist und die Leute denken, der ist jetzt besser wie DDR4 4000-er RAM (für Gaming).

[BlacKi]

ihr habt noch ddr3 vs ddr4 im kopf. damals war ddr4 massiv teurer, weil ddr3 billig war. das ist zurzeit aber nicht der fall. ddr4 ist bereits teuer, ddr5 wird grob nur 20-30% teurer werden IMHO.


Ich kann mir aber gut vorstellen, dass viele dann sowas wie DDR5 4800 RAM kaufen, weil der (vlt.) bezahlbar ist und die Leute denken, der ist jetzt besser wie DDR4 4000-er RAM (für Gaming).das ist zu konservativ gedacht. ddr4 4000 wird wohl trotz besserer latenzen in gaming nicht massiv besser sein als ddr5 4800. und tweaker werden auch keinen 4800er ram kaufen. die werden eher ab 6400 einsteigen und schauen was sie noch an takt und timings rausholen können.

[Blediator16]

Was ist aktuell an DDR4 teuer?

[Platos]

ihr habt noch ddr3 vs ddr4 im kopf. damals war ddr4 massiv teurer, weil ddr3 billig war. das ist zurzeit aber nicht der fall. ddr4 ist bereits teuer, ddr5 wird grob nur 20-30% teurer werden IMHO.

Das ändert dann ja aber nicht am allgemein hohen Preisniveau. Der Preis ist dann nur scheinbar "nur" 20-30% teurer. Die Preise sind halt letztes Jahr gestiegen, vermutlich wegen Corona und der hohen Nachrfage. Ich finde hier gerade wieder Riegel, die vorhin 100 Euro gekostet haben und jetzt 160 Euro.

Wenn die RTX 4080 1000$ teuer wird, sage ich auch nicht, ist ja eig. günstiger wie damals die 3080 zu Hochpreiszeiten:freak:

Aber mag sein, dass zum dann herrschenden Preis DDR5 nicht extrem viel teurer ist. Dann würde ich aber trotzdem jedem emfpehlen zu warten.

das ist zu konservativ gedacht. ddr4 4000 wird wohl trotz besserer latenzen in gaming nicht massiv besser sein als ddr5 4800. und tweaker werden auch keinen 4800er ram kaufen. die werden eher ab 6400 einsteigen und schauen was sie noch an takt und timings rausholen können.

Naja, das will ich dann aber getestet sehen, vorher sind das nichts mehr als Vermutungen. Da reichen mir auch keine Tests innerhalb der selben Speichergeneration.

Und ich habe ja nicht von Tweaker geredet, das war eben ein Beispiel. Abgesehen davon wird dann 6400-er RAM sicherlich teurer wie 4800-er RAM sein. Und damals bei DDR4 haben die meisten am Anfang keine 3200-er RAM gekauft. Da haben viele 2400/2666 gekauft. 3200-er RAM war nämlich Anfangs viel teurer. Das wird jetzt auch nicht anders sein.

Was ist aktuell an DDR4 teuer?

https://geizhals.de/g-skill-trident-z-silber-rot-dimm-kit-32gb-f4-3600c17d-32gtz-a1567801.html?hloc=at&hloc=de

Such dir hier was raus und schau den Preisverlauf des letzten Jahres an.

[HPVD]

Gerücht: Intel Alder Lake wird langsamer als erwartet

https://www.notebookcheck.com/Geruecht-Intel-Alder-Lake-wird-langsamer-als-erwartet-die-Xe-Gaming-GPU-dafuer-ueberraschend-guenstig.536165.0.html

[w0mbat]

Das ist wohl nur eine Extrapolierung von Intels bisherigen Entwicklungen :P

[Platos]

Wenn Intel bei den Grafikkarten eine gute Verfügbarkeit haben, ist das eig. DER Zeitpunkt, um ins Geschäft einzusteigen. Denn schliesslich sind die Preise bei den anderen so kaputt, da muss man nicht mal Konkurrenzfähig sein bezüglich Leistung/Listenpreis.

Eigentlich DIE Chance für Intel, Marktanteile zu gewinnen. Und dass sie eien gute Verfügbarkeit haben können, haben sie ja mit Rocket Lake bewiesen.

[HOT]

Gerücht: Intel Alder Lake wird langsamer als erwartet

https://www.notebookcheck.com/Geruecht-Intel-Alder-Lake-wird-langsamer-als-erwartet-die-Xe-Gaming-GPU-dafuer-ueberraschend-guenstig.536165.0.html

Dazu passend Ians Skepsis ggü. Alder Lake

https://www.youtube.com/watch?v=0T1HBme_F4c

AMDs 12 und 16 Kerner sind damit wohl nicht einholbar, das ist denke ich relativ klar mittlerweile.

[y33H@]

Hat sich Ian eigentlich mal detailliert praktisch mit Lakefield beschäftigt?

[aufkrawall]

Gerücht: Intel Alder Lake wird langsamer als erwartet

https://www.notebookcheck.com/Geruecht-Intel-Alder-Lake-wird-langsamer-als-erwartet-die-Xe-Gaming-GPU-dafuer-ueberraschend-guenstig.536165.0.html
Oh, oh. Im schlimmsten Fall bringt das Hardware-Scheduling für Spiele gar nichts und es läuft so im besten Fall auf dem Niveau von 10C CML mit etwas Allcore-OC.
Oder die littles saufen "unerwartet" viel, wenn hoher Takt auf allen Kernen anliegen soll. ;D

[w0mbat]

Ne, im schlimmsten Fall wird ADL nochmal langsamer und die 10nm ESF yields sind so grottenschlecht, dass die CPUs trotzdem überteuert sind.

[Distroia]

Oh, oh. Im schlimmsten Fall bringt das Hardware-Scheduling für Spiele gar nichts und es läuft so im besten Fall auf dem Niveau von 10C CML mit etwas Allcore-OC.
Oder die littles saufen "unerwartet" viel, wenn hoher Takt auf allen Kernen anliegen soll. ;D

Glaubt überhaupt irgendjemand, dass die Little-Cores irgendwas bei Spielen bringen (von Ausnahmen abgesehen)? Mehr als 8 Kerne bringen sowieso schon sehr wenig bis gar nichts; ich kann mir eher vorstellen, dass die Little-Cores stören, wenn der Scheduler nicht genau macht, was er machen soll.

Die Little-Cores werden wahrscheinlich den Rückstand im Bezug auf Leistung und Leistungsaufnahme in stark parallelisierbaren Anwendungen verkürzen, mehr aber auch nicht.

[Platos]

Glaubt überhaupt irgendjemand, dass die Little-Cores irgendwas bei Spielen bringen (von Ausnahmen abgesehen)? Mehr als 8 Kerne bringen sowieso schon sehr wenig bis gar nichts; ich kann mir eher vorstellen, dass die Little-Cores stören, wenn der Scheduler nicht genau macht, was er machen soll.

Die Little-Cores werden wahrscheinlich den Rückstand im Bezug auf Leistung und Leistungsaufnahme in stark parallelisierbaren Anwendungen verkürzen, mehr aber auch nicht.

Die little.Cores sind vor allem der Konter auf Apple, also d.h Energieeffizienz in niedrigen Lastszenarien. Die wurden sicherlich nicht für's Gaming eingebaut :freak:

Wie ja das Konzept eigentlich schon verratet, sind die kleinen Cores nicht dazu gedacht grosse Lasten auszuführen. Ich weiss nicht, wie hier manche auf Gaming kommen:confused: Die sind dazu da, den Stromverbrauch auf niedriglast deutlich zu senken bzw. die grossen Cores bei ihrer "eigentlichen" Aufgabe zu entlasten (vom OS etc.).

[w0mbat]

ADL wurde geplant, als Intel noch Hoffnungen hatte, Apple als Kunde zu behalten. Jetzt ist Apple weg und sie haben den Frankenstein im Desktop.

[KarlKastor]

Genau. Intel verbaut 2+8 und die acht Kerne sollen natürlich nur Hintergrundlast bearbeiten.
Die sollen in MT Szenarien natürlich "große Lasten" ausführen.

[Unicous]

Hat sich Ian eigentlich mal detailliert praktisch mit Lakefield beschäftigt?
:confused:

https://www.anandtech.com/show/15877/intel-hybrid-cpu-lakefield-all-you-need-to-know

Mir stellt sich die Frage, ob du das Video überhaupt angeschaut hast. :uponder.

Er ist nämlich nicht nur wegen der Performance skeptisch sondern insbesondere auch wegen der Plattform.

Als "Hybrid"-Plattform die sowohl DDR4 als auch DDR5 unterstützt bei letzterer aber das Ökosystem noch in den Kinderschuhen steckt und es keine Anzeichen gibt, dass sich das in den nächsten Monaten signifikant ändert, stellt sich die Frage ob Alder Lake vorrangig eine DDR4-Plattform ist und man dadurch von Intel im alten Ökosystem gefangen gehalten wird.

DDR5 wie gesagt ist praktisch noch nicht auf dem Markt erschienen. Auch wenn es alle paar Wochen nette PR-Veröffentlichungen gibt, hat noch keiner der großen 3 offiziell die Massenfertigung verkündet. Dass ein eher obskurer chinesischer Hersteller wohl erste Riegel mit Micron Chips herstellt, dabei aber nicht über die JEDEC Spezifikation hinaus geht und man daher mit einem 4800MHz Riegel und 40er Timings rechnen darf dürfte weder Enthusiasten in Verzückung geraten lassen (insbesondere da es DDR4 4800MHz Riegel mit fast halbieren Timings gibt bzw. man Riegel entsprechend übertakten kann) noch Otto Normal Verbraucher dazu bewegen deutlich mehr für eine Plattform auszugeben wenn die Performance-Vorteile unter Umständen von der jeweiligen Applikation abhängen (Latenzabhängig oder Bandbreitenabhängig).
Wie es bei den Mainboardherstellern aussieht ist auch noch fraglich bzw. ist es da sehr still so scheint es.

Mobile sähe das unter Umständen etwas anders aus, aber hier vermutet Cutress, dass Alder Lake sich verschieben könnte, da ein Tiger Lake Refresh ja nun offiziell zu sein scheint:
https://www.anandtech.com/show/16629/intel-confirms-tiger-lake-u-refresh-later-in-2021

Das würde also bedeuten, dass Alder Lake Desktop First ist und das Ökosystem für die Plattform sich noch materialisiert hat.

Im zweiten Teil des Videos spricht er dann den Windows Scheduler an, die Anpassungen die er über die Jahre erhalten hat und fragt sich wie Programme auf zwei verschieden Cores mit unterschiedlichen Leistungsmerkmalen und instruction sets reagieren, wie es mit dem Powerbudget aussieht, ob es zum Beispiel Sinn macht am Ende die kleinen Kerne abzuschalten um bessere und zuverlässigere Performance zu erreichen.

Letztendlich stellt er auch die IPC-Versprechungen in Frage, denn es gibt bislang keinerlei Anhaltspunkte seitens Intel wie diese Steigerungen erreicht werden, außer ganz viel unkonkreter Besserwisserei in den Kommentarspalten so wie ich das mal etwas freier interpretiert habe.:wink:

[BlacKi]

Die little.Cores sind vor allem der Konter auf Apple, also d.h Energieeffizienz in niedrigen Lastszenarien. Die wurden sicherlich nicht für's Gaming eingebaut :freak:

Wie ja das Konzept eigentlich schon verratet, sind die kleinen Cores nicht dazu gedacht grosse Lasten auszuführen. Ich weiss nicht, wie hier manche auf Gaming kommen:confused: Die sind dazu da, den Stromverbrauch auf niedriglast deutlich zu senken bzw. die grossen Cores bei ihrer "eigentlichen" Aufgabe zu entlasten (vom OS etc.).schau dir doch mal die auslastung von heutigen spielen an. von einer gleichmäßigen auslastung sind wir weit entfernt. auch von 8 kernen. die spiele entwickler sind gerade voll dabei die prozesse aufzudröseln, wodurch der hauptprozess entlastet wird. solange die minimalslasten korrekt auf die kleinen kerne ausgelagert werden können, darf man hier 16 kern gaming leistung zu kosten eines 10 kerners mit dem verbrauch eines 10 kerners erwarten.


das prinzip, falls richtig distrubited, setzt gerade beim gaming ihr volles postential frei.


das prinzip ist so genial, zen5 wird ebenfalls biglittle;D
https://videocardz.com/newz/amd-3nm-zen5-apus-codenamed-strix-point-rumored-to-feature-big-little-cores

[w0mbat]

das prinzip ist so genial, zen5 wird ebenfalls biglittle;D
https://videocardz.com/newz/amd-3nm-zen5-apus-codenamed-strix-point-rumored-to-feature-big-little-cores
Genau, ich würde jetzt jedem tweet über Zen5 Glauben schenken ;D

[aufkrawall]

schau dir doch mal die auslastung von heutigen spielen an. von einer gleichmäßigen auslastung sind wir weit entfernt. auch von 8 kernen.

Das ist einfach nur noch falsch, in diversen Spielen ist mit expl. API die CPU-Auslastung >10 Threads in CPU-aufwendigen Szenen durchgängig hoch.
Beispiele: SoTR, Cyberpunk, BFV (RT...), RDR2... -> Und das sind alles Last Gen-Spiele.

Diesen Irrglauben bitte mal aus den Köpfen verbannen und einsehen, dass little.BIG bei so etwas Mist ist. Danke.

[Unicous]

@BlacKi

Das Gerücht bezieht sich explizit auf eine APU. Im Zweifel also eine mobile Plattform. Ob die HP-Chips ein hybrides Kern-Konzept haben kannst du daraus also nicht zwangsläufig extrapolieren.

Der Rest den du geschrieben hast, ist extrem viel Mutmaßung ohne konkret zu werden und zudem sehr viel substanzloses Gefasel. Minimallasten (was auch immer das sein soll:freak:) die Entwickler dröseln gerade Prozesse auf (What? ;D).
Lasten sind zum Teil extrem dynamisch, deswegen springt ein Thread von 0% Auslastung kurzzeitig auf 100% um dann wieder viele, viele Cycles nichts zu tun, während die "Haupt"threads einen großen Teil der Arbeit verrichten. Das "die" Entwickler mittlerweile daran arbeiten, die Lasten gleichmäßiger zu verteilen und mehr Kerne bzw. Threads dabei einzubinden bedeutet aber auch, dass man nicht einfach so sagen kann, ach Kerne 8-15 warum bearbeitet ihr nicht die ganze Zeit diese eher unwichtigen Dinge während Kerne 0-7 die schweren Lasten meistern, insbesondere wenn man weiß, dass es so ein starkes Perfomancegefälle bei den Architekturen gibt.

Bin mir relativ sicher, dass du vor nicht allzu langer Zeit zu der 4 Kerne ist genug Fraktion gezählt hast, jetzt auf einmal ist ein 8+8 Konzept einem 10 Kerner ebenbürtig.:freak:

[Distroia]

Glaubt überhaupt irgendjemand, dass die Little-Cores irgendwas bei Spielen bringen (von Ausnahmen abgesehen)?


solange die minimalslasten korrekt auf die kleinen kerne ausgelagert werden können, darf man hier 16 kern gaming leistung zu kosten eines 10 kerners mit dem verbrauch eines 10 kerners erwarten.



das prinzip, falls richtig distrubited, setzt gerade beim gaming ihr volles postential frei.


Ich wollte eigentlich eher fragen, warum er überhaupt in die Richtung argumentiert, weil sowieso niemand behauptet, dass die kleinen Kerne bei Spielen etwas bringen würden. Aber da gibt es wohl doch jemanden. ;D

"Big.LITTLE" wird bei Spielen höchstwahrscheinlich das neue Hyperthreading, bringt entweder gar nichts oder kostet sogar ein kleines bisschen Leistung, wenn man es nicht abschaltet.

Edit: Ich will big.LITTLE nicht schlechtreden. Es hat seine Daseinsberechtigung, aber eben nicht für Spiele.

[amdfanuwe]

Noch besser: Hatte letztens einen QT Code mit mehreren Threads vorliegen. Dummerweise wurden die nicht korrekt gestartet wodurch alles auf dem gleichen Core lief.

[HOT]

Hat sich Ian eigentlich mal detailliert praktisch mit Lakefield beschäftigt?
Darum geht es auch in dem Video. Er sagt, der große Kern dient eher zu Beschleunigung bestimmter Prozesse, z.B. der flüssigeren Bedienung als um irgendwas anderes. Für ihn ist Lakefield nach wie vor ein Atom-Prozessor, der große Kern ändert daran nix.


Oh, oh. Im schlimmsten Fall bringt das Hardware-Scheduling für Spiele gar nichts und es läuft so im besten Fall auf dem Niveau von 10C CML mit etwas Allcore-OC.
Oder die littles saufen "unerwartet" viel, wenn hoher Takt auf allen Kernen anliegen soll. ;D

Im schlimmsten Fall ist ein 8+0 schneller bei Spielen als ein 8+8.


Nach der News vom Tiger Lake Refresh, also U/H neben H45, und der angesprochenen Probleme mit der Plattform, würde es mich nicht überraschen, dass ALD komplett verschoben wird oder tatsächlich nur die k-Varianten noch dieses Jahr gelauncht werden. Aber das wird primär vom Yield abhängen. bei dem schrottigen Yield vor 5 Monaten war das noch undenkbar einen Massenprozessor in 10nm zu bringen, weil der einfach zu teuer zu produzieren gewesen wär (dazu gibts von Ian ebenfalls ein Video); wie es heute aussieht weiss schlichtweg keiner. Der Löwenanteil ist ja heute immer noch 14nm. Dann gibts ja ein paar Tiger Lakes, die aber ja recht kleine Dies haben.

[davidzo]

Oder die littles saufen "unerwartet" viel, wenn hoher Takt auf allen Kernen anliegen soll. ;D
Gracemont kommt ja auch als Network / 5G CPU, dann ohne die großen Kerne. Wenn dass ein Indikator ist, dann wird das Frequenzwachstum zwar vorhanden sein, aber eher im Rahmen eines normalen Generationensprungs.
Grand-Ridge mit Gracemont Cores kommt auf 2,6Ghz und das in 7HLL+ :eek: Snow Ridge kommt bisher mit Tremont in 10SF bei 2,2Ghz. Turbo gibts bei Network SKUs nicht, es interessiert nur die sustained Leistung bei baseclock.

Im Desktop taktet man dagegen mit dem turbo deutlich über dem Effizienz-sweetspot. Jasper Lake kommt auf 2Ghz base und 3,3Ghz im Turbo. Wenn die kleinen Kerne für Effizienz da sind würde es mich aber wundern wenn man die bis an die Kotzgrenze taktet wenn man doch dafür noch die lake cores hat, die bei niedrigerem takt sogar effizienter sind als die kleinen bei hohem takt.

Alles über 2,6Ghz base und 3,6Ghz Turbo würde mich doch sehr wundern für Gracemont in 10ESF.

Wenn die Gerüchte zur Leistung stimmen, entspricht das 8-Kern Cluster mit ca. 2,6 / 3,6Ghz boost dann "Skylake-Performance", also einem 6700K Quadcore mit 4-4,2Ghz 4C/8T. Das ist ausgehend von tremont schon sehr realistisch, wird aber nicht so viel helfen um einen 5900x geschweige denn 5950x zu schlagen.

[Fusion_Power]

Wenn Intel bei den Grafikkarten eine gute Verfügbarkeit haben, ist das eig. DER Zeitpunkt, um ins Geschäft einzusteigen. Denn schliesslich sind die Preise bei den anderen so kaputt, da muss man nicht mal Konkurrenzfähig sein bezüglich Leistung/Listenpreis.

Eigentlich DIE Chance für Intel, Marktanteile zu gewinnen. Und dass sie eien gute Verfügbarkeit haben können, haben sie ja mit Rocket Lake bewiesen.
Yupp, natürlich vorrausgesetzt Intel kann WIRKLICH GPUs liefern, ich traue in diesen Zeiten diesbezüglich absolut keinem Hersteller. Und natürlich kommts am Ende wie immer auch auf die Treiber an, was nützen uns theoretisch schnelle und preiswerte Grafikkarten wenn die in der Praxis (in Spielen) nix taugen?

Die little.Cores sind vor allem der Konter auf Apple, also d.h Energieeffizienz in niedrigen Lastszenarien. Die wurden sicherlich nicht für's Gaming eingebaut :freak:

Wie ja das Konzept eigentlich schon verratet, sind die kleinen Cores nicht dazu gedacht grosse Lasten auszuführen. Ich weiss nicht, wie hier manche auf Gaming kommen:confused: Die sind dazu da, den Stromverbrauch auf niedriglast deutlich zu senken bzw. die grossen Cores bei ihrer "eigentlichen" Aufgabe zu entlasten (vom OS etc.).
Ich stell mir vor dass auch die Kleinen Cores in Games halt neben den großen ihren Beitrag leisten können, halt für kleine Aufgaben. Wer sagt denn dass die ungenutzt bleiben müssen wenn die großen Cores arbeiten? Oder sie kümmern sich um Hintergrundtasks oder sonstwas.

[Platos]

Da müsste aber eine logik dahinter (ähnlich HT), die regelt, welche Aufgaben viel und welche Aufgaben wenig Last erzeugen.

Ansonsten bremsen die kleinen nur aus. Und diese Logik muss zuerst einmal in Hardware gegossen werden (oder es werden dafür gleich 1 kleiner Kern genommen) und vor allem in Windows gleich mit.

Und wenn ich mir so die "smartheit" bzw. "Modernheit" von Win so ansehe, sehe ich das eher als unwahrscheinlich an.

Zumal die 8 langsamen Kerne (wie gesagt) nicht dazu da sind, viel Rechenleistung zu bringen. Der Zugewinn dürfte minimal sein. M M.n wird man damit die Hintergrundprozesse berechnen und so die grossen Cores entlasten.

Aber mal sehen, vlt. kriegen sie es ja hin und Intel ist dann im Gaming in ein paar Spieen auf einmal deutlich energieeffizienter. In anderen, vor allem eig. praktisch jedem neuen AAA Game wird es dann keinerlei Vorteile haben, da die eig. die Kerne mittlerweile gut Auslasten und dann kann man keine kleine mehr verwenden.

Also ich bleib dabei: Die kleinen Kerne werden m.M.n nach (zumindest vorerst) nicht fürs Gaming benutzt.

[robbitop]

Hat sich Ian eigentlich mal detailliert praktisch mit Lakefield beschäftigt?
IIRC hatte er keinen zum Testen da. Und das ist Schade - denn damit hätte er wenigstens eine Art praktische Grundlage zur Beurteilung. Und spätestens jetzt würde ich mir an seiner Stelle ein Gerät holen, um mal zu schauen, wie gut Intel das bisher gelöst hat.

IMO unterschätzt er die Möglichkeiten des uControllers der CPU. Die haben in den letzten 2-3 Jahren eine Menge Defizite des Windows Schedulers geradegebogen.
Er schließt die Möglichkeit ja auch nicht aus - ist nur skeptisch, wie gut die Heuristik dann zu den Anwendungen und der Variabilität der unterschiedlichen Konstellationen und Erwartungen ist.
Lakefield funktionierte von seiner Heuristik wie erwartet. Andererseits ist der Ansatz bei Lakefield auch etwas anders und somit einfacher.
Dort wird sicherlich über power pro core geschaut, ob man den SC ausknipst und alle 4x TM ackern lässt oder ob es wenige kurze Peaks sind und dann den SC ackern lassen. Die Konstellation stelle ich mir für ADL deutlich komplexer vor. Heißt aber nicht, dass Intel das nicht potentiell genauso gut in den Griff kriegen kann.

:confused:

https://www.anandtech.com/show/15877/intel-hybrid-cpu-lakefield-all-you-need-to-know

Das ist eher eine theoretische Abhandlung. Aber er hat keine HW in der Praxis getestet. Das sollte man IMO schon tun. Er hatte IIRC auch in einem Podcast als Gast geantwortet, dass er Lakefield noch nicht in der Praxis getestet hat mangels Gerät. IMO sollte er das nachholen.

[robbitop]

Glaubt überhaupt irgendjemand, dass die Little-Cores irgendwas bei Spielen bringen (von Ausnahmen abgesehen)? Mehr als 8 Kerne bringen sowieso schon sehr wenig bis gar nichts; ich kann mir eher vorstellen, dass die Little-Cores stören, wenn der Scheduler nicht genau macht, was er machen soll.

Die Little-Cores werden wahrscheinlich den Rückstand im Bezug auf Leistung und Leistungsaufnahme in stark parallelisierbaren Anwendungen verkürzen, mehr aber auch nicht.
Es kommt, die du schreibst, stark darauf an, ob die Littlecores genau das machen können, was sie sollen. Da hat die uFirmware/uController ja heutzutage noch vor dem Scheduler einen großen Einfluss drauf. Sauberer wäre natürlich wenn die SW dafür direkt optimiert wäre (nicht nur der Scheduler sondern auch die Anwendung/das Spiel selbst). Da das kurzfristig schwierig ist, wird es wohl die uFirmware/uController richten müssen.

Viele Anwendungen und Spiele haben ja auch heterogene Threads. Mainthreads, die besonders zeitkritisch sind und eine ganze Menge Nebenthreads.
Wenn 8x Cores ausreichen um alles zu saturieren und keine Auswirkungen auf die Mainthreads haben bringen mehr Cores (auch große) nichts.
Aber sobald Nebenthreads oder Hintergrundprozesse Resourcen von den zeitkritischen Threads in Anspruch nehmen, hat es einen Einfluss.

Man kann dann mehr Cores verbauen oder SMT nutzen. Doppelt so viele Cores statt SMT sind natürlich besser weil SMT eben auch HW Ressourcen vom ersten Thread der CPU in Anspruch nimmt. Ein Little Core, der vor einem SMT Thread benutzt würde, hätte hier sicherlich zumindest ggü SMT potenziell Vorteile.

Also ein Spiel was sagen wir mal 12-16 Threads gut nutzt, würde am besten auf einem 16C laufen aber potenziell auf einem 8+8C (wenn richtig umgesetzt) schneller als auf 8C/16T.
Für Nebenthreads sind die großen Cores ein wenig "Perlen vor die Säue". Man kann also mit weniger Energie und Transistoren die Performance anheben. Das schaufelt ggf (verglichen mit 16c) mehr TDP frei damit die großen Kerne etwas höher Takten können.

Am Ende muss man sehen, wie gut das funktionieren wird.

Gerüchte besagen, dass AMD zu Zen5 ebenfalls heterogenes SMP verbauen will. Angeblich im Verhältnis 8:4. Ich hatte überlegt, ob sie wirklich einen dedizierten Core designen oder lieber einen Zen 2 CCX shrinken und ggf etwas auf low power optimieren (bzw den Zen 2 Kern etwas redesignen für ein wenig niedrigere Taktraten - das macht ihn kleiner und sparsamer). Mal sehen, was kommt. Es bleibt spannend. :)

[Platos]

Das funktioniert aber auch sehr inkonsistent. Manche Spiele werden vlt. 2 Threads eher mässig belasten, andere vlt. 4 Threads und andere vlt. maximal einen (und belasten somit alle anderen relativ stark, so dass die schwachen eher nutzlos sind). Der positive Effekt, der sich dadurch theoretisch erzielen liesse, ist also sehr stark von der Threadnutzung des Spieles abhängig.

Ob 8C+8c zwingend besser ist wie 8C/16T kommt stark auf die kleinen Cores an. Also jenachdem, wie viel die Leisten.

Und selbst wenn es ein Thread gibt, der zwar wenig Last erzeugt auf starken Kernen, bedeutet das nicht, dass die Aufgabe ein langsamer Kern (gut) erledigen kann/sollte. Der langsame Kern wird sehr niedrig getaktet sein und somit diese Aufgabe auch langsam lösen. Evtl. dürfen dann die schnellen Kerne ständig auf die langsamen warten.

Ich denke nicht, dass man in Spielen einfach simple nach Kernauslastung gehen kann. Da kommt es sicherlich sehr darauf an, ob eine Berechnung schnell geschehen muss (auch wenn sie einen schnellen Kern nicht sonderlich stark belastet, muss diese ja trotzdem potentiell möglichst schnell abgearbeitet werden).

[HOT]

IIRC hatte er keinen zum Testen da. Und das ist Schade - denn damit hätte er wenigstens eine Art praktische Grundlage zur Beurteilung. Und spätestens jetzt würde ich mir an seiner Stelle ein Gerät holen, um mal zu schauen, wie gut Intel das bisher gelöst hat.

IMO unterschätzt er die Möglichkeiten des uControllers der CPU. Die haben in den letzten 2-3 Jahren eine Menge Defizite des Windows Schedulers geradegebogen.
Er schließt die Möglichkeit ja auch nicht aus - ist nur skeptisch, wie gut die Heuristik dann zu den Anwendungen und der Variabilität der unterschiedlichen Konstellationen und Erwartungen ist.
Lakefield funktionierte von seiner Heuristik wie erwartet. Andererseits ist der Ansatz bei Lakefield auch etwas anders und somit einfacher.
Dort wird sicherlich über power pro core geschaut, ob man den SC ausknipst und alle 4x TM ackern lässt oder ob es wenige kurze Peaks sind und dann den SC ackern lassen. Die Konstellation stelle ich mir für ADL deutlich komplexer vor. Heißt aber nicht, dass Intel das nicht potentiell genauso gut in den Griff kriegen kann.



Das ist eher eine theoretische Abhandlung. Aber er hat keine HW in der Praxis getestet. Das sollte man IMO schon tun. Er hatte IIRC auch in einem Podcast als Gast geantwortet, dass er Lakefield noch nicht in der Praxis getestet hat mangels Gerät. IMO sollte er das nachholen.

Ich glaub er kann das schon beurteilen, auch ohne das Gerät zu haben.

Es kommt, die du schreibst, stark darauf an, ob die Littlecores genau das machen können, was sie sollen. Da hat die uFirmware/uController ja heutzutage noch vor dem Scheduler einen großen Einfluss drauf. Sauberer wäre natürlich wenn die SW dafür direkt optimiert wäre (nicht nur der Scheduler sondern auch die Anwendung/das Spiel selbst). Da das kurzfristig schwierig ist, wird es wohl die uFirmware/uController richten müssen.

Viele Anwendungen und Spiele haben ja auch heterogene Threads. Mainthreads, die besonders zeitkritisch sind und eine ganze Menge Nebenthreads.
Wenn 8x Cores ausreichen um alles zu saturieren und keine Auswirkungen auf die Mainthreads haben bringen mehr Cores (auch große) nichts.
Aber sobald Nebenthreads oder Hintergrundprozesse Resourcen von den zeitkritischen Threads in Anspruch nehmen, hat es einen Einfluss.

Man kann dann mehr Cores verbauen oder SMT nutzen. Doppelt so viele Cores statt SMT sind natürlich besser weil SMT eben auch HW Ressourcen vom ersten Thread der CPU in Anspruch nimmt. Ein Little Core, der vor einem SMT Thread benutzt würde, hätte hier sicherlich zumindest ggü SMT potenziell Vorteile.

Also ein Spiel was sagen wir mal 12-16 Threads gut nutzt, würde am besten auf einem 16C laufen aber potenziell auf einem 8+8C (wenn richtig umgesetzt) schneller als auf 8C/16T.
Für Nebenthreads sind die großen Cores ein wenig "Perlen vor die Säue". Man kann also mit weniger Energie und Transistoren die Performance anheben. Das schaufelt ggf (verglichen mit 16c) mehr TDP frei damit die großen Kerne etwas höher Takten können.

Am Ende muss man sehen, wie gut das funktionieren wird.

Gerüchte besagen, dass AMD zu Zen5 ebenfalls heterogenes SMP verbauen will. Angeblich im Verhältnis 8:4. Ich hatte überlegt, ob sie wirklich einen dedizierten Core designen oder lieber einen Zen 2 CCX shrinken und ggf etwas auf low power optimieren (bzw den Zen 2 Kern etwas redesignen für ein wenig niedrigere Taktraten - das macht ihn kleiner und sparsamer). Mal sehen, was kommt. Es bleibt spannend. :)

Das ist tolle Theorie, aber in der Praxis macht dir da der Windows Scheduler einfach einen Strich durch die Rechnung. Ich denke, es wird eine Anpassung für ADL geben, die die Little-Cores bei Spielen schlichtweg deaktivieren, damit sie die Laufzeit nicht stören und es wird mMn zwischen 8+8 und 8+0 bei Spielen schlichtweg keinen Unterschied geben. Zen 5 wird 4 Little-Cores verbauen, die im Mobilbetrieb, wie im Mobiltelefon, Strom sparen. Große Zen5 werden nach wie vor bis zu 16 große Cores haben oder man nimmt die Stromsparcores mit in den Desktop. Verdächtig ist eben, dass es nur 4 derer sind. Für eine Performancesteigerung ist 8+4 Unsinn, dass kann nur für Minimallast überhaupt interessant sein.

[davidzo]

Es kommt, die du schreibst, stark darauf an, ob die Littlecores genau das machen können, was sie sollen. Da hat die uFirmware/uController ja heutzutage noch vor dem Scheduler einen großen Einfluss drauf. Sauberer wäre natürlich wenn die SW dafür direkt optimiert wäre (nicht nur der Scheduler sondern auch die Anwendung/das Spiel selbst). Da das kurzfristig schwierig ist, wird es wohl die uFirmware/uController richten müssen.

Da verlangst du aber ganz schön viel von einem Mikrocontroller. Der soll statistische Auswertung eines threads machen, in Echtzeit und diese auswertungen dann auch im cache halten, regelmäßig überprüfen und korrigieren. Threads haben nicht immer denselben workload, z.B. wenn sie spawnen schonmal was ganz anderes. Wenn überhaupt kann so eine Firmware nur mit hoher latenz auf workloadänderungen reagieren, wenn der thread also schon eine weile auf dem falschen core lief und analysiert wurde. Und der Switch auf den anderen Core oder einen anderen Power state wird wieder einiges an Latenz kosten und an Power. Zu häufig sollte er also auch nicht switchen, sonst gibt es overshoot und starke Leistungseinbrüche. Der µC müsste also pro Thread soetwas wie PID autotune machen. Das kostet alles ziemlich viel Zeit und ist nicht besonders genau wenn die Threads nicht voll deterministisch sind.

Es ist viel einfacher das von Treiberseite aus zu machen, wenn man die Anwendungen kennt die gerade im userspace laufen. so wie Grafiktreiber auch eine Erkennung bestimmter Spiele haben und dann das eine oder andere Renderfeature aktivieren. Du musst die Analyse dann nicht aufwändig in echtzeit quasi "reverse engineeren", sondern kannst fein getunte Thread-verhaltens-analysen aus dem Labor einfach mit dem Treiber zusammen ausliefern. Das heißt, wenn der Scheduler eine Treibersache wäre und nicht hardcodet um Betriebssystem hängt.

[robbitop]

Ich glaub er kann das schon beurteilen, auch ohne das Gerät zu haben.
Das ist einfach keine gute Basis. Man sollte sich die Praxis unbedingt anschauen. Egal was für ein Experte man ist und IMO auch unabhängig vom Thema.

------------------------------------

Zu den (berechtigten) Zweifeln von allen:
Man wird abwarten müssen, wie gut es am Ende funktioniert. Ich habe auch meine Zweifel. Aber Lakefield zeigte ja bereits, dass zumindest das was Intel für das Produkt wollte auch so funktioniert. Bei ADL wird es schwieriger.
Ganz abwegig ist es IMO nicht.

[Naitsabes]

Wie macht das denn der Linux Scheduler? big.LITTLE funktioniert dort ja bestens.
Warum sollten ähnliche Mechanismen nicht auch irgendwann Einzug in den Windows Kernel finden? Im Hinblick auf ARM Windows wird das doch früher oder später nötig. Bzw. wie läuft es bereits jetzt auf nem Surface Pro X? Ist ja auch big.LITTLE

[HOT]

Das ist einfach keine gute Basis. Man sollte sich die Praxis unbedingt anschauen. Egal was für ein Experte man ist.
Das mag man so sehen, allerdings ist der glaub ich einfach Experte genug um die Zusammenhänge bewerten zu können. Es hilft natürlich, wenn man das testet, aber dass Anandtech so einen Test nicht online hat, heißt ja auch nicht, dass Ian damit noch nicht gearbeitet hat.

[robbitop]

Das mag man so sehen, allerdings ist der glaub ich einfach Experte genug um die Zusammenhänge bewerten zu können. Es hilft natürlich, wenn man das testet, aber dass Anandtech so einen Test nicht online hat, heißt ja auch nicht, dass Ian damit noch nicht gearbeitet hat.
Nochmal: Ian hat es neulich in einem Podcast gesagt, dass er Lakefield noch nicht getestet hat. Und er sagt ja selbst in den Videos, dass ihm noch nicht klar ist, wie Intel das im Detail lösen will.

Ich finde man darf nicht generell die Aussagen renormierter Leute nur aufgrund ihres Namens mehr Kredibilität schenken als wenn das nicht der Fall wäre. Jede These braucht vollständig schlüssige Argumente (die man auch anzweifeln darf) und am Ende auch Belege. Denn nur ein Beleg kann schlüssig Gegenargumente entkräften.

"XYZ ist ein Experte und wird es schon wissen" ist mMn dünn und keine besonders gute Lebenseinstellung. Ehrlich gesagt ist das sogar eine ziemlich schwache Einstellung.
Oft genug haben sich Experten (auch in diesen spezifischen Themen) schon geirrt. Sind ja auch nur Menschen. Zumal Ian ja zugibt, es nicht genau zu wissen. Er äußert lediglich Zweifel - sagt aber nicht mit absoluter Gewissheit, dass das prinzipbedingt nicht funktionieren kann. Und das ist ein deutlicher Unterschied.

[Gipsel]

Das Hauptproblem bei den kleinen Kernen von Alderlake im Desktop ist vermutlich, daß AMDs Kerne recht gut zu relativ niedrigen Verbräuchen (sagen wir mal 1-2W pro Kern) skalieren. Ein Zen3-Kern auf 2W haut vermutlich jeden Gracemont-Kern weg. Damit bleibt nur der geringere Flächenverbrauch als Argument. Da AMD aber relativ sparsam mit der Chipfläche umgeht (ein Zen3-Kern ist ja offenbar kleiner als ein WillowCove Kern und Alderlakes GoldenCoves werden nochmal größer), können die sich das auch erlauben (mal abgesehen vom Chiplet-Ansatz).
Im Notebook sind die kleinen Kerne wegen geringerem Verbrauch sowohl bei niedriger Last oder allcore-Volllast (auf den kleinen Kernen) für intel vermutlich ziemlich hilfreich (weil die großen Kerne von intel recht durstig sind und schlechter zu niedrigen Verbräuchen skalieren als AMDs Kerne [bei allcore Volllast müßten z.B. 8-Kerner absurd niedrig takten um z.B. innerhalb von 15W zu bleiben; müssen die Vierkerner ja schon bald]). Im Desktop sinken die Vorteile dagegen wegen dem höheren Powerbudget. Und wenn ein 8+8 Alderlake an einen 12Kerner von AMD rankommen würde, hätte intel schon was gewonnen. Zu mehr wird es wohl nicht reichen. In dem Zusammenhang ist es ja auch hilfreich, daß Gracemont zumindest AVX2 unterstützt. Denn bei aktiven kleinen Kernen, werden wohl alle Befehlssatzerweiterungen auf die Fähigkeiten von Gracemont beschränkt (AVX512 wird also nur gehen, wenn die kleinen kerne deaktiviert sind, das ist Teil des Problems mit dem Scheduler).

[robbitop]

Wobei ein guter Tell der kleineren Fläche für die Kerne die bessere Packdichte kommt. AMDs layouting tools scheinn aktuell in der Hinsicht deutlich mehr Packdichte zu schaffen.

Bzgl Energie. Ggf wird sich das ja mit zukünftigen Kernen auch ändern. Also wesentlich breiter und schneller und die bisherigen Kerne bzw dessen Breite als little cores. Food for thought?

[HOT]

Halten wir also fest: Intel handelt sich alle Nachteile dieser Lösung ein, wärend AMD keine dieser Nachteile hat und keinen Nachteil ggü. Intels Big/Little hinnehmen muss.

robbitop
Im Normalfall stimme ich dir zu, hier aber nicht. Ich vertraue Ians Urteil dahingehend schlichtweg mehr. Und die Tatsache, dass Lakefield eigentlich gescheitert ist, unterstreicht dieses.

[robbitop]

Ich finde deine Aussage zu undifferenziert.

1.) Es ging nicht um einen kommerziellen Erfolg Lakefields sondern darum ob die Kernallokation so funktioniert hat, wie es Intel‘s Intension (gemäß Pressedeck) war. Und genau das war der Fall. Und es geht darum, ob Ian es sich in der Praxis angeguckt hat und das hat er nicht. Zumindest wäre eine Untersuchung Lakefields sinnvoll gewesen, um erste Rückschlüsse zu ziehen.

2.) Hat Ian NICHT gesagt, dass ADL mit gemischten Kernen definitiv nicht funktionieren wird. Er hat es offen gelassen. Er hat nur Zweifel angemeldet.

„Ian wird‘s schon wissen“ ist nach diesen Aussagen leider ein sehr dünnes Brett zum Bohren.

Nochmal: ich will damit nicht das Gegenteil sagen. Sondern nur, dass man es nicht sicher wissen kann und abwarten sollte, bevor man ein Urteil fällt. Intel hat die offenbar für Jahre ihre Produktpalette auf big little aufgebaut. Ob man das ohne ein gewisses Maß an Vertrauen in seine Untersuchungen und interne Simulationen getan hätte?

———————-

Zu AMD: Stand heute hat kein heterogenes SMP wie Intel es zu ADL plant. Es sieht aber so aus als hätte man genau das zu Zen 5 in 2023/24 vor. Ein Indiz, dass es ggf doch funktionieren kann, wenn beide IHVs das vorhaben.

Auch AMD wird die Kerne über lang oder kurz breiter machen müssen, um die pro Core Performance zu steigern. Entsprechend ist dann ein kleiner Core zum Zurückbalancieren ggf sinnvoll.
Ob man dafür einen extra Core von Grund auf designen muss oder ob man einfach einen Zen2/3 nehmen kann, der in 3nm super energieeffizient sein könnte bei moderaten Frequenzen, ist die Frage.

[davidzo]

Halten wir also fest: Intel handelt sich alle Nachteile dieser Lösung ein, wärend AMD keine dieser Nachteile hat und keinen Nachteil ggü. Intels Big/Little hinnehmen muss.

robbitop
Im Normalfall stimme ich dir zu, hier aber nicht. Ich vertraue Ians Urteil dahingehend schlichtweg mehr. Und die Tatsache, dass Lakefield eigentlich gescheitert ist, unterstreicht dieses.

Nicht nur er, auch andere Engineers die sich damit beschäftigt haben halten das für einen Marketing-Move bzw. engineering-by Bean-counters genau wie das Gigahurts Rennen beim Pentium4 damals. Nur um die theoretische Leistung schönzurechnen und einen hohen Corecount fürs Marketing zu bekommen.


Francois Piednoel, Ingineer von Conroe, und ausgerechnet derjenige der mit Baytrail Out-of-order-Execution und die erste brauchbare Atom-Architektur eingeführt hat:
I am sorry to tell you that big.LITTLE on x86 is not going to provide the return on investment excel was projecting...
��
https://webcache.googleusercontent.com/search?q=cache:djeanzdT-qkJ:https://twitter.com/i/web/status/1369429800218202119+&cd=3&hl=en&ct=clnk&gl=de&client=opera

Gerade der Excel Seitenhieb ist ein Fingerzeig darauf von welcher Seite die Entscheidung für Big Little in seinen Augen angestrengt wurde. Excel, das ist das Lieblingstool der Business und finance Guys, nicht das der Hardware Developer.


Joe Macri product CTO von AMD:

We've been studying big.LITTLE, it's been 15+ years, so this is not a new concept in any way shape or form. We continue to study it, we continue to look at it.(...)
Is the goal just marketing, 'I want more core count', regardless of what it does for the other two variables?
(...)
Just driving up the core count with little isn't going to be that useful until software comes along,(...)
I think there will be a point when we are going to need LITTLE, and it will be a point in time when the OS has the right attributes, the right capabilities in its scheduler and memory allocator, we'll have the right memory subsystem.
Er rechnet nicht damit dass die Software in den nächsten Jahren ansatzweise so weit ist, schließt es aber für die Zukunft auch nicht aus.

Es ist allein schon einige Arbeit das überhaupt zum laufen zu bekommen, geschweige denn performance benefits. Gerade bei Mobile CPUs mit ihren power tables, etc. Wie stellst du zum Beispiel sicher dass die Software nicht zum Beispiel beim Boot und Laden der Treiber ein Kernelmodul lädt das Befehlssätze verwendet welche der aktive Kern gar nicht unterstützt? Das wird fun, testing testing testing und wenn man fertig ist kann man von vorne anfangen, denn software ändert sich auch...
On Linux (x86) the boot CPU is assumed to be homogeneous with all others. Doing enablement will be fun, but not impossible, and a good excuse at cleanup. Key is making sure things like your cache line size, and ISA features don't differ
https://twitter.com/jonmasters/status/1164243744117465088

[Distroia]

I am sorry to tell you that big.LITTLE on x86 is not going to provide the return on investment excel was projecting...

Funktioniert big.LITTLE aus irgendeinem Grund auf ARM besser als auf x86?

[MiamiNice]

Bei all dem theoretischen Fachgesimpel hier, wird imo gerne vergessen, das kaum jemand derart viele Kerne im Desktop braucht, wie AMD derzeit anbietet. Da mehr Kerne auch Nachteile haben, nicht nur speziell wie bei AMD durch die Chiplet Problematik, sondern auch ganz generell -> TDP, kann das Intel Gerät durchaus brauchbar werden. Wie brauchbar es wird, wird der Windows oder Hardware Sheduler entscheiden.

Wer das Ding jetzt schon abschreibt, hat, imo, nicht zu Ende gedacht. Sich darüber jetzt schon negativ auszulassen, ist doch bloß Fanboi Gewäsch.

[w0mbat]

Jetzt machst du keinen Sinn. ADL kommt mit 16 Kernen, soviel wie AMD.

[MiamiNice]

Ist ja nicht ganz richtig. ADL kommt mit 8 dicken und 8 kleinen Kernen.

[Savay]

Bei Intel brauchen die Dicken Cores unter absoluter Volllast aber auch durchaus fast 50%+ mehr als ein Zen3 Core...und damit meine ich jetzt die 10nm Versionen...über RKL decken wir da mal generell schön das Mäntelchen des Schweigens.
Das ist auch der Grund warum die die Littles auch im Desktop brauchen...nicht weil viele Kerne generell ein "TDP" Problem hätten...sondern weil deren Cove Cores einfach nur ziemlich versoffen sind und deren TDP Budget ruck zuck wegnuckeln und ab einer gewissen Grenze dann das hinzufügen von Kernen gradezu ad absurdum führt.

Das sieht man ja heute schon wenn man nen 8C Cezanne unter ST mit 4C Ice und TigerLake vergleicht in der 15W und 25/28W Konfiguration. :ulol:

Der vergleich zu AMD ist da schon wirklich leicht lächerlich, erst recht wenn man dann noch Kram ala "Chipletproblematik" vom Stapel lässt und von irgendwelchen Fanboys fantasiert.

[Distroia]

Bei all dem theoretischen Fachgesimpel hier, wird imo gerne vergessen, das kaum jemand derart viele Kerne im Desktop braucht, wie AMD derzeit anbietet. Da mehr Kerne auch Nachteile haben, nicht nur speziell wie bei AMD durch die Chiplet Problematik, sondern auch ganz generell -> TDP, kann das Intel Gerät durchaus brauchbar werden. Wie brauchbar es wird, wird der Windows oder Hardware Sheduler entscheiden.

Man hat mehr Kerne im Desktop als man braucht und deswegen soll ein Konzept, das gerade da funktioniert wo man mehr Kerne braucht, Vorteile bringen? :confused:

[HPVD]

Funktioniert big.LITTLE aus irgendeinem Grund auf ARM besser als auf x86?

genau DAS ist die Frage.

Oder sind es einfach die Einsatzfälle bei den Arm basierten Devices mit big little (Smartphones), die so wenig leistungshungrig aber kontinuierlich sind, dass die kleinen Kerne perfekt dafür sind??
Stichwort "Standby" also ohne direkte Nutzerinteraktion aber beschäftigt mit
- Nachrichten empfangen,
- Netzumbuchungen (wenn das in Software läuft),
- neuerdings auf Sprachbefehle warten,
- Musik streamen
- etc
?
(da sich große Kerne selbst wenn für diesen minimalen Leistungsbedarf max tief getaktet mehr verbrauchen)

Wenn Notebooks jetzt/zukünftig auch "always on" sind, haben sie vielleicht auch ein ähnliches Nutzungsprofil und es würde Sinn machen...

Bei Desktops jedoch..

[Distroia]

genau DAS ist die Frage.

Oder sind es einfach die Einsatzfälle bei den Arm basierten Devices mit big little (Smartphones), die so wenig leistungshungrig aber kontinuierlich sind, dass die kleinen Kerne perfekt dafür sind??
Stichwort "Standby" also ohne direkte Nutzerinteraktion aber beschäftigt mit
- Nachrichten empfangen,
- Netzumbuchungen (wenn das in Software läuft),
- neuerdings auf Sprachbefehle warten,
- Musik streamen
- etc
?
(da sich große Kerne selbst wenn für diesen minimalen Leistungsbedarf max tief getaktet mehr verbrauchen)

Wenn Notebooks jetzt/zukünftig auch "always on" sind, haben sie vielleicht auch ein ähnliches Nutzungsprofil und es würde Sinn machen...

Bei Desktops jedoch..

Das eine schließt das andere ja nicht aus, deine Einzelfälle sind sicher gute Gründe für den Vergleich zwischen Mobile und Desktop, aber es könnte zusätzlich noch ein Grund im Vergleich zwischen der ARM- und x86-Archtitektur selbst liegen.

[Freestaler]

Ja aber mal ernsthaft, wir diskutieren vermutlich im Bereich unter 2 Watt wo die ganze Hütte ja im Idle sowieso 10 Watt zieht. BigLittle im Desktop ist mMn. nichts als Resteverwertung.

[davidzo]

Bei Intel brauchen die Dicken Cores unter absoluter Volllast aber auch durchaus fast 50%+ mehr als ein Zen3 Core...und damit meine ich jetzt die 10nm Versionen...über RKL decken wir da mal generell schön das Mäntelchen des Schweigens.
Das ist auch der Grund warum die die Littles auch im Desktop brauchen...nicht weil viele Kerne generell ein "TDP" Problem hätten...sondern weil deren Cove Cores einfach nur ziemlich versoffen sind und deren TDP Budget ruck zuck wegnuckeln und ab einer gewissen Grenze dann das hinzufügen von Kernen gradezu ad absurdum führt.

Das sieht man ja heute schon wenn man nen 8C Cezanne unter ST mit 4C Ice und TigerLake vergleicht in der 15W und 25/28W Konfiguration. :ulol:

Der vergleich zu AMD ist da schon wirklich leicht lächerlich, erst recht wenn man dann noch Kram ala "Chipletproblematik" vom Stapel lässt und von irgendwelchen Fanboys fantasiert.

Die hat man aber auch dahin gezüchtet. Auch Skylake war einmal eine sehr effiziente Architektur und sah bis Ryzen 2000 auch sehr gut aus, bevor man die mit dem Baseclock über 4Ghz geprügelt hat.


Ich kann mich nich gut erinnern als ivy bridge einen großen Sprung an energieeffiziez gebracht hat, haswell dann mehr IPC im gleichen verbrauch und Broadwell einfach geglänzt hat gegenüber AMD. Ich habe hier ein Macbook mit 5257U und das kommt selten über 15W trotz möglicher 28W TDP. Mit dem intel power gadget kann ich da sehen dass die einzelnen cores auch unter Last bei baseclock nicht mehr als 2,5Watt verbrauchen, dazu uncore und SI, zusammen ist das ein sehr effizientes Paket.
Skylake war da nicht viel schlechter. Nur die Taktraten auf die man den geprügelt hat, zusammen mit den 14nm Prozessveränderungen um diese möglich zu machen haben daraus so eine saufnase gemacht.

Icelake und Tigerlake haben imo auch kein verbrauchsproblem, sondern ein Taktproblem. Die sind auch weit jenseits des Effizienzoptimums getaktet. Wenn die mit rund 2Ghz laufen und nicht gerade AVX512 Last anliegt sind die locker so effizient wie AMDs 7nm Cezanne cores, nur schaffen die eben 3-3,5Ghz bei angemessenem verbrauch, weshalb intel diesen schritt zu gehen gezwungen war.

Sicher war nicht geplant dass die so schlecht takten bzw. der sweetspot so weit unten liegt, aber es gibt betriebsmodi in denen man durchaus sehr effizient sein kann, nicht nur beim absoluten verbrauch, sondern auch power /Watt.



Ein großer Stromfresser der Lake Cores ist die für AVX512 aufgebohrte FPU die man aus den Xeons übernommen hat. Das war mal als Konkurrenz zu GPU Computing gedacht, den Kampf hat man aber längst verloren, bzw. baut ja jetzt selber GPUs.
Alderlake ist die erste Architektur die einen signifikanten Rückbau der stomfressenden FPUs beinhaltet. VNNI und Co bleiben, das betrifft also nicht alle neueren lake Instructions.

[BlacKi]

genau DAS ist die Frage.

Oder sind es einfach die Einsatzfälle bei den Arm basierten Devices mit big little (Smartphones), die so wenig leistungshungrig aber kontinuierlich sind, dass die kleinen Kerne perfekt dafür sind??
Stichwort "Standby" also ohne direkte Nutzerinteraktion aber beschäftigt mit
- Nachrichten empfangen,
- Netzumbuchungen (wenn das in Software läuft),
- neuerdings auf Sprachbefehle warten,
- Musik streamen
- etc
?
(da sich große Kerne selbst wenn für diesen minimalen Leistungsbedarf max tief getaktet mehr verbrauchen)

Wenn Notebooks jetzt/zukünftig auch "always on" sind, haben sie vielleicht auch ein ähnliches Nutzungsprofil und es würde Sinn machen...

Bei Desktops jedoch..big little soll im desktop ganz andere aufgaben erfüllen. man führt hier big little nicht nach altem schema ein, sondern will das die beiden architekturen gleichzeitig arbeiten. wenn es funktioniert, könnte es die effizienz steigern. wenn nicht, dann ist das prinzip für den arsch und intel hätte es schon lange gecancelt.

würde es nicht funktionieren, würde uns 8-12 kerne golden cove vorgesetzt werden mit allen nachteilen. da das nicht passiert, sondern adl kommt wie geplant, wird adl so funzen wie geplant.

so IMHO.

[robbitop]

Ggf kann man schon durch einen sehr statischen Allokationsalgorithmus die Performance erhöhen:
1. Fülle erst die 8x großen Cores
2. fülle dann die 8x kleinen Cores
3. fülle zuletzt smt threads der großen Cores (3b sollten little cores irgendwannmal smt haben dann fülle die smt threads der kleinen cores nach den smt threads der großen)

Ähnlich wie man das bei der Bulldozerfamilie gemacht hat. Fülle erst Thread 0 jedes Moduls von allen Modulen und erst danach Thread 1. Das hat ja funktioniert.

Das würde ggf im Desktop die Performance in so ziemlich allen Anwendungen positiv beeinflussen, die mehr als 8x threads haben. Natürlich sind dort 16 big cores aber besser. :)

[genervt]

Mein Wissen über ARM Architektur ist begrenzt. Ich sehe, dass BIG.little dort erfolgreich zum Strom sparen eingesetzt wird und offenbar - sehen kann ich es nicht - Hintergrundprozesse brav auf den littles laufen.
Generell sehe ich nicht, warum das nicht auch im Desktop möglich sein soll. Es gibt genügend Hintergrundprozesse allein schon von Windows, die nicht auf einm großen Core laufen müssen.

Bezüglich AMD und Intel sehe ich unterschiedliche Motivationen den Weg zu gehen und auch mit unterschiedlichem Ansatz.
Intel muss den Core count von AMD wenigstens nominell auch bieten. Ihre Cove Cores sind jedoch power hungrig und groß. daher nutzen sie für die littles eine eigene Arch.

AMD hat kleine Cores stößt im Mobile jedoch mit dem momolithoschen Ansatz der APUs an Grenzen und konnte bisher die top Akkulaufzeit von Intel nicht bieten.
Da sehe ich bei AMD durchaus Möglichkeit zur Optimierung. Ein wie auch immer beschnittener Zen2 oder Zen3 Core auf Strom sparen optimiert für längere Laufzeit als little siehe Schnitte PS5.

Die Herausforderung wäre für beide Unternehmen, dass der Scheduler mitspielen muss. Und ich denke da an Eigenheiten wie das Thread hopping, dass man dann nur innerhalb von BIG Oder little Cores haben will, um z.B. die BIG Cores nicht zu wecken.

Ob das jetzt im Highend Desktop irgendeinen Sinn ergibt wage ich jedoch zu bezweifeln.

[BlacKi]

Ggf kann man schon durch einen sehr statischen Allokationsalgorithmus die Performance erhöhen:
1. Fülle erst die 8x großen Cores
2. fülle dann die 8x kleinen Cores
3. fülle zuletzt smt threads der großen Cores (3b sollten little cores irgendwannmal smt haben dann fülle die smt threads der kleinen cores nach den smt threads der großen)

Ähnlich wie man das bei der Bulldozerfamilie gemacht hat. Fülle erst Thread 0 jedes Moduls von allen Modulen und erst danach Thread 1. Das hat ja funktioniert.

Das würde ggf im Desktop die Performance in so ziemlich allen Anwendungen positiv beeinflussen, die mehr als 8x threads haben. Natürlich sind dort 16 big cores aber besser. :)auf dem desktop mit max performance preset ja, aber es macht durchaus sinn auf dem preset balanced oder energie sparen zuerst die kleinen kerne zu nutzen, gerade auf dem laptop.

Funktioniert big.LITTLE aus irgendeinem Grund auf ARM besser als auf x86?

eigentlich könnte man das auch jetzt schon testen, wie sich das big little prinzip auf dem desktop verhalten würde. man nehme einen 16 kerner und takte 8 kerne um die hälfte runter(ja die kerne wären noch groß, aber die performance würde nur noch die hälfte betragen) und vergleiche die performance mit einem 12 kerner mit vollem takt(auch gerne den stromverbrauch 12 vs 8+8 mit protokolieren). am besten mit dem selben 16 kerner umd ungenauigkeiten zu vermeiden.

mich würde das echt interessieren ob das nicht jetzt schon vorteile bringt.

[Mangel76]

eigentlich könnte man das auch jetzt schon testen, wie sich das big little prinzip auf dem desktop verhalten würde. man nehme einen 16 kerner und takte 8 kerne um die hälfte runter(ja die kerne wären noch groß, aber die performance würde nur noch die hälfte betragen) und vergleiche die performance mit einem 12 kerner mit vollem takt(auch gerne den stromverbrauch 12 vs 8+8 mit protokolieren). am besten mit dem selben 16 kerner umd ungenauigkeiten zu vermeiden.

Dazu müsste aber Windows irgendwie zwischen langsamen und schnellen Kernen unterscheiden. Wird rein zufällig verteilt, wird die Leistung stark schwanken. Gibt es so etwas im Sheduler? Bei ZEN gibt es ja immerhin prefered cores im CCD. Aber ist reines runtertakten für das OS erkennbar?

[MiamiNice]

Man hat mehr Kerne im Desktop als man braucht und deswegen soll ein Konzept, das gerade da funktioniert wo man mehr Kerne braucht, Vorteile bringen? :confused:

Nein. Es bringt Vorteile weil man 8 große Kerne noch weiter beschleunigen kann, mehr Kerne braucht man aktuell nicht, zusätzlich hält man diese 8 fetten Kerne von „Arbeit“ frei, für die sie nicht gebaut wurde.

€: Wenn die dicken Kerne nur 10% schneller sind als das was AMD zu dieser Zeit liefern kann - ist der ganze Drops einfach so gelutscht im Desktop.

[fondness]

Das Hauptproblem bei den kleinen Kernen von Alderlake im Desktop ist vermutlich, daß AMDs Kerne recht gut zu relativ niedrigen Verbräuchen (sagen wir mal 1-2W pro Kern) skalieren. Ein Zen3-Kern auf 2W haut vermutlich jeden Gracemont-Kern weg. Damit bleibt nur der geringere Flächenverbrauch als Argument. Da AMD aber relativ sparsam mit der Chipfläche umgeht (ein Zen3-Kern ist ja offenbar kleiner als ein WillowCove Kern und Alderlakes GoldenCoves werden nochmal größer), können die sich das auch erlauben (mal abgesehen vom Chiplet-Ansatz).
Im Notebook sind die kleinen Kerne wegen geringerem Verbrauch sowohl bei niedriger Last oder allcore-Volllast (auf den kleinen Kernen) für intel vermutlich ziemlich hilfreich (weil die großen Kerne von intel recht durstig sind und schlechter zu niedrigen Verbräuchen skalieren als AMDs Kerne [bei allcore Volllast müßten z.B. 8-Kerner absurd niedrig takten um z.B. innerhalb von 15W zu bleiben; müssen die Vierkerner ja schon bald]). Im Desktop sinken die Vorteile dagegen wegen dem höheren Powerbudget. Und wenn ein 8+8 Alderlake an einen 12Kerner von AMD rankommen würde, hätte intel schon was gewonnen. Zu mehr wird es wohl nicht reichen. In dem Zusammenhang ist es ja auch hilfreich, daß Gracemont zumindest AVX2 unterstützt. Denn bei aktiven kleinen Kernen, werden wohl alle Befehlssatzerweiterungen auf die Fähigkeiten von Gracemont beschränkt (AVX512 wird also nur gehen, wenn die kleinen kerne deaktiviert sind, das ist Teil des Problems mit dem Scheduler).

Richtig, das ist das Hauptproblem. Wenn ich mit 8+8 gegen 16+0 antrete, kann das nur aufgehen, wenn die big Cores von Intel erheblich schneller sind als die big Cores von AMD. Ansonsten habe ich etwas falsch gemacht. Da der Fertigungsprozess auch vergleichbar sein wird, wird man sehen ob die Rechnung für Intel aufgeht. Sie können jetzt jedenfalls alles zeigen, was sie die letzten Jahre seit Skylake angeblich zurück halten mussten aufgrund des 10nm Prozesses. Ergo 6 Jahre Entwicklung plus big.LITTLE. Eigentlich wäre alles andere als ein klarer Sieg eine Enttäuschung, immerhin würde es bedeuten, dass AMD aus der fast Pleite heraus Intel auch RnD mäßig überholt oder zumindest eingeholt hat. Da dürfte man sich dann schon zurecht die Frage stellen, was dort eigentlich die letzten Jahre passiert ist.

Bei all dem theoretischen Fachgesimpel hier, wird imo gerne vergessen, das kaum jemand derart viele Kerne im Desktop braucht, wie AMD derzeit anbietet. Da mehr Kerne auch Nachteile haben, nicht nur speziell wie bei AMD durch die Chiplet Problematik, sondern auch ganz generell -> TDP, kann das Intel Gerät durchaus brauchbar werden. Wie brauchbar es wird, wird der Windows oder Hardware Sheduler entscheiden.


Das ist ein Henne/Ei-Problem. Mehr Kerne können erst dann von Entwicklern sinnvoll verwendet werden, wenn die HW-Basis vorhanden ist. Ergo soll Intel endlich aus dem Winterschlaf erwachen und die Entwicklung nicht noch länger aufhalten. Wir wären wohl heute noch bei 4 Cores wenn es nach Intel gehen würde.

[BlacKi]

Dazu müsste aber Windows irgendwie zwischen langsamen und schnellen Kernen unterscheiden. Wird rein zufällig verteilt, wird die Leistung stark schwanken. Gibt es so etwas im Sheduler? Bei ZEN gibt es ja immerhin prefered cores im CCD. Aber ist reines runtertakten für das OS erkennbar?


imho ist das schon jetzt möglich. die letzten 2 gens von amd haben viele kerne mit unterschiedlichen taktraten. wäre das so wie früher, also meinem haswell e(ich konnte da 2 kerne mit 4,6ghz 3x mit 4,5 und 1x mit 4,4 betreiben), würde die performance dem langsamsten kern entsprechen. das scheint bei der 3000er und 5000er serie von amd cpus schon nicht mehr der fall zu sein, da es schnellere und langsamere kerne gibt.

mein mainboard lässt leider keine einzelne steuerung von cpu kernen mehr zu, sonst würde ich das erneut testen.

Richtig, das ist das Hauptproblem. Wenn ich mit 8+8 gegen 16+0 antrete, kann das nur aufgehen, wenn die big Cores von Intel erheblich schneller sind als die big Cores von AMD. Ansonsten habe ich etwas falsch gemacht.
der 8+8 wird aber keine 800-900€ cpu.

[Virtual]

Ggf kann man schon durch einen sehr statischen Allokationsalgorithmus die Performance erhöhen:
1. Fülle erst die 8x großen Cores
2. fülle dann die 8x kleinen Cores
3. fülle zuletzt smt threads der großen Cores (3b sollten little cores irgendwannmal smt haben dann fülle die smt threads der kleinen cores nach den smt threads der großen)

Ähnlich wie man das bei der Bulldozerfamilie gemacht hat. Fülle erst Thread 0 jedes Moduls von allen Modulen und erst danach Thread 1. Das hat ja funktioniert.

Das würde ggf im Desktop die Performance in so ziemlich allen Anwendungen positiv beeinflussen, die mehr als 8x threads haben. Natürlich sind dort 16 big cores aber besser. :)
Du versuchst unentwegt ein technisches Problem zu mitigieren, das Intel im Kontext eines Windows-Desktop in 2021/2022 eher notgedrungen herbeigeführt.
Zumindest für den Zocker mit geringem technischen Verständnis ist Intels Big.Little Version weniger vorteilhaft als vielmehr irreführend.
Dein Vergleich mit Bulldozer ist trotzdem gut gewählt, nur triffst du den entscheidenden Punkt nicht. Wie damals für AMD ist der doppelten Core-Count für Intel zunächst nur im Marketing wirkungsvoll.
16 ausgewachsene Cove-Kerne in Intels 10nm bei 5 GHz (als Marketing-Pflicht) sind auf einem Die kaum darstellbar, werden aber vom Marketing als "vergleichbares" Produkt zu AMDs HighEnd-Desktop Systemen benötigt.
Als ob das für Intel nicht schon "Notlage" genug wäre, drängen heterogene Multicore Systeme der ARM-Fraktion zunehmend in den klassischen Markt der mobilen x64 Systeme. Als Ausweg aus diese Lage versucht Intel sich nun an einen technischen Spagat.

Intels Ansatz dürfte in einigen Jahren auch für den Desktop Pflicht werden, aber für das primäre Nutzungprofil eines Zockers ist es in 2021/2022 einfach nur ein technisches Problem, das ZEN4 nicht haben wird.

[robbitop]

Unabhängig von ADL kann big little schon aufgehen. Für sehr sehe gute Skalierung der Anwendung kann man ja auch einfach wesentlich mehr little Cores verbauen. Man bekommt für gleiches Flächenbudget je nach Auslegung zwischen 2-4 little cores für einen big core. Entsprechend mehr davon könnte man für pures MT verbauen.

Und in die andere Richtung kann man für Anwendungen die nur begrenzt paralleliserbar sind möglichst breite und schnelle Kerne nutzen.

Das wäre the right tool for the right job. IMO ist die Perspektive dazu heute noch nicht die richtige. Weil die meisten Zen 3 bspw als big core sehen.
Ich kann mir vorstellen, dass Zen5 oder 6 deutlich breiter und schneller sind. M1 zeigt ja was noch mindestens pro Takt möglich ist. Man stelle sich einen breiten Kern vor, der pro Takt 50-80% schneller ist. Das ist mittelfristig nicht unmöglich. Aber es kann gut sein, dass das kombiniert mit hohen Taktraten mittelfristig einfach mit deutlich erhöhtem Energiebedarf verbunden ist. Man braucht dann nur so viele zu verbauen dass die Anwendungen die begrenzt parallilisierbar sind von denen ausreichend zur Verfügung haben. Sagen wir 8-12. Und dazu dann noch eine ganze Menge Little Cores für MT. zB 16-24.

In Zeithorizont von 5-10 Jahren mit etwas Weitblick gedacht.

[Thunder99]

Nicht alles lässt sich parallelisieren.

Denke Intel ist auch deswegen zu diesem Schritt gezwungen um überhaupt die Kerne zu erhöhen. Zen Kerne sind einfach zu stark und flexibel. So was haben sie derzeit einfach nicht.

Und wegen dem Scheduler würde ich da nicht mir so den Kopf zerbrechen. Reicht es da nicht einfach zu definieren was Vordergrund und Hintergrund Prozeß ist und entsprechend die Kerne dazu zu nutzen? Erst bei massiven Kern Bedarf kommen dann beim Vordergrundprozess die Kleinen Kerne auch hinzu.

[BlacKi]

Nicht alles lässt sich parallelisieren.

Denke Intel ist auch deswegen zu diesem Schritt gezwungen um überhaupt die Kerne zu erhöhen. Zen Kerne sind einfach zu stark und flexibel. So was haben sie derzeit einfach nicht.

Und wegen dem Scheduler würde ich da nicht mir so den Kopf zerbrechen. Reicht es da nicht einfach zu definieren was Vordergrund und Hintergrund Prozeß ist und entsprechend die Kerne dazu zu nutzen? Erst bei massiven Kern Bedarf kommen dann beim Vordergrundprozess die Kleinen Kerne auch hinzu.


die kernzahl zu erhöhen ist garkein problem. intel könnte locker 24 kerne bringen(weglassen der igpu) und einfach den verbrauch über die tdp begrenzen. aber das ist einfach zu teuer, wegen der siliziumfläche. biglittle ist hier der ansatz um fläche zu sparen, und natürlich auch die effizienz zu erhöhen.

[CrazyIvan]

@robbitop
Sehe ich genau so. Auch teile ich Deine Einschätzung, dass ZEN 2/3 für AMD langfristig als little Core herhalten könnte. Die Effizienz im <3Ghz Bereich ist bei Renoir und Cézanne heute bereits der Wahnsinn.

[Virtual]

Unabhängig von ADL kann big little schon aufgehen. Für sehr sehe gute Skalierung der Anwendung kann man ja auch einfach wesentlich mehr little Cores verbauen. Man bekommt für gleiches Flächenbudget je nach Auslegung zwischen 2-4 little cores für einen big core. Entsprechend mehr davon könnte man für pures MT verbauen.

Und in die andere Richtung kann man für Anwendungen die nur begrenzt paralleliserbar sind möglichst breite und schnelle Kerne nutzen.

Das wäre the right tool for the right job. IMO ist die Perspektive dazu heute noch nicht die richtige. Weil die meisten Zen 3 bspw als big core sehen.
Ich kann mir vorstellen, dass Zen5 oder 6 deutlich breiter und schneller sind. M1 zeigt ja was noch mindestens pro Takt möglich ist. Man stelle sich einen breiten Kern vor, der pro Takt 50-80% schneller ist. Das ist mittelfristig nicht unmöglich. Aber es kann gut sein, dass das kombiniert mit hohen Taktraten mittelfristig einfach mit deutlich erhöhtem Energiebedarf verbunden ist. Man braucht dann nur so viele zu verbauen dass die Anwendungen die begrenzt parallilisierbar sind von denen ausreichend zur Verfügung haben. Sagen wir 8-12. Und dazu dann noch eine ganze Menge Little Cores für MT. zB 16-24.

In Zeithorizont von 5-10 Jahren mit etwas Weitblick gedacht.
Du beziehst dich auf die Entwicklung heterogener Multicore Syteme in einigen Jahren. Ja, du liegst mit deiner Einschätzung sicherlich in guter Nähe zur Realität.

ADL wird aber dieses Jahr in den Markt entlassen und soll nach Intels Vorstellung den Gamer (HighEnd) Desktop in 2022 dominieren.

In den News vom 29. April gab es das Gerücht zu lesen, ADL liege bis zu 40% unterhalb der Erwartungen Intels. Gegenenfalls ist diese Zahl übertrieben, liegen die Ergebnisse der Tests im Schnitt nicht derart fern von Intels Erwartungshaltung, jedoch dürfte es diese Tests bereits breitflächig geben und die Gerüchte sind wohl eher nicht völlig aus der Luft gegriffen. Nehmen wir nun großzügig an, ADLs Cove-Kerne haben den erwarteten Dampf unter der Haube. Dann sieht es danach aus, als würfelt das "hier-und-jetzt Windows- und Applikations-Umfeld" die Little-Kerne Performance-ungünstig in die Tests hinein?! Das dürfte derart für einige Applikationen in 2022 gelten. In genau diesem Jahr Zeit soll ADL aber glänzen und hier liegt das technische Problem.

[Mangel76]

imho ist das schon jetzt möglich. die letzten 2 gens von amd haben viele kerne mit unterschiedlichen taktraten. wäre das so wie früher, also meinem haswell e(ich konnte da 2 kerne mit 4,6ghz 3x mit 4,5 und 1x mit 4,4 betreiben), würde die performance dem langsamsten kern entsprechen. das scheint bei der 3000er und 5000er serie von amd cpus schon nicht mehr der fall zu sein, da es schnellere und langsamere kerne gibt.

Möglich ist vieles. Die Frage ist eher, ob da auch immer der jeweils günstigste Kern ausgewählt wird. Bisher wird wohl einfach ein bestimmter Kern bevorzugt. Bei big.LITTLE muss aber je nach Prozesstyp mal der schnelle und mal der sparsame Kern zugeordnet werden. Ich weiß nicht, ob Windows das kann.

[BlacKi]

Bei big.LITTLE muss aber je nach Prozesstyp mal der schnelle und mal der sparsame Kern zugeordnet werden. Ich weiß nicht, ob Windows das kann. das könnten wir schon heute testen. ich nicht, aber einer mit vielen kernen eines amd 3000/5000 könnte das schon heute testen.

[aufkrawall]

imho ist das schon jetzt möglich. die letzten 2 gens von amd haben viele kerne mit unterschiedlichen taktraten. wäre das so wie früher, also meinem haswell e(ich konnte da 2 kerne mit 4,6ghz 3x mit 4,5 und 1x mit 4,4 betreiben), würde die performance dem langsamsten kern entsprechen. das scheint bei der 3000er und 5000er serie von amd cpus schon nicht mehr der fall zu sein, da es schnellere und langsamere kerne gibt.

Leider gibt es da einen massiven Denkfehler deinerseits: Bei MT takten wieder alle Kerne so ziemlich gleich schnell, und bei der little.BIG-Problematik von Spielen mit vielen, ggf. abhängigen Threads, ist die Problematik entsprechend kaum durch Scheduler-Magie lösbar.

[BlacKi]

Leider gibt es da einen massiven Denkfehler deinerseits: Bei MT takten wieder alle Kerne so ziemlich gleich schnell, und bei der little.BIG-Problematik von Spielen mit vielen, ggf. abhängigen Threads, ist die Problematik entsprechend kaum durch Scheduler-Magie lösbar.und du hast einen massiven denkfehler gemacht, wenn du denkst, das es mir dabei um den messbaren leistungsverlust ging. mir ging es darum, das der scheduler scheinbar zu wissen scheint, welcher kern der schnellste ist, und damit scheint man die big little erkennungsproblematik schon ausgemerzt zu haben.



aber danke für das wort massiv:biggrin:

[aufkrawall]

Du kannst ja gerne mal erklären, was der Scheduler machen soll, wenn die BIGs voll sind und das Spiel nun Threads mit vergleichbaren Tasks auf den littles laufen lassen will. :cool:

[Mangel76]

mir ging es darum, das der scheduler scheinbar zu wissen scheint, welcher kern der schnellste ist, und damit scheint man die big little erkennungsproblematik schon ausgemerzt zu haben.

Genau da liegt das Problem. Damit der Ansatz funktioniert, muss ein Optimierungsproblem mit 2 gegenläufigen Zielen - max. Performance und min. Verbrauch - gelöst werden. Derzeit gibt es bei AMD einen schnellsten Kern, was soweit wohl auch funktioniert. Ich würde aber vermuten, das Windows die runtergetakteten Kerne nicht von den anderen unterscheidet. Bei einem Spiel geht vielleicht der Hauptthread auf den schnellsten Kern, aber die anderen werden wohl mehr oder weniger zufällig verteilt, genau wie Hintergrundtasks. Um das wirklich sinnvoll hinzukriegen, müssten die Prozesse ja einem der beiden Ziele zugeordnet werden und dann dementsprechend auf die Kerne verteilt werden.

Bisher gibt es nur eine Optimierung auf Performance, was relativ simpel ist. (Verbrauch wird dann in zweitem Optimierungsproblem über den Takt bearbeitet) Bei zwei gegensätzlichen Zielen im gleichen Problem ist die Optimierung deutlich komplexer.

[BlacKi]

wo ist hisn wenn man ihn mal brauch XD

[Savay]

Es sind 2 Kerne und 4 Threads auf dem ersten CCD die immer priorisiert gefüllt werden! (Bei mir Core 0 und Core 7)
Auf dem 2. CCD gibt es danach nach meiner Beobachtung oft einen weiteren dominanten Kern.
Der Rest wird anscheinend vglw. frei hin und her geschoben, dort aber idR zuerst die physischen Kerne gefüllt und danach erst die verbliebenen SMT Threads voll gemacht.

Die Heuristik scheint unter W10 mit nem 5950X also ganz grob so zu sein: beide Prime Cores auf dem Prime CCD zuerst, ein Prime Core auf anderem CCD danach, dann alle restlichen Cores, dann die verbliebenen SMT Threads. (im Hintergrund könnten die Threads aber natürlich noch entsprechend ihrer Abhängigkeiten auf die CCX zugeordnet werden, aber ich glaube das ist eine Optimierung unter der Haube die es ja schon seit Zen(+) gibt, aber das sieht man ja nicht zwingend an der Auslastung)

Spätestens ab dem Punkt wo alle Prime Cores voll sind, ist die CPU meist eh soweit Taktlimitiert, dass alle Cores so oder so wieder potenziell gleich schnell sind! (Wenn auch tw. mit unterschiedlicher Leistungsaufnahme, da sich CCD 0 und 1 dort unterscheiden)

Ergo: Das löst evtl. ansatzweise einen Teil der big.little "Problematik" beseitigt aber nicht den letzten Punkt mit der unterschiedlichen Performance.
Bei Zen3 sind vor allem die beiden ersten Prime Cores einfach nur die Kerne die mit bis zu 5,05GHz boosten können.
Aber auch die schwächeren Cores vom 2. CCD kommen locker auf den theoretischen All-Core Boost der meistens bereits dann zieht wenn 4-8 Threads entsprechend ausgelastet sind.
Die machen (ohne Limits) ja nicht schon bei 3-3,5GHz dicht sondern gehen auch bis ca. 4,3-4,4GHz+...evtl. sogar noch höher. (Nur wahrscheinlich nicht bis auf die beworbenen 4,9GHz+)

[Freestaler]

MMn. reicht der Zensheduler bei weiten nicht für den BigLittle Ansatz. Dort gehts um +/- 5%. Reicht für Benchmarkgewinne, aber im Alltag nicht sonderlich merklich. Wenn nun aber der Kritische Gameprozess auf nen little kommt, weil MS Defender (jede andere Software die nicht mit dem Game/App zu tun hat) update läuft gehts mehr als 5% runter. Die 50% mekrt man dann. Zum Thema in die Breite mit höher effizienz: genau das passiert ja jetzt bereits. Bei allcore gehen die core runter mit dem takt und rauf mit der effizienz je watt. Keine Ahnung was ihr euch da noch erhofft. Das müsste Perf/Watt in noch unbekannten Dimensionen sein (was sie aber noch heutigen Wissenstand eben auch nicht sein werden).

[BlacKi]

Es sind 2 Kerne und 4 Threads auf dem ersten CCD die immer priorisiert gefüllt werden! (Bei mir Core 0 und Core 7)
Auf dem 2. CCD gibt es danach nach meiner Beobachtung oft einen weiteren dominanten Kern.
Der Rest wird anscheinend vglw. frei hin und her geschoben, dort aber idR zuerst die physischen Kerne gefüllt und danach erst die verbliebenen SMT Threads voll gemacht.

Die Heuristik scheint unter W10 mit nem 5950X also ganz grob so zu sein: beide Prime Cores auf dem Prime CCD zuerst, ein Prime Core auf anderem CCD danach, dann alle restlichen Cores, dann die verbliebenen SMT Threads.

Spätestens ab dem Punkt wo alle Prime Cores voll sind, ist die CPU meist eh soweit Taktlimitiert, dass alle Cores so oder so wieder potenziell gleich schnell sind! (Wenn auch tw. mit unterschiedlicher Leistungsaufnahme, da sich CCD 0 und 1 dort unterscheiden)

Ergo: Das löst evtl. ansatzweise einen Teil der big.little "Problematik" beseitigt aber nicht den letzten Punkt mit der unterschiedlichen Performance.
Bei Zen3 sind vor allem die beiden ersten Prime Cores einfach nur die Kerne die mit bis zu 5,05GHz boosten können.
Aber auch die schwächeren Cores vom 2. CCD kommen locker auf den theoretischen All-Core Boost der meistens bereits dann zieht wenn 4-8 Threads entsprechend ausgelastet sind.
Die machen (ohne Limits) ja nicht schon bei 3-3,5GHz dicht sondern gehen auch bis ca. 4,3-4,4GHz+...evtl. sogar noch höher. (Nur wahrscheinlich nicht bis auf die beworbenen 4,9GHz+)


kannst du mal den 2. ccd manuell die taktrate halbieren und schauen ob der scheduller dann andere kerne favorisiert, also die schnellen?

[reaperrr]

MMn. reicht der Zensheduler bei weiten nicht für den BigLittle Ansatz. Dort gehts um +/- 5%. Reicht für Benchmarkgewinne, aber im Alltag nicht sonderlich merklich. Wenn nun aber der Kritische Gameprozess auf nen little kommt, weil MS Defender (jede andere Software die nicht mit dem Game/App zu tun hat) update läuft gehts mehr als 5% runter. Die 50% mekrt man dann. Zum Thema in die Breite mit höher effizienz: genau das passiert ja jetzt bereits. Bei allcore gehen die core runter mit dem takt und rauf mit der effizienz je watt. Keine Ahnung was ihr euch da noch erhofft. Das müsste Perf/Watt in noch unbekannten Dimensionen sein (was sie aber noch heutigen Wissenstand eben auch nicht sein werden).
Du glaubst doch nicht ernsthaft, dass AMD bei Einsatz von "echtem" big.LITTLE mit MS nichts am Scheduling ändern würde?

Wenn 8 (oder mehr) big cores da sind, werden Games schon nicht wegen sowas wie MS Defender auf little cores verschoben werden, wäre auch für MS schlechte Presse und AMD's Standing bei MS sollte mittlerweile wieder mehr als nur gut genug sein, damit das rechtzeitig angegangen wird.
Wobei ich eh davon ausgehe, dass AMD's "little" Kerne stark genug sein werden, dass der Spieler davon außerhalb von Benchmarks so oder so nichts merken würde. Und Intel geht ja auch den Weg, von daher auch im Worst-Case kein Wettbewerbs-Nachteil.

Aber wie gesagt, sich aufgrund des heutigen Zen-Schedulings jetzt schon wegen möglichem big.LITTLE bei Zen5 wegen potentieller negativer Auswirkungen auf die Gaming-Performance ins Hemd zu machen halte ich für leicht übertrieben, vorsichtig ausgedrückt.

[Windi]

Spätestens ab dem Punkt wo alle Prime Cores voll sind, ist die CPU meist eh soweit Taktlimitiert, dass alle Cores so oder so wieder potenziell gleich schnell sind!

Ich glaube das ist der wichtigste Punkt in der ganzen Diskussion, der aber leider häufig übersehen wird.

Die meisten verkauften CPUs werden mit einem TDP Limit betrieben. Nur ein paar Overclocker öffnen alle Schleusen und lassen die CPU so viel saufen wie sie will.

Noch lange bevor alle Kerne voll genutzt werden, muss die Taktrate gesenkt werden um nicht über das Limit zu geraten. Das heißt, bei Anwendungen die nur wenige Kerne nutzen können, profitiert man von der höheren Leistung der BIG Kerne. Bei Anwendungen die viele Kerne nutzen können müssen die BIG Kerne so stark gedrosselt werden, das es zwischen BIG und Little keine großen Unterschiede mehr gibt.

Ich sehe für das BIG.Little Konzept keine großen Nachteile und der Scheduler sollte damit auch klar kommen.


Es wird nur komplizierter, wenn man absichtlich Aufgaben von den Big Kernen auf die Little Kerne schieben will um Energie zu sparen und damit dann einen oder zwei BIG Kerne höher takten zu können. Aber das ist noch nicht so wichtig und wird sich dann im Laufe der Zeit entwickeln.

[Savay]

Bei Anwendungen die viele Kerne nutzen können müssen die BIG Kerne so stark gedrosselt werden, das es zwischen BIG und Little keine großen Unterschiede mehr gibt.

Na moment...dazu müssten die Big Kerne aber sehr schlecht nach unten skalieren und die little sehr gut nach oben und die IPC darf sich nicht groß unterscheiden.
Das geht dann aber fast soweit, das ab einem Punkt das ganze Konzept sich selbst ad absurdum führt.

Ob das bei den Coves und Monts wirklich der Fall ist halte ich für eher sehr unwahrscheinlich vor allem Thread vs. Thread.

Das von mir beschriebene geht vor allem dann auf wenn es eher eine Art big.little Binning (was man wohl doch eher Prime.Secondary nennen sollte) ist wie bei Zen3 (was man ggf. noch etwas weiter auf die Spitze treiben könnte) es aber sonst von der IPC und der Taktbarkeit in einem gewissen Übergangsbereich keine relevanten Unterschiede gibt.

[Nightspider]

Da hier so wild herumgestochert wird:

Vielleicht sitzen bei Zen5 die 4 little Cores auch im IO Die wodurch der Stromverbrauch des Infinity Fabric teilweise wegfallen könnte. Würde sogar im mobilen Einsatz Sinn machen.

[Windi]

Na moment...dazu müssten die Big Kerne aber sehr schlecht nach unten skalieren und die little sehr gut nach oben und die IPC darf sich nicht groß unterscheiden.
Das geht dann aber fast soweit, das ab einem Punkt das ganze Konzept sich selbst ad absurdum führt.
Wenn man sich ansieht, wie viel man investieren muss um die Singelthreadleistung nur um ein paar Prozentpunkte zu erhöhen, glaube ich kaum das der Leistungsunterschied bei Intel so groß sein wird. Die Kerne sind ja generell relativ groß, egal ob BIG oder Little. Selbst von dem kleinen Kern erwarte ich schon mittelmäßige Leistung. Die Großen sind dann eher eine Art Turbo.

Ich erwarte hier eher eine Art: Mittel + Turbo als wirkliches BIG + Little
Dafür sind die Kerne einfach zu groß und bestehen aus zu vielen Transistoren.
Und ich glaube auch nicht an ein Wunder, das Intel bei den Großen Kernen plötzlich die IPC um 50% steigern konnte.

[Savay]

Ich glaube du überschätzt die Monts.

Das mit "Skylake Performance" scheint sich lt. aller Indizien bislang auf einen kompletten 8C Cluster verglichen mit einem 4C/8T Skylake unter voller Auslastung zu beziehen. Was bei Taktgleichheit ~2/3 Skylake IPC für 1T bedeuten könnte?!

D.h. die IPC und Leistung wird pro Thread signifikant niedriger sein als auf dem Big Cluster.
Ne Differenz von um die 50% von Haus aus ist damit nicht unrealistisch und das ohne das die Coves schneller werden.
Und ob die dann am Ende auch ähnlich takten wird sich zeigen müssen.
Gehen die bisherigen Monts überhaupt schon irgendwo über 3GHz?!

[davidzo]

big little soll im desktop ganz andere aufgaben erfüllen. man führt hier big little nicht nach altem schema ein, sondern will das die beiden architekturen gleichzeitig arbeiten. wenn es funktioniert, könnte es die effizienz steigern.

Ist das so? Also um die Multithread Leistung zu steigern? Wieso kriegt dann ausgerechnet die 56C Super Multithread CPU im Serverbereich keine little Kerne dazu?


wenn nicht, dann ist das prinzip für den arsch und intel hätte es schon lange gecancelt.

würde es nicht funktionieren, würde uns 8-12 kerne golden cove vorgesetzt werden mit allen nachteilen. da das nicht passiert, sondern adl kommt wie geplant, wird adl so funzen wie geplant.

so IMHO.
Intel hat schon vieles gelauncht was eigentlich keinen Sinn macht. Lakefield, XE-DG1, Rocketlake, etc...
Intel hat eine Tradition daraus gemacht mit vollkaracho gegen Betonwände zu rennen. Dass man dazu steht ist also kein Indikator das es einen Durchbruch geben wird.

[Windi]

Ich habe natürlich keine Ahnung,

aber die Monts müssten aus so vielen Transistoren bestehen, das ich dort schon etwas Leistung erwarte.
Intel hatte jetzt auch genügend Zeit ihre Designs zu optimieren und diesmal kommt auch die richtige Architektur für die passende Fertigung.

Ist natürlich alles wilde Spekulation.

[BlacKi]

nur weil du es nicht als erfolg abspeicherst, heißt es nicht dass das jeder tut. lakefield war kein fail, er hat performt wie er sollte. intels grafik war eigentlich nur ein testboot. rocketlake war ein backport in den alten prozess, weil intels prozesse probleme machten.

hater gona hate...

[Unicous]

LOL, man kann die design wins fur Lakefield buchstäblich an einer Hand abzählen und du kommst mit haters gonna hate.

[davidzo]

Gehen die bisherigen Monts überhaupt schon irgendwo über 3GHz?!

Nur im Turbo - 3,3Ghz.
Der Sweetspot scheint aber eher bei unter 2Ghz zu liegen, da liegt jedenfalls der baseclock aller jasperlake Varianten. Wenn es also um Energieeffizienz geht ist das wahrscheinlicher dass der da bleibt und für mehr dann eher die großen Kerne genommen werden.

[y33H@]

Ich krieg die Tage nen Jasper Lake rein, bin gespannt.

[Tralalak]

Then compare Jasper Lake in the duel of small cores also with the KaiXian KX-U6780A.

[robbitop]

Wo wir beim Thema "der Scheduler erkennt die schnellsten Cores" waren: ich habe da aus Interesse eine Frage: die neusten CPUs haben doch eine Zuordnung (vom Werk) welches die schnellsten/besten Kerne sind und welche mittelmäßig und welche schlecht sind. Und das wirkt sich auch auf maximale Boosttaktraten aus. Entsprechend asymmetrisch boosten die Kerne.

Bekommt der Scheduler und die Spiele/Anwendungen das denn wirklich hin, genau diese Kerne in den Mainthread zu nehmen und zu halten?
Mein Eindruck war eigentlich, dass ein maximaler Allcore Takt (der aber etwas niedriger als der maximale asymmetrische turbotakt der besten Kerne ist) in Spielen etwas mehr Leistung bringen. Und wenn das so ist, dann spricht es ja ein wenig dagegen, dass Scheduler und Anwendung das konsistent können, oder?

[dildo4u]

Ian Cutress hat spekuliert das es für Desktop Modelle mit abgeschalteten kleinen Kernen geben wird, er erwartet das sich dann der ganze Chip besser OC lässt.
Ich vermute mal die Atom Kerne sind nicht dafür ausgelegt sonderlich hoch zu Takten.(Aktuell unter 3Ghz)

https://www.pcgameshardware.de/CPU-CPU-154106/News/Intel-Grand-Ridge-Atom-DDR5-PCIe-4-in-7-nm-Leak-1355857/

Bin eh gespannt wie das funktioniert ob man die Cluster unabhängig OC kann.

[Wuge]

Also bei meinem Broadwell-e funktioniert das mit dem Favorite Core mässig. Benutzt eine Anwendung exakt einen Kern/Thread bekommt der Scheduler das gut hin. Ansonsten erfolgt die Lastverteilung willkürlich.

[Savay]

Also im Falle von Zen3 bekommt Windows wie gesagt wohl zumindest zwei "Prime" Cores mit mitgeteilt. (also 4T auf CCD0, z.B. Core 0 und 7)
Dort pinnt es nach meiner Beobachtung quasi immer die dominantesten Threads drauf.
Das sind deshalb auch die, die quasi immer zuerst vollständig ausgelastet werden.

Was "Windows" sieht lässt sich dort bspw. auch per Ryzen Master anzeigen.
Davon abweichend scheint auf dem CCD1 dann aber sich noch ein weiterer Kern priorisiert zu werden, was nach meiner Beobachtung aber nicht unbedingt mit dem Rating, das sich aus dem Binnig ergibt, korreliert

Das funktioniert m.E. schon halbwegs anständig, da hier halt meist genug "priorisierte" Threads (halt bis zu 6) zur Verfügung stehen für die meisten Mainthreads in Games etc.
Ich nehme mal an Windows geht dann einfach stumpf nach der Prozesspriorität und Auslastung aber wegen der CCX dem SMT und dem übergeordneten Management über die SMU passiert halt auch viel unter der Haube, das sich von außen im Detail IMHO eh eher schlecht beurteilen lässt.

Aber ab dem Punkt an dem 4-8T komplett ausgelastet sind, bremsen die Limits die CPU meist eh schon auf einen Takt ein den idR eh alle Kerne erreichen können.
Zumindest bei Zen3 geht`s da halt eher um Unterschiede im Bereich von vielleicht 300-400MHz.
Die CPUs sind ja eh entsprechend gebinnt...Problematisch würde das IMHO wohl eher wenn es da Differenzen von signifikant über 500MHz gäbe.

[aufkrawall]

Mein Eindruck war eigentlich, dass ein maximaler Allcore Takt (der aber etwas niedriger als der maximale asymmetrische turbotakt der besten Kerne ist) in Spielen etwas mehr Leistung bringen.
Seit Zen 2 eher das Gegenteil, sofern man keinen Allcore-Takt-Star erwischt hat. Ist bei vielen modernen Spielen aber auch zunehmend egal aufgrund der hohen Last auf vielen Threads, wenn es wirklich mal ins CPU-Limit geht.

[davidzo]

Btw, zu dem hier immer wiederholten Mantra dass die kleinen Kerne effizienter sind als die großen und daher für MT loads einen großen Effizienzschub bringen können: Zumindest bei Apple ist das nicht der Fall: Das ist auch der Grund wieso der M1x fürs Macbook pro 14" und 16" mit 8 Firestorm und nur vier Icestorm kommen soll und von den kommenden 32Core Macs nur 8 Cores Icestorm sind.

https://images.anandtech.com/doci/16192/spec2006_A14.png
https://www.anandtech.com/show/16192/the-iphone-12-review/2

Die kleinen Kerne sind bei Integerloads ungefähr genau so effizient wie die großen, 1/3 der Leistung bei 1/3 der Power.
Bei Floating point gewinnen die großen dann Eindeutig die Effizienzbattle.

Für Apple macht es also keinen Sinn mehr kleine Kerne zur Aufstockung der Multithread Performance zu nehmen, deshalb auch die Gerüchte um fast ausschließlich große Kerne in den Macbook und Desktop CPUs.

Es ist besser das Powerbudget den großen Kernen zu geben und die kleinen schlafen zu legen.

Einziger Sinn und Zweck der kleinen Kerne bei Apple sind Idle-loads, wo man große Teile des SOCs schlafen legen kann und maximal kleine hintergrundtasks laufen. Bei Vollast wird gewechselt auf die großen. Ein Grund für die schlechtere Effizienz der kleinen Kerne könnte das schwächere Cache-System sein, welches den Gang zum DRAM häufiger notwendig macht, welcher mehr Energie verbrät als wenn die Line im cache zu finden ist. Eine Multithreaded Anwendung wird auch ineffizenter mit DRAM und Energie umgehen wenn sie mehr Tasks spawnen muss. Insofern gibt es durchaus einige Gründe die dafür sprechen dass die großen kerne effizienter sind, egal ob in ST oder ind MT Loads (aber eben unter Last).

[Distroia]

Das bringen die kleinen Kerne ja noch weniger, als ich gedacht habe. Die Werte ergeben sich, wenn die Kerne alleine arbeiten, wenn beide gleichzeitig aktiviert sind und die kleinen den großen im Weg rumstehen, kann ich mir noch weniger vorstellen, dass es überhaupt Sinn macht diese zu aktivieren. Außerdem sollte man nicht vergessen, dass Apple auch die Software inclusive Scheduler selbst an den Prozessor anpassen kann, während Intel sich auf Microsoft verlassen muss.

Edit:

Also ich lese da bei Integer ein Drittel der Performance bei einem Zehntel des Verbrauchs (Drittel der benötigten Energie für die Aufgabe). Bei Floating Point ist es ebenfalls ein Zehntel des Verbauchs bei allerdings nur ~22% der Performance (und damit ~45% der benötigten Energie für den Durchlauf).
Also doch, die kleinen Kerne sind effizienter.

Ich nehm alles zurück. Das nächste mal genauer hingucken und nicht alles glauben. :ugly:

[Gipsel]

https://images.anandtech.com/doci/16192/spec2006_A14.png
https://www.anandtech.com/show/16192/the-iphone-12-review/2

Die kleinen Kerne sind bei Integerloads ungefähr genau so effizient wie die großen, 1/3 der Leistung bei 1/3 der Power.
Bei Floating point gewinnen die großen dann Eindeutig die Effizienzbattle.Also ich lese da bei Integer ein Drittel der Performance bei einem Zehntel des Verbrauchs (Drittel der benötigten Energie für die Aufgabe). Bei Floating Point ist es ebenfalls ein Zehntel des Verbauchs bei allerdings nur ~22% der Performance (und damit ~45% der benötigten Energie für den Durchlauf).
Also doch, die kleinen Kerne sind effizienter.

[KarlKastor]

Eben. Die Icestorm sind hier Effizienzwunder. Das ist auch der Grund warum die mobile Geräte so gut laufen.
Die Icestorm haben eine gewisse Performance, die ausreichend ist um eine flüssige Bedienung zu gewährleisten und sind gleichzeitig mega effizient. Gleichzeitig können die unter Volllast aber auch was schaffen, was wichtig ist, da die großen Kerne nicht im Überfluss vorhanden sind.

Andere ARM SoC müssen jedes bisschen gleich auf die großen Cores packen, da die A55 für mehr als simple Hintergrunddienste nichts taugen.

Aber eins ist auch klar. Die Performance kommt auch durch die riesigen Caches. Soo klein sind die Icestorm gar nicht. Das Ziel war wohl maximale Effizienz.

[robbitop]

Btw, zu dem hier immer wiederholten Mantra dass die kleinen Kerne effizienter sind als die großen und daher für MT loads einen großen Effizienzschub bringen können: Zumindest bei Apple ist das nicht der Fall: Das ist auch der Grund wieso der M1x fürs Macbook pro 14" und 16" mit 8 Firestorm und nur vier Icestorm kommen soll und von den kommenden 32Core Macs nur 8 Cores Icestorm sind.

https://images.anandtech.com/doci/16192/spec2006_A14.png
https://www.anandtech.com/show/16192/the-iphone-12-review/2

Also bei SpecINT sehe ich folgendes
Firestorm: 63 speed und 4,42W
Icestorm: 20 speed und 0,44W

Normiere ich jetzt speed auf 63-> 63/20 * 0,44W = 1,38 W. Und das ist weniger als 1/3 der Leistungsaufnahme der 4,42 W vom Firestorm.
Wenn man sich die Energiemenge anschaut, die für die gleiche Arbeit nötig ist:

Firestorm: 8941 J
Icestorm: 2816 J

Icestorm braucht also weniger als 1/3 der Energie für die gleiche Aufgabe.

Bei SpecFP das gleiche nur weniger krass. Icestorm verbraucht weniger 1/2 der Energie verglichen mit Firestorm für die gleiche Aufgabe.


Bitte korrigiere mich, wenn ich einen Denkfehler habe. Aber es wäre auch etwas unsinnig einen little core zu designen, wenn man damit nicht energieeffizienter wäre als der große Core.

[Platos]

... Und wenn man sich jetzt mal den Leistungsfortschritt in 6 Jahren forstellt, dann weiss man, wie extrem krass effizient Geräte werden könnten.

[Savay]

Wenn man sich die Energiemenge anschaut, die für die gleiche Arbeit nötig ist:


Das ist halt die Frage....beziehen sich die Wattsekunden auf den SPECSpeed Wert oder auf den kompletten Durchlauf?!

Eigentlich müsste es letzteres sein. :wink:
Zumindest ist das Diagramm etwas missverständlich was die Werte und Balken angeht.

[Gipsel]

Das ist halt die Frage....beziehen sich die Wattsekunden auf den SPECSpeed Wert oder auf den kompletten Durchlauf?!

Eigentlich müsste es letzteres sein. :wink:
Zumindest ist das Diagramm etwas missverständlich was die Werte und Balken angeht.Die Verbrauchswerte stehen da ja auch. Das ist schon stimmig so, daß das der Energieverbrauch für ein fixes Arbeitspensum (ein Durchlauf) ist.

[BlacKi]

Also im Falle von Zen3 bekommt Windows wie gesagt wohl zumindest zwei "Prime" Cores mit mitgeteilt. (also 4T auf CCD0, z.B. Core 0 und 7)
Dort pinnt es nach meiner Beobachtung quasi immer die dominantesten Threads drauf.
Das sind deshalb auch die, die quasi immer zuerst vollständig ausgelastet werden.

Was "Windows" sieht lässt sich dort bspw. auch per Ryzen Master anzeigen.
Davon abweichend scheint auf dem CCD1 dann aber sich noch ein weiterer Kern priorisiert zu werden, was nach meiner Beobachtung aber nicht unbedingt mit dem Rating, das sich aus dem Binnig ergibt, korreliert

Das funktioniert m.E. schon halbwegs anständig, da hier halt meist genug "priorisierte" Threads (halt bis zu 6) zur Verfügung stehen für die meisten Mainthreads in Games etc.
Ich nehme mal an Windows geht dann einfach stumpf nach der Prozesspriorität und Auslastung aber wegen der CCX dem SMT und dem übergeordneten Management über die SMU passiert halt auch viel unter der Haube, das sich von außen im Detail IMHO eh eher schlecht beurteilen lässt.

Aber ab dem Punkt an dem 4-8T komplett ausgelastet sind, bremsen die Limits die CPU meist eh schon auf einen Takt ein den idR eh alle Kerne erreichen können.
Zumindest bei Zen3 geht`s da halt eher um Unterschiede im Bereich von vielleicht 300-400MHz.
Die CPUs sind ja eh entsprechend gebinnt...Problematisch würde das IMHO wohl eher wenn es da Differenzen von signifikant über 500MHz gäbe.


kannst du nicht den ccx2 mal manuell auf 2,5ghz runtertakten und schauen ob sich die wahl der kerne ändert?

[Distroia]

Also bei SpecINT sehe ich folgendes
Firestorm: 63 speed und 4,42W
Icestorm: 20 speed und 0,44W

Normiere ich jetzt speed auf 63-> 63/20 * 0,44W = 1,38 W. Und das ist weniger als 1/3 der Leistungsaufnahme der 4,42 W vom Firestorm.
Wenn man sich die Energiemenge anschaut, die für die gleiche Arbeit nötig ist:

Firestorm: 8941 J
Icestorm: 2816 J

Icestorm braucht also weniger als 1/3 der Energie für die gleiche Aufgabe.

Bei SpecFP das gleiche nur weniger krass. Icestorm verbraucht weniger 1/2 der Energie verglichen mit Firestorm für die gleiche Aufgabe.


Bitte korrigiere mich, wenn ich einen Denkfehler habe. Aber es wäre auch etwas unsinnig einen little core zu designen, wenn man damit nicht energieeffizienter wäre als der große Core.

Du brauchst dir nicht die Arbeit zu machen, die Effizienz auszurechnen. Rechts in dem Diagramm ist der Energieverbrauch pro "Arbeit", der Kehrwert davon entspricht der Effizienz.

[BlacKi]

Du brauchst dir nicht die Arbeit zu machen, die Effizienz auszurechnen. Rechts in dem Diagramm ist der Energieverbrauch pro "Arbeit", der Kehrwert davon entspricht der Effizienz.
also sind die kleinen 3,175x so effizient wie die großen kerne.

intels angaben betrugen bei lakefield 2x.

dort war der große kern aber auch nicht 3x schneller sondern nur 50%

https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fen.wikichip.org%2Fw%2Fimages%2Fthumb%2F6%2F66%2Flkf_big_vs_smal l_st.jpg%2F600px-lkf_big_vs_small_st.jpg&f=1&nofb=1

[Gipsel]

Du brauchst dir nicht die Arbeit zu machen, die Effizienz auszurechnen. Rechts in dem Diagramm ist der Energieverbrauch pro "Arbeit", der Kehrwert davon entspricht der Effizienz.
Nein. Rechts ist die Performance (und nicht Energieverbrauch pro Arbeit), links der Energieverbrauch (die Balken) für einen feste Menge an Arbeit (offenbar ein Run). Und in Zahlen steht links sowohl die Leistungsaufnahme in Watt (erste Zahl) und der Energieverbrauch in Joule (zweite Zahl).

[KarlKastor]

Er spricht von der Zahl rechts am linken Balken und mit "Arbeit" meint er den Spec Durchlauf.
Was du da jetzt für einen Quotienten bilden willst, weiß ich nicht.

Ist schon interessant was man sich an so einem simplen Diagramm abarbeiten kann. ;D

EDIT: OK, der Quotient ist wieder weg.

[Gipsel]

Er spricht von der Zahl rechts am linken Balken und mit "Arbeit" meint er den Spec Durchlauf.Das meinte er vielleicht, aber davon sprach er nicht. :wink:

[CrazyIvan]

Trotzdem finde ich es etwas unglücklich, dass Anandtech erwartet, dass der Leser die "Art" des Benchmarks kennt. Denn nur wenn klar ist, dass die zu leistende Arbeit konstant ist, kann man die richtigen Schlüsse ziehen.

[Savay]

kannst du nicht den ccx2 mal manuell auf 2,5ghz runtertakten und schauen ob sich die wahl der kerne ändert?

Der Turbo wird dadurch zwar zerschossen, deswegen geht bei mir nur 34x auf CCD0 und bspw. 25x auf CCD1, aber der Scheduler unterscheidet definitiv nicht anhand des Multis usw.

Die Reihenfolge der Füllung ist zu 100% genauso wie bei 34x auf beiden CCDs oder komplett mit Multi auf Auto.
Hätte mich auch schwer gewundert wenn es anders wäre.

[Distroia]

Hmmm, ich hab oben geguckt und da steht "Energie Usage (Jules) ---- Performance Spec Speed". Dachte das wäre der Energieverbrauch, der in der rechten Spalte dargestellt wird, aber "Energie Usage" bezieht sich ja auf den Wert hinter dem Komma in der linken Spalte (ist also nicht graphisch dargestellt). Sehr unübersichtlich das Ganze.

Notiz an mich selbst: Auf jeden Fall in Zukunft genauer hinschauen. :ugly:

[CrazyIvan]

@Distroia
Doch doch. Der linke Balken stellt den Gesamtverbrauch in Joule dar. Die Watt-Angabe ist eher eine Zusatzinformation.

[BlacKi]

Der Turbo wird dadurch zwar zerschossen, deswegen geht bei mir nur 34x auf CCD0 und bspw. 25x auf CCD1, aber der Scheduler unterscheidet definitiv nicht anhand des Multis usw.

Die Reihenfolge der Füllung ist zu 100% genauso wie bei 34x auf beiden CCDs oder komplett mit Multi auf Auto.
Hätte mich auch schwer gewundert wenn es anders wäre.


dann hat amd festgelegt welche cpus zuerste gefüttert werden?

[CrazyIvan]

@Blacki
Ich nahm immer an, dass das hart codiert ist und bspw. in HWinfo auch so angezeigt wird:
https://i.ibb.co/NrBZQdw/HWinfo.png

[Distroia]

@Distroia
Doch doch. Der linke Balken stellt den Gesamtverbrauch in Joule dar. Die Watt-Angabe ist eher eine Zusatzinformation.


Richtig. Schon komisch, dass die Zahl für den Balken hinter dem Komma und die Zusatzinformation vor dem Komma steht.

Also nochmal:

Linke Balken: Gesamtverbrauch

rechter Balken: Performance

[Platos]

Also bei SpecINT sehe ich folgendes
Firestorm: 63 speed und 4,42W
Icestorm: 20 speed und 0,44W

Normiere ich jetzt speed auf 63-> 63/20 * 0,44W = 1,38 W. Und das ist weniger als 1/3 der Leistungsaufnahme der 4,42 W vom Firestorm.
Wenn man sich die Energiemenge anschaut, die für die gleiche Arbeit nötig ist:

Firestorm: 8941 J
Icestorm: 2816 J

Icestorm braucht also weniger als 1/3 der Energie für die gleiche Aufgabe.

Bei SpecFP das gleiche nur weniger krass. Icestorm verbraucht weniger 1/2 der Energie verglichen mit Firestorm für die gleiche Aufgabe.


Bitte korrigiere mich, wenn ich einen Denkfehler habe. Aber es wäre auch etwas unsinnig einen little core zu designen, wenn man damit nicht energieeffizienter wäre als der große Core.

Warum ist denn da der Energieverbrauch in Joule komplett anders, wie in Watt? Der durchschnittliche Wert in Watt sollte im Verhältnis genau gleich der Energie sein.

Wie hat man die beiden Werte überhaupt ermittelt?

[basix]

Warum ist denn da der Energieverbrauch in Joule komplett anders, wie in Watt? Der durchschnittliche Wert in Watt sollte im Verhältnis genau gleich der Energie sein.

Wie hat man die beiden Werte überhaupt ermittelt?

Joule = Watt * Sekunde --> Wenn etwas länger braucht, weil die Performance niedriger ist, ist die Energiemenge eben höher als es die Watt suggerieren

[davidzo]

Notiz an mich selbst: Auf jeden Fall in Zukunft genauer hinschauen. :ugly:

Ging mir genauso, ich dachte der linke Balken wäre der Verbrauch in Watt, nicht die Joules für den Benchmarkdurchlauf. Der Balken stellt aber die joules dar, die Watt sind nur unglücklicherweise auf derselben beschriftet. Wenn man nicht die einzelnen Wattzahlen mit der balkenlänge vergleich kommt man da schnell durcheinander :freak:

Wenn man sich das Prinzip des Spec benchmarks sieht (längerer durchlauf = weniger performance) macht es aber Sinn. Ich finde Joule Angaben auch sehr sinnvoll!

Tja, habe ich mich grandios geirrt! Spannend was das aber wieder lostritt :D

[basix]

Diese Darstellung von Anand hat mich schon immer verwirrt. Etwas komplizierte Darstellung.

[KarlKastor]

Naja, es steht doch oben und unten dran was was ist. Und eine Skala für die Balken gibts auch. Die 1000er Einheiten sind sicher nicht für die Leistung in Watt.

Vielleicht sollte er die Einheiten hinter jede Zahl schreiben. Oder einfach ne Tabelle machen. :D

[Platos]

Joule = Watt * Sekunde --> Wenn etwas länger braucht, weil die Performance niedriger ist, ist die Energiemenge eben höher als es die Watt suggerieren

Natürlich, stimmt. Ist ja Watt und nicht Wattsekunde. Blöder Denkfehler.

Also demnach müssten die Icestorms die Aufgabe in 1.78h erledigt haben, während dem die Firestroms sie in 33.71 min (0.56h) erledigen. D.h der Firestormkern hat die Aufgabe 3.2-Mal schneller erledigt, allerdings benötigt der Firestorm dafür aber die 3.2-fache Energie.

Vergleicht man den heutigen Firestormkern mit einem zukünftigen Icestormkern, der genau die Perfomance hat, wie der heutige Firestormkern (beim Stromverbrauch vom Icestorm), dann würde dieser also die selbe Aufgabe mit 10.10x weniger Energie erledigen (wie der heutige Icestormkern).

Also in ein paar Jahren (zugegeben vermutlich viele Jahre), wenn die Icestrom-Nachfolger die 3.2-Fache Perfomance erreicht haben, dann werden diese im Stande sein, die Aufgaben, die heute Firestormkerne machen, mit 3.2-mal weniger Energie zu erledigen. D.h theoretisch könnte man dann Smartphones mit A14 Leistung mit dem Stromverbrauch von Icestromkernen stemmen.

Natürlich wird die benötigte Rechenleistung sicher ansteigen, da man diese ausnutzen wird. Somit verbrauchen also zukünftige Geräte vermutlich leider nicht weniger Strom sondern Leisten einfach mehr (für was auch immer).

Cool wäre es doch aber, wenn es irgendwann Geräte gibt, die einen Bruchteil von heutigen Smartphones verbrauchen und zwar indem man als "schnelle" Kerne die zukünftigen Icestorm-Nachfolger nutzt (die 3.2-Fach so schnell sind, also so schnell, wie heutige Firestormkerne). Dazu aber dann noch langsamere Kerne, die noch weniger Energie verbrauchen. Dann könnte man ein Smartphone bauen, dessen Stromverbauch unter 1W liegt (ohne Bildschirm). Als (noch) langsamere Kerne müsste man Kerne entwickeln, die eben dann noch weniger Strom verbrauchen (unter 0.1W). Also dann eben 3 Kernklassen. Für Lowpower-Geräte die zwei unteren Kernklassen und für andere eben die zwei oberen.

Leider wird das nie passieren, da die Leute/Die Welt mehr Leistung haben wollen (obwohl die meisten Privatpersonen sie nicht mal brauchen (können)).

Aber das wäre doch mal technologisch gesehen richtig geil. Den Stromverbauch zu senken wäre so easy, aber niemand tut es. Wobei der Stromverbrauch von den Firestormkernen ja niedriger sind, wie die vom Vorgänger. Also ein bisschen was tut da Apple anscheinend.

[Adam D.]

https://www.igorslab.de/wp-content/uploads/2021/05/Alder-Lake-S.jpg


Artikel bzw. Video von Igor: https://www.igorslab.de/exklusive-daten-zu-intel-alder-lake-s-heisser-kampf-mit-amd/

[HOT]

Nach der Rev. A im Januar ist das jetzt offenbar die Rev.B. Die dürfte auch die Launchrev. werden, sonst könnte man seine Termine bis Ende des Jahres auch nicht halten.
Sieht ja ziemlich so aus, wie man sich das vorgestellt hat. Mal sehen wie die finalen Takte dann werden.

Ich sehe ein neues Namensschema aufziehen ;). 5-stellige Nummern sind aber auch kacke.

[Tarkin]

Hm. B0 schaut schon ziemlich final aus.

Der Großteil der IPC-Steigerungen von Willow auf Golden Cove wird wohl (wieder) von den niedrigen Taktraten aufgefressen - ganz so sie von SKL auf Sunny Cove.

20% mehr IPC (reine Spekulation... könnten genau so eher nur 10-15% im Schnitt sein) aber dafür 10% weniger Takt (wenn die Taktraten von diesem Sample noch um 200MHz erhöht werden).

Vl reicht es knapp für die Gaming-Krone gegen Zen 3... viel Abstand wird da allerdings nicht sein.

Und wer weiß was von AMD heuer noch kommt - schätze, da wird man keine Probleme haben die Gaming und Multi-Thread Krone zu behalten.

[Savay]

Man muss doch nur mal auf die Turbo Ratio Limits der Atom Cores schauen. Wie schon vermutet keine Taktwunder.
3,4GHz für 1-4T und ganze 3GHz bei mehr als 4T mit wenn es hoch kommt vielleicht 75% Skylake IPC/Thread.

Sieht ehrlich gesagt nicht unbedingt besonders pralle aus. Selbst wenn man davon ausgehen kann das es sicherlich nicht die Top SKU ist.

Wenn das grob finale Taktraten sind, können die ja fast froh sein wenn die Multithreaded überhaupt annähernd an den 12C Zen3 rankommen.

[robbitop]

Das ist doch erst ein engineering sample. Über finale Taktraten wissen wir noch gar nichts.

[Gipsel]

Das ist doch erst ein engineering sample. Über finale Taktraten wissen wir noch gar nichts.Falls die im Herbst/Winter rauskommen, sollte man jetzt schon ziemlich nah dran sein (wir haben immerhin schon Mai und Intel hat traditionell oft etliche Monate vor Launch schon Samples mit quasi finalen Takten). 200-300 MHz könnten sich eventuell noch bewegen (mehr eventuell allcore beim ausgequetschten Topmodell mit 125/250W), aber so viel ist dann beim Singlecore-Boost dann auch nicht mehr zu erwarten.

[davidzo]

Ich sehe ein neues Namensschema aufziehen ;). 5-stellige Nummern sind aber auch kacke.

Sollte sich das Namensschema bis zum Launch halten feiere ich Intel richtig dafür!
Core-1800 = Fulldie 8C/24T 1800mhz baseclock.
Das ist so klar und eindeutig wie seit P4 Northwood Zeiten nicht mehr. Ob das ein Gelsinger Move ist?
Core-1600k ist dann ein 6c/20T unlocked
Core-1500 ein 6c/16T
...

Das ist doch erst ein engineering sample. Über finale Taktraten wissen wir noch gar nichts.

Dafür sind die Taktraten aber verdamm nah an dem was bisher spekuliert wurde. Das typische ES mit 2,4Ghz ohne Turbo ist es jedenfalls nicht.
Bei den kleinen Cores passt es sehr genau zu dem was versprochen wurde: Mehr takt als Tremont, mehr war die Aussage nicht. Und gegenüber dem Baseclock von 2-2,2ghz von tremont sind 3Ghz allcore schon eine Ansage.

Andererseits hatten wir vom 11900K zu einem ähnlichen Zeitpunkt auch schon ES mit 1,8Ghz und 4,4Ghz Turbo: https://videocardz.com/newz/intel-core-i9-11900-engineering-sample-tested-in-cpu-z-benchmark-on-z490-motherboard
Letzendlich sind es dann aber 2,5Ghz base und 5,2Ghz Turbo beim 11900 geworden.

[y33H@]

Die Daten stammen aus HW-Info, das nur am Rande.

[Platos]

Falls die im Herbst/Winter rauskommen, sollte man jetzt schon ziemlich nah dran sein (wir haben immerhin schon Mai und Intel hat traditionell oft etliche Monate vor Launch schon Samples mit quasi finalen Takten). 200-300 MHz könnten sich eventuell noch bewegen (mehr eventuell allcore beim ausgequetschten Topmodell mit 125/250W), aber so viel ist dann beim Singlecore-Boost dann auch nicht mehr zu erwarten.

Man muss das positiv sehen. Je niedriger der Takt, desto höher muss die IPC sein, denn Intel wird sicherlich nichts auf den Markt werfen, das schlechter wie der Vorgänger ist.

Und je niedriger der Takt, desto mehr Optimierungspotential ist vorhanden :D

Ist mir lieber eine hohe IPC mit niedrigem Takt wie bisher mit gewöhnlicher IPC und Takt bis an die Kotzgrenze.

[aufkrawall]

Ist halt nur blöd, wenn auch mit etwaig besserer Fertigung in Zukunft trotzdem nur 8 BIGs am Horizont sind. :(

[Lehdro]

Man muss das positiv sehen. Je niedriger der Takt, desto höher muss die IPC sein, denn Intel wird sicherlich nichts auf den Markt werfen, das schlechter wie der Vorgänger ist.

Sicher? (https://www.computerbase.de/2021-03/intel-core-i9-11900k-i5-11600k-test/4/) :freak:

Aber wie hier schon gesagt: Kommt auf die Praxis an, bis jetzt sehe ich da noch große Fragezeichen.

[Platos]

Ja, mit Alderlake nicht und ich denke mal, dass Raptorlake da auch nichts ändert.

Also muss man wohl bis Meteorlake und ein Chiplet-Design warten. Also ist noch etwa 2.5 Jahre bis dahin:freak:

Dann gibts vermutlich mehr (schnelle) Kerne

[davidzo]

Intel wird sicherlich nichts auf den Markt werfen, das schlechter wie der Vorgänger ist.

Coppermine-Williamette
Northwood - Prescott
Broadwell-Skylake

Rein rechnerisch wäre es mal wieder an der Zeit ;D
Andererseits trifft das ja mit Rocketlake ja quasi zu, zweimal nacheinander wäre also ein bisschen übertrieben :freak:

[reaperrr]

Coppermine-Williamette
Northwood - Prescott
Broadwell-Skylake

Rein rechnerisch wäre es mal wieder an der Zeit ;D
Andererseits trifft das ja mit Rocketlake ja quasi zu, zweimal nacheinander wäre also ein bisschen übertrieben :freak:
Broadwell-Skylake ist ein bisschen unfair, Skylake-S als Chip/Architektur war schon klar besser (sowohl IPC als auch Taktbarkeit/Effizienz), nur der L4 von Broadwell hat gerade in Spielen halt einen verdammt großen Unterschied gemacht, mit 400(?) MHz weniger AllCore Takt und 5-7% weniger IPC teils 15% schneller, heißt der L4 hat in Spielen teils 20% und mehr gebracht.

Ich weiß auch nicht so ganz, warum Intel Broadwell in der Form zu dem Zeitpunkt überhaupt noch gebracht hat, damit haben sie nur unnötig die Erwartungshaltung an den Nachfolger hochgeschraubt.

[y33H@]

Tualatin vs Willamette!

[BlacKi]

Tualatin vs Willamette!


wobei der p4 im schlechteren prozess hergestellt wurde als der p3.

genauso war prescot schneller als northwood. https://www.anandtech.com/show/1419/4

auch seine anderen auflistungen sind wieder mal nur in der eigenen fantasie vorhanden.

[Virtual]

wobei der p4 im schlechteren prozess hergestellt wurde als der p3.

genauso war prescot schneller als northwood. https://www.anandtech.com/show/1419/4

auch seine anderen auflistungen sind wieder mal nur in der eigenen fantasie vorhanden.
Naja, zu "Preshot" darf man nun im wirtschaftlich bedeutungslosen Rückblick auch eine neutrale Meinung haben:

https://www.computerbase.de/2019-02/intel-pentium-prescott-test-rueckblick/

Lässt man mal die beliebten Demonstrationen der bedingungslosen Überlegenheit mittels (SSE3-)Befehlssatzoptimierung beiseite, dann war "Preshot" in Spielen nicht schneller als Northwood.

Falls das Engineering Sample von ADL für 4.2 GHz wirklich bereits >1,3 V benötigt, dann ist für dieses (durchschnittliche?) Sample sicherlich bei 4,6 GHz mit 1,5 V das Ende der Fahnenstange erreicht.
Aber vielleicht kann Intel in nächsten Monaten aus Design und Prozess noch 400 MHz bei verträglichen 1,3 V herausquetschen?

[Fusion_Power]

https://www.igorslab.de/wp-content/uploads/2021/05/Alder-Lake-S.jpg


Artikel bzw. Video von Igor: https://www.igorslab.de/exklusive-daten-zu-intel-alder-lake-s-heisser-kampf-mit-amd/
125W TDP? :eek: Vllt. hab ich falsche Vorstellungen aber ich hab mir bei so einem Big/Little Chipdesign wesentlich niedrigere Verbrauchswerte ausgemalt. Zumindest wenn die kleinen Cores unter Last werkeln.

[CrazyIvan]

Das wird ja auch so sein. Aber unter Volllast aller 16 Kerne... das war erwartbar. Muss ja auch nicht heißen, dass Intel die TDP mit ADL-S direkt ausreizt. Aber man hat die eigene Grenze schonmal vorsorglich angehoben.

[BlacKi]

die werden schon mit 8+0 gerissen. die neuen big cores sind nochmals größer. die kleinen cores werden so oder so nur beiwerk sein. ich glaub nicht, das die ungebremst weniger als 200w brauchen werden. eher richtung 300w. in games werden es dann so zwischen 90 und 110w sein im cpu limit. die kühlbarkeit wird wohl ähnlich gut sein wie bei rocketlake.

[CrazyIvan]

Ja, die TDP ist eben bei Intel was bei Intel die TDP ist - keine Aussage zur Spitzenlast.

[Virtual]

125W TDP? :eek: Vllt. hab ich falsche Vorstellungen aber ich hab mir bei so einem Big/Little Chipdesign wesentlich niedrigere Verbrauchswerte ausgemalt. Zumindest wenn die kleinen Cores unter Last werkeln.
Deine Vorstellung ist sicherlich zutreffend, wenn alle kleinen Cores ohne die großen Cores unter (Voll)Last werkeln und dabei keine 125W erreichen, ... aber sollte das wirklich genau so vorkommen, dann läuft auch was grundsätzlich falsch.

[Fusion_Power]

Deine Vorstellung ist sicherlich zutreffend, wenn alle kleinen Cores ohne die großen Cores unter (Voll)Last werkeln und dabei keine 125W erreichen, ... aber sollte das wirklich genau so vorkommen, dann läuft auch was grundsätzlich falsch.
Kann das nicht einfach eine knuffige 35-65W CPU sein die in meinem Mini-ITX Gehäuse noch gescheit gekühlt werden kann? Welche Modelle sind von der Architektur eigentlich alles geplant? Doch nicht nur 125W(+) Boliden, oder?

[KarlKastor]

Wo ist das Problem? Stell im BIOS ne kleinere TDP ein und gut ist.
Die Leistung zu drosseln ist doch das kleinste Problem.

Umgekehrt ist's kniffliger.

[Fusion_Power]

Wo ist das Problem? Stell im BIOS ne kleinere TDP ein und gut ist.
Die Leistung zu drosseln ist doch das kleinste Problem.

Umgekehrt ist's kniffliger.
Wie immer ist der PREIS das Problem. ;) Die schnelleren CPUs sind natürlich auch teurer, was soll ich mir nen i9 kaufen wenn ich ihn nur auf i5 Leistung betreibe. Wer würde sowas tun.
Nee, ich kauf mir dann den i5 mit weniger TDP, vorrausgesetzt es gibt diesen überhaupt. Ich gehe eigentlich davon aus dass Intel auch mit Alder lake Architektur alles abdeckt, vom i3 bis zum i9 oder wie auch immer sie das dann nennen werden. Es sollen ja sogar mobile CPUs kommen mit der Architektur.

[BlacKi]

Kann das nicht einfach eine knuffige 35-65W CPU sein die in meinem Mini-ITX Gehäuse noch gescheit gekühlt werden kann? Welche Modelle sind von der Architektur eigentlich alles geplant? Doch nicht nur 125W(+) Boliden, oder?


natürlich wirds die geben. die t modelle werden mit hoher warscheinlichkeit wieder mit 35w tdp kommen. aber preislich wird sich nicht viel tun.


ich hab das gefühl, das die OC modelle wieder kaum OC ermöglichen werden wie rocketlake. was die 125w tdp modelle so oder so ad absurdum führt, eben genau wie bei rocketlake.


dann wirst du 8+8 modelle mit 65w tdp für 400-500€ bekommen. die man dann manuell entdrosseln kann.

[Fusion_Power]

Ich suche da ehr ne zukunftsfähige CPU um die 200€. Dafür bekommt man ja mittlerweile auch schon "irgend was mit 6 Kernen und 12 Threads". Wirds halt keine exotische Hybrid CPU mit fragwürdigem Nutzen sondern wieder einfache Hausmannskost.

[BlacKi]

Ich suche da ehr ne zukunftsfähige CPU um die 200€. Dafür bekommt man ja mittlerweile auch schon "irgend was mit 6 Kernen und 12 Threads". Wirds halt keine exotische Hybrid CPU mit fragwürdigem Nutzen sondern wieder einfache Hausmannskost.


abwarten, gerade die kleinen hybriden könnten interessant werden. beim großen könnte es wieder unnötig teuer werden, die kleinen aber dafür interessant.


wenn raptorlake mit dem gaming cache richtig zündet, dann bleibt adl sowieso nicht lange drin^^

[dildo4u]

Laut dem ist der Launch Termin zur Zeit November.


https://wccftech.com/intel-alder-lake-s-landing-in-november-2021-first-to-market-with-pcie-5-0-ddr5-ram-and-new-coolers/

[HOT]

Das wäre nicht schlecht. Und für Intel Verhältnisse hätte man die CPU in Rekordzeit aus dem Boden gestampft. Mitte Januar Rev.A, Ende April Rev.B und Launch November ist ein sehr sehr straffer Zeitplan. Gut gelaufen für Intel.

[Blediator16]

Das wäre nicht schlecht. Und für Intel Verhältnisse hätte man die CPU in Rekordzeit aus dem Boden gestampft. Mitte Januar Rev.A, Ende April Rev.B und Launch November ist ein sehr sehr straffer Zeitplan. Gut gelaufen für Intel.

Ich dachte das Design liegt seit 10 Jahren in deren Schublade?

[HOT]

? Wohl eher nicht.

Mal der Zeitplan wie realistisch geplant (also nach dem Aus von Tick/Tock, nicht von 2012 :D).

2013 Haswell
2014 Broadwell
2015 Skylake (2 und 4C)
2017 Cannon Lake (2 und 4C)
2018 Ice Lake (2 und 4C) (verschob sich 1/2 Jahr)
2020 Tiger Lake (2 und 4C) (klappte ja auch, aber eben nur mobil)

Soweit war Intel gar nicht aus dem Zeitplan. Es ist eben nur so, dass Cannon Lake vermutlich mit 2 und 4 Cores Anfang 2017 kommen sollte, das klappte nicht und Ice Lake vermutlich mit 2 und 4 C Ende 2018 für Mobil und Desktop. Diese Pläne wurden eben durcheinandergeworfen von a.) 10nm klappte nicht und b.) AMDs 8-Core-CPUs. Ich denke nicht, dass Intel für Desktop mit all diesen CPUs mehr als 4 Kerne vorsah. Das kam ausschließlich von AMDs Einfluss, denn in 2016 war ja schon klar, dass AMD echte 8C mit viel IPC bauen würde.

[amdfanuwe]

Ich denke nicht, dass Intel für Desktop mit all diesen CPUs mehr als 4 Kerne vorsah.
Seh ich auch so. 4 Cores für Office und etwas darüber hinaus ist ja auch ausreichend. Solange man mit jeweils geringen Verbessungen die Chips zu hohen Preisen verkaufen kann, ein gutes Geschäft.
AMD hat mit 6 und 8 Core mit akzeptabler IPC eine Lücke getroffen und Intel überrascht.

[y33H@]

uArch-Talk auf der HC im August:

https://hotchips.org/advance-program/

[HPVD]

und auch der DDR5 Speicher scheint schneller als gedacht:


Arbeitsspeicher von GeIL: DDR5 mit bis zu 7.200 MHz und RGB kommt im 4. Quartal
...Vielmehr sollen mit der Einführung DDR5 RAM-Sets mit 6.000, 6.400, 6.800 und als schnellste Variante mit 7.200 MHz in den Handel kommen, die darüber hinaus auch mit reduzierten Timings von CL32-36-36, CL32-36-36, CL36-44-44 und CL36-44-44 angegeben sind.

https://www.computerbase.de/2021-05/arbeitsspeicher-von-geil-ddr5-mit-bis-zu-7.200-mhz-und-rgb-kommt-im-4.-quartal/

[JVC]

"mit reduzierten Timings von CL32-36-36 7.200MHZ"
Soll man da lachen oder weinen ?
B-Die CL14-14-14 3600Mhz sollte da doch merklich schneller sein :confused:

M.f.G. JVC

[Thunder99]

Am Anfang ist der alte RAM immer schneller oder besser wenn es um Timings geht. Das wird wie immer dauern das New DDR RAM besser ist als Old.

[robbitop]

Die Latenz vom RAM ist doch historisch gesehen relativ statisch (zumindest wenn man vergleichbare Segmente in Augenschein nimmt). Bandbreite steigt (was mit wachsender Anzahl an Kernen an Bedeutung zunimmt) und ggf sinkt die Latenz im IMC etwas aufgrund des höheren Taktes.

Es ist eigentlich nur der IMC und der Pfad bis zum RAM der höher Taktet. Der RAM Baustein selbst intern nicht.

Die Gesamtlatenz sinkt eigentlich kaum noch. Bereits Phenom 2, Sandy and Ivy Bridge schafften knappe 40-42 ns mit getuntem RAM.
Skylake und Nachfolger schafften mit extremen RAM nochmal weniger - 35-40 ns.

(alles AIDA Messwerte)

[Platos]

Wie kann man eig. bei sowas schnellem wie ns im 2 stelligem Bereich noch mit Software auslesen? Eig. sollte das doch alles unter enormen ungenauigkeiten stehen.

[robbitop]

Es gibt ein definiertes Taktsignal das man kennt und zählt Takte und rechnet dann um.

[basix]

Es gibt ein definiertes Taktsignal das man kennt und zählt Takte und rechnet dann um.

Genau. Wenn ich ~1000 Schrauben will zähle ich die nicht, sondern wäge zuerst eine Schraube und anschliessend den ganzen Haufen.

Vom grundlegenden Prinzip her das selbe wie bei der Latenzbestimmung, einfach umgekehrt. 1000 Speicheroperationen dauern so lange, wie lange dauert also 1 davon.

[BlacKi]

"mit reduzierten Timings von CL32-36-36 7.200MHZ"
Soll man da lachen oder weinen ?
B-Die CL14-14-14 3600Mhz sollte da doch merklich schneller sein :confused:

M.f.G. JVC


ich teile die meinung der anderen nicht.



hier im video hat man ddr3 2400 cl11 vs ddr4 2400cl15 gebenched. ja, die timings sind schlechter siehe aida64 https://youtu.be/qctAqMDL_vA?t=189



und trotzdem sind die performance werte vergleichbar.


ich hab den zusätzlichen eindruck, das ddr5 deutlich schneller ddr4 hinter sich lassen als es ddr4 mit ddr3 tat. 2014 gabs kaum ram der überhaupt schneller war als ddr3, jetzt schau dir ddr5 an, er ist noch nicht mal kaufbar, und schon schneller als es ddr4 je war.


wenn das kein gutes zeichen ist.

die skepsis kommt vermutlich einfach daher, das intel zuerst auf ddr5 geht, und diese leute einfach schlechte stimmung machen. wenn dann zen4 kommt, ist die welt plötzlich eine andere, und alle finden ddr4 scheiße und ddr5 gut^^

[WedgeAntilles]

ich hab den zusätzlichen eindruck, das ddr5 deutlich schneller ddr4 hinter sich lassen als es ddr4 mit ddr3 tat. 2014 gabs kaum ram der überhaupt schneller war als ddr3, jetzt schau dir ddr5 an, er ist noch nicht mal kaufbar, und schon schneller als es ddr4 je war.


wenn das kein gutes zeichen ist.

Interessant wird auch der Preis sein - DDR 4 war doch am Anfang viel teurer als DDR 3 IIRC.
Mal sehen wie der Unterschied dieses mal sein wird.

[robbitop]

Man muss bei den AIDA zur Memorylatency Werten aufpassen. Ich bin mir nicht sicher, ob die immer vergleichbar sind.
Nicht umsonst hat Anand sich ein Tool gebaut, um mit verschiedenen Zugriffsmustern die Latenz zu messen und am Ende muss man analytisch entscheiden, welches Pattern am repräsentativsten ist bei einer entsprechenden uArch. Insofern kann man schwer die Latenz in unterschiedlichen Plattformen vergleichen und somit ist man nicht wirklich in der Lage, Schlüsse daraus zu ziehen oder latenznormiert zu benchen.

[Platos]

Es gibt ein definiertes Taktsignal das man kennt und zählt Takte und rechnet dann um.
Genau. Wenn ich ~1000 Schrauben will zähle ich die nicht, sondern wäge zuerst eine Schraube und anschliessend den ganzen Haufen.

Vom grundlegenden Prinzip her das selbe wie bei der Latenzbestimmung, einfach umgekehrt. 1000 Speicheroperationen dauern so lange, wie lange dauert also 1 davon.

Ach soo, ja macht natürlich Sinn so.

[Platos]

Interessant wird auch der Preis sein - DDR 4 war doch am Anfang viel teurer als DDR 3 IIRC.
Mal sehen wie der Unterschied dieses mal sein wird.

Grundsätzlich baute man bisher immer zu wenig Kapazitäten als Fertiger (man will ja nicht drauf sitzen bleiben). Und Anfangs ist die Nachfrage immer höher, wie das Angebot.

Die Speicherpreise von DDR4 sollten auf DDR5 keinerlei Einfluss haben. Wenn also DDR4 gerade einen hohen Preis hat, dann erscheint DDR5 günstig/nicht so teu(r)er, ist es aber nicht.

[davidzo]

ich teile die meinung der anderen nicht.



hier im video hat man ddr3 2400 cl11 vs ddr4 2400cl15 gebenched. ja, die timings sind schlechter siehe aida64 https://youtu.be/qctAqMDL_vA?t=189



und trotzdem sind die performance werte vergleichbar.

Hast du dir das Video mal angesehen? Zwar nicht um viel, aber durch die Bank liegt dort DDR4 hinten. Das ist schon hart bei gleicher cpu, nur leicht unterschiedlichen speichertimings -
Du verschweigst nämlich die subtimings, die so nah aneinanderliegen wie irgend möglich:
cl11-14-14-32
cl15-15-15-36
Dass da nicht viel Luft zwischen ist sieht man ja schon an AIDA, das normalerweise heftiger auf Unterschiede bei den subtimings reagiert.

und die meisten benches wie 7zip etc. die er verwendet hat reagieren eher auf die bandbreite und sind weitgehend latenzagnostisch.


Grundsätzlich baute man bisher immer zu wenig Kapazitäten als Fertiger (man will ja nicht drauf sitzen bleiben). Und Anfangs ist die Nachfrage immer höher, wie das Angebot.

Die Speicherpreise von DDR4 sollten auf DDR5 keinerlei Einfluss haben. Wenn also DDR4 gerade einen hohen Preis hat, dann erscheint DDR5 günstig/nicht so teu(r)er, ist es aber nicht.

Es sind dieselben Fabs. Die werden sich einfach ähnlich pro Wafer bezahlen lassen, plus Aufschlag für das geflossene R&D Budget und die neuen Masken bei DDR5.

[BlacKi]

cl ist aber der wichtigste faktor. und der ist erheblich niedriger. du kannst ja gerne mal ddr4 4000 mit cl19 vs cl14 vergleichen. ja, so groß ist der nachtteil hier im ddr3 vs ddr4 vergleich. aber ich vermute mal, das ist kaum messbar^^ da ist kaum luft dazwischen^^

es könnte zusätlich noch kommen, das ddr5 vorteile mit sich bringt, die die latenzen ram unabhängig verbessert. die aufteilung von 1x 64bit auf 2x 32bit.

[Platos]

Ich hoffe mal, DDR5 wird so ein Wunder, wie du es immer preist :freak:

Dann brauche ich nämlich deutlich niedrigere Spannungen für die selbe Leistung.

[Lehdro]

Die Latenz vom RAM ist doch historisch gesehen relativ statisch (zumindest wenn man vergleichbare Segmente in Augenschein nimmt).
Nur mal als Blast from the Past: Ein Athlon 64 schaffte mit DDR 500 @ CL2 auch schon um die 37ns. Stock mit DDR 400 @ CL2 sind es ca. 45-46ns. Für DDR 600 @ CL2.5 und DDR 400 @ CL1.5 habe ich leider keine Werte mehr gefunden. Aber du hast schon recht: Es hat sich in dem Bereich wirklich gar nichts getan, nur die Bandbreite ist "explodiert".

[mksn7]

Genau. Wenn ich ~1000 Schrauben will zähle ich die nicht, sondern wäge zuerst eine Schraube und anschliessend den ganzen Haufen.

Vom grundlegenden Prinzip her das selbe wie bei der Latenzbestimmung, einfach umgekehrt. 1000 Speicheroperationen dauern so lange, wie lange dauert also 1 davon.

Mhm, ich würde dein Beispiel hier genau andersrum aufspannen: Ich möchte wissen was eine Schraube wiegt, kann aber so fein nicht messen. Also wiege ich tausend Schrauben und teile durch 1000.

[Platos]

Sagt er doch unten gleich. Bei Speicherlatenzen dann genau anders rum ;)

[BlacKi]

Nur mal als Blast from the Past: Ein Athlon 64 schaffte mit DDR 500 @ CL2 auch schon um die 37ns. Stock mit DDR 400 @ CL2 sind es ca. 45-46ns. Für DDR 600 @ CL2.5 und DDR 400 @ CL1.5 habe ich leider keine Werte mehr gefunden. Aber du hast schon recht: Es hat sich in dem Bereich wirklich gar nichts getan, nur die Bandbreite ist "explodiert".
und trotzdem ist die performance in den anwendungen mit jeder ddr evolution absolut gestiegen.:biggrin:

[Thunder99]

Nur wenn die Anwendung/Spiel von der erhöhten Bandbreite profitieren kann. Siehe auch A64 DDR vs. DDR2 Vergleich (https://www.computerbase.de/2021-05/amd-am2-athlon-64-x2-ddr2-test-rueckblick/#abschnitt_ohne_zusaetzliche_leistung_aber_mit_mehr_features). Der neue Standard brachte erst mal nichts

[robbitop]

und trotzdem ist die performance in den anwendungen mit jeder ddr evolution absolut gestiegen.:biggrin:

Ob das nicht ggf eher mit der Evolution der uArch und der Cachehitrate korrelieren könnte? ;)

[arcanum]

bei alder lake kann man das ja prima testen dank ddr4+ddr5 support.

[Platos]

bei alder lake kann man das ja prima testen dank ddr4+ddr5 support.

Ja, bitte ausführliche Tests, will ich auch.

[BlacKi]

Ob das nicht ggf eher mit der Evolution der uArch und der Cachehitrate korrelieren könnte? ;)dann waren die letzten 15 jahre wohl für die katz? ddr1 forever...

[robbitop]

dann waren die letzten 15 jahre wohl für die katz? ddr1 forever...

Das habe ich damit nicht sagen wollen. Es brachte Bandbreite. Da die kumulierte MT Leistung stieg, brauchte man auch mehr Bandbreite. Aber für die Latenz brachte es wenig.

[BlacKi]

aber wie ich schon sagte, latenzen sind nicht absolut, wenn man die performance beurteilen will.

ddr4 3600 cl16 ist nicht gleich schnell wie ddr5 7200 cl32. ddr5 ist schneller.

[robbitop]

Wie ich schon sagte. Ohne ein Tool wie Anand es hat, lässt sich Latenz nur schwer vergleichen. Bei einem Produkt, welches zwei Speicherstandards unterstützt könnte man den Aida Messwert schon halbwegs nehmen. Mal sehen ob sich jemand bei ADL die Mühe machen wird. Bei SKL könnte man das auch machen. Latenz normieren und dann Spielebenchmarks.

[Platos]

Das würde mich auch interessieren. Also liebe Testseiten, bitte ausführlich testen. Neue Speichergenerationen gibts schliesslich nicht jedes Jahr oder alle 2 Jahre.

Latenznormiert ist eine gute Idee. Am besten dann auch, in dem man die Latenz auf verscheidene Weise erreicht (z.B hoher Speichertakt& hohe Timings oder weniger hoher Speichertakt aber dafür straffe Timings - bei selber Speichergeneratioin).

Tests mit "gängigen" Taktraten und Latenzen bei beiden Speichersorten sollten aber auch nicht fehlen.

[HOT]

Die Latenz lässt sich leicht verglechen. Man würde heute immer noch schnelle Systeme mit DDR3 bauen können, wäre kein Problem, da sich die Latenz schlichtweg nicht ändert. Wie gesagt, es gab schon zu DDR-Zeiten Systeme, die identische oder gar niedrigere Latenzen aufwiesen als heute. DDR5 wird daran genau 0 ändern.
Das einzige was sich ändert ist die Bandbreite. Die ist zu einem gewissen Grad notwendig, aber die DDR4 vs. DDR5-Tests werden eben zeigen, dass es heute quasi 0 Unterschied macht, auf welchen Standard man setzt. Da brauchst schon Renderingsoftware oder irgendwas anderes bandbreitenlastiges, um davon zu profitieren. Bisher waren Spiele niemals die Profiteuere eines Speicherumstiegs.