mae schrieb:
Gegenbeispiel AMD64: Tremont; hat keinen uop-Cache.
Gegenbeispiel ARM: Cortex-A77 und A78: haben einen uop-Cache.
Aber andere Caches stellen auch einen side channel dar.
Ich habe auch nicht gesagt das ARM gegen side channel immun ist. Ich habe lediglich festgestellt dass die x86 big cores sehr auf µop Caches angewiesen sind, da variable instruction length decoder einfach riesig und kompliziert sind. Die sind daher nur 4-wide, ohne decoder recycling geht nicht nur power draw stark nach oben, sondern wird auch die pipeline superbreiter cores wie willow cove, golden cove, etc. nicht ausreichend gefüllt.
Das ARM cores meistens keinen µop cache brauchen liegt ja eben daran dass es keine fetteb cores sind wie die x86 "big-core" designs. Außerdem können die decoder für fixed instruction length ohnehin viel einfacher sein, viel weniger energie verbrauchen und große caches ohne vielen aufwand und großem power draw realisiert werden.
ARM hat den µop $ erst mit Hercules/A78 eingeführt weil es vorher einfach keinen bedarf gab und mit 1,5K entries ist der auch gerademal auf sandybridge niveau. Man hätte stattdessen auch 5-wide oder 6-wide decode gehen können, da man seit dem a76 das frontend nicht verbreitert hat. Das heißt nicht dass Dinge wie µopcache und instruction fuse die x86 seit Jahren machen für ARM keinen Sinn machen. Irgednwann werden die das auch brauchen wenn die Cores immer breiter werden. Aber während x86 darauf jetzt schon angewiesen ist um das frontend nicht zum bottleneck werden zu lassen ist das bei ARM einfach nicht so dringend notwendig.
Und Tremont ist ein small Core und noch dazu eine Krücke, das ist eher ein Argument pro µop-cache.
mae schrieb:
Gegenbeispiel: AMD K7, K8, K10: 64KB L1, 2-way set-associative.
ja und IPC, effizienz-technisch weit abgeschlagen in 2021. Das heißt dass mit pech jede menge zeug geladen wird welches man nicht braucht und nur in sonderfällen werden die 64kb gut ausgenutzt. Und die line size ist trotzdem 64byte.
Ein wichtiger Faktor für die Effizienzgewinne von Zen1 gegenüber Bulldozer war die Einführung des µop caches.
mae schrieb:
Gegenbeispiel: Ein Cyrix-Prozessor (6x86? M1?) hat alle Zweierpotenzen ab 4K unterstuetzt; hat sich aber nicht durchgesetzt.
Interessant! Das hat bei Cyrix aber andere Gründe dass die es nicht geschafft haben. Wie setzen die das um wenn die x86 ISA das nicht anbietet?
mae schrieb:
ARM selbst arbeitet aber mit 4KB-Seiten. Ein interessanter Fall ist RISC-V, die sie auf 4K festgelegt haben, die meinen also offenbar, dass groessere Seiten keine nennenswerten Vorteile bieten.
Ja, der cache unterstützt variable page sizes. Apple kann zwischen 64, 32, 16 und 4kb hin und her schalten und legt dann die jeweiligen ungenutzten blöcke schlafen. So nutzen sie immer die gesamte Assoziativität aus, anders wäre der zusammen 384kb große L1 Cache (größer als der Comet Lake L2 cache!) gar nicht möglich in einem Iphone-Power Budget.
Alle aktuellen ARM CPUs verwenden größere page sizes als 4KB und haben größere Caches mit geringerer assoziativität als aktuelle x86 CPUs.
Aktuelle x86 cores haben 32kb/8way I und Data caches mit tigerlake als ausnahme mit 48kb 12-way
ARM cpus bis zum A76, A77, A78 haben traditionell je 64kb I- und Data Cache mit lediglich 4-way Assoziativität. Das kostet weniger Diefläche und Energie, hat aber dank 16kb page size eine ähnlich gute vllt. sogar bessere hitrate.
