Wie zu sehen ist, hat Intel in seinen aktuelleren Architekturen den L1-Data-Cache ebenfalls bereits vergrößert, konkret um +50 % und das bereits in 2018/19 (Sunny Cove ist effektiv bereits aus 2018). Ob man mit Alder Lake weitere Vergrößerungen zu sehen bekommen wird, wird man abwarten müssen, jedoch sind Größenänderungen längst nicht alles, was man am Cache/Speichersubsystem optimieren kann.
Mit Blick auf Zen2/3 ist der L3 bspw. voraussichtlich nur wegen Epyc und der Chiplet-Bauweise so groß geworden, denn andernfalls hätte man mit den bis zu acht Chiplets mit mehr Latenzen beim Speicherzugriff zu kämpfen. Die L1/L2-Größen sind unverändert geblieben (32/32 KiB und 512 KiB), dennoch hat AMD auch bei Zen3 weiter am Cache optimiert, zusätzlich zum unified L3, der nun alle acht Kerne abdeckt, dafür jedoch auch mit etwas höheren Latenzen auskommen muss.
Derart extrem große Caches, wie sie bspw. beim M1 zu sehen sind, sind voraussichtlich auf x86 nicht sinnvoll übertragbar, weil bspw. ein wesentlicher Unterschied ist, dass die bisherigen ARM-Kerne typischerweise darauf ausgelegt waren ohne einen L3 zu arbeiten und entsprechend müssen ihre anderen Caches zwangsweise etwas größer ausfallen. Beim M1 ging Apple mit den 12 MiB L2 für die vier großen Firestorm-Kerne und die 16 MiB shared L3 des gesammten SoCs jedoch in die Vollen. **)
Ähnliches sieht man auch bei Intel's Atom's. Beispielsweise die aktuellen Tremont-Kerne wurden auf 32/32 KiB L1 belassen/vergrößert (Goldmont Plus verwendete noch 24 KiB L1-Data), was dem Effizienzziel geschuldet ist. Der L2 dagegen kann bei Tremont je nach konkretem Verwendungszweck zwischen 1,5 - 4,5 MiB pro Modul ausfallen und ein Modul kann bis zu vier Kerne enthalten, d. h. es kann Designs mit 4,5 MiB L2 für einen einzelnen Kern geben oder auch bspw. Designs mit 1,5 MiB L2 für vier Kerne. Ein L3 ist für Atom's ebenfalls nicht vorgesehen. Mit dem umfangreichen Überarbeitungen, die die neue Generation Gracemont (Stand-alone und auch als Bestandteil von Adler Lake) erfahren soll, dürfte es interessant zu sehen sein, ob Intel hier nennenswert an die Cache-Struktur der neuen Atom's Hand anlegt, denn dem entgegen stehen die zu erreichenden Effizienzziele (aber vielleicht kann hier das 10nm Enhanced SuperFin etwas mehr Spielraum verschaffen?). Man darf gespannt sein.
*) Bspw. in (vergleichsweise) leistungsstarken CPUs für Base Stations (Atom P, Snow Ridge) verwendet Intel 4,5 MiB pro Vierermodul, so bspw. im 24-Kerner P5962B. Dagegen in der Embedded-Version 6425E (Atom X, Elkhart Lake) kombiniert Intel die vier Kerne mit nur 1,5 MiB L2, vewendet also die kleinstmögliche Kombination.
**) Apple hat beim M1 aus den Vollen geschöpft, was wahrscheinlich zum Teil dem verwendetem N5 von TSMC zuzuschreiben ist, denn die großén Caches kosten einiges an Effizienz, die jedoch durch den modernen Prozess vermutlich besser ausgeglichen werden konnten. Dagegen die topaktuellen SoCs der Konkurrenz, die ARMs Cortex-X1 für den schnellen Kern verwenden, sind auf 1024 bzw. gar 512 KiB L2 beschränkt (zzgl. 64+64 KiB L1) und verwenden für die CPU nur 4 MiB shared L3, was möglicherweise daran liegt, dass der Snapdragon 888 und Exynos 2100 nur Samsungs 5LPE verwenden, das eher mit TSMCs NextGen-7nm-Prozessen vergleichbar ist bzgl. Performance und Effizienz. Das ARM-Design sieht beim X1 grundsätzlich nicht mehr als maximal 1 MiB L2 vor, aber für den shared L3 hätte man bei diesen SoCs auch bis zu 8 MiB implementiert können, wovon jedoch beide Hersteller absahen. Möglicherweise hätte das zu sehr auf die Effizienz geschlagen?
***) Zudem mit Blick auf Performance und Effizienz ist bei architektonischen Lösungen auch die Frage ob die jeweiligen Hersteller, so bspw. Intel und AMD mit x86 ggf. patentrechtlichen Beschränkungen unterliegen, die es ihnen verwehren einige (mittlerweile allgemein bekannte) Bauweisen zu verwenden, die vielleicht noch von ARM als Patente gehalten werden?
Letzten Endes ist ARM zudem bzgl. Effizienz augenscheinlich noch längst nicht der Weisheit letzter Schluss, weil mittlerweile anscheinend noch einiges mehr geht.
Micro Magic, Inc. stellte Ende letzten Jahres den bis dahin schnellsten RISC-V-Kern vor. Mit 0,8 V soll ein einzelner Kern rund 11.000 CoreMark-Punkte erreichen bei 4,25 GHz und gerade mal 200 mW. Ein Raspberry Pi 3 B mit seinen vier Cortex-A53 erreicht bei 1,2 GHz gerade mal 13717 Punkte und zieht netzseitig rd. 4,7 W (2,0 W im Leerlauf). (Mit 1,1 V erreichte ein solcher Kern gar 5,0 GHz und 13.000 CoreMark Punkte. Micro Magic stellt die Erreichung von bis zu 110000 CoreMark Punkten pro Watt in Aussicht, jedoch muss man hier abwarten, wann die Entwicklung zu ersten, echten Produkten führen wird.)
Zur besseren Einordnung: Der EEMBC CoreMark ist ein im Embedded-Bereich genutzter Benchmark und bildet vorrangig einfache Integer-Operationen ab.