smalM schrieb:
Bei der Effizienz wird x86 immer das Poblem haben einen CISC-Befehlssatz abarbeiten können zu müssen. Moderne Compiler versuchen zwar x86-Code zu erzeugen der möglichst wie RISC aussieht, da das bei der Dekodierung Aufwand spart und damit den Stromverbrauch mindert, aber die kompletten Resourcen müssen dennoch vorgehalten werden.
Der Decodingeinheit ist es aber weitgehend egal, ob sie in einem kleinen ULV-Chip oder einem riesigen Multi-Core-Xeon mit zig integrierten, breiten PCIe- und Speichercontrollern usw. arbeitet. Die skaliert nicht wirklich mit der Leistung.
Im Low-End-Energiesparbereich fällt der CISC-Nachteil also bei der Effizienz stärker ins Gewicht, bei größeren CPUs verschwindet er schnell im Hintergrundrauschen. Deshalb hat ARM sich im Mobil-Segment behaupten können und x86 bei den PCs und Servern halten können.
Tatsächlich wird der x86-Decoder aber inzwischen wohl selbst bei sparsamen Mobil-SoCs nicht mehr viel ausmachen. Als AMD sich vor ca. 15 Jahren dazu entschied, seiner ersten 64Bit-CPU weiterhin x86-Kompatibilität mitzugeben (im Gegensatz zu Intels Itanium), nahm der Decoder schon nur noch
10% der Die-Fläche ein. Das war es AMD damals nicht wert, auf x86-Kompatibilität zu verzichten.
Ein Sledgehammer hatte 100 Millionen Transistoren. Apples A10 hat 3,3 Milliarden. Ein 32-Core-Epyc 19,2 Milliarden!
Da kann man sich ungefähr vorstellen, wie viel der CISC-Overhead im Frontend wahrscheinlich noch ausmacht.
Solange x86-Kompatibilität noch die kleinste Rolle spielt, und sei es nur, dass die Softwareentwickler damit und mit den entsprechenden Entwicklungstools etwas vertrauter sind, wird man es sich stark überlegen, auf CPUs zu wechseln, die das nicht mehr bieten.
)
