»Artemis« zu gut für Konkurrenz?: ARM Cortex-A73 toppt High-End-CPUs

In einem 10-nm-Prozess sollen ab 2017 erste SoCs mit ARMs neuer High-End-CPU Cortex-A73 von vermutlich Intel-Fabriken ausgeliefert werden. Für eine maximale Energieeffizienz wurde die Architektur des A72 an der einen oder anderen Stelle sogar zurückgebaut – mit bemerkenswerten Ergebnissen.

Keine Fehlerkorrektur im L1-Cache

Bild 3: Die Sprungvorhersage wurde auch beim Cortex-A73 nochmals besser.

Um Siliziumfläche und Energie einzusparen, wurde bei der Verbindung zu Schaltmatrizen wie der CCI-400 auf einen AMBA-5-Port verzichtet und sich auf einen AMBA-4-ACE mit bidirektionaler 128-bit-Schnittstelle beschränkt. Beim L1-Cache wurde im Gegensatz zum L2 auf fehlererkennende und -korrigierende Codes (ECC) verzichtet, was den Einsatz des A73 in vielen sicherheitsrelevanten Märkten ausschließen dürfte – für diese wird es 2017 erste CPUs auf Basis der ARMv8-R-Architektur geben. Davon abgesehen ist der Cortex-A72 für Embedded- und Server-Tasks, die rechenintensive Vektor-Operationen und große Datensätze nutzen, mit seiner komplexeren Mikroarchitektur ohnehin besser geeignet.

Einen Schwerpunkt der Optimierung setzte ARM in der Befehlscode-Ladestufe auf die Vermeidung sogenannter Lücken (»Bubbles«). Diese entstehen durch Ressourcenkonflikte, wenn Zugriff auf eine Ressource benötigt wird, die bereits von einer anderen Stufe belegt ist. Diese Konflikte erfordern es, dass entsprechende Befehle am Anfang der Pipeline warten (»stallen«), was die Bubbles in der Pipeline erzeugt. Dies führt dazu, dass die Pipeline nicht optimal ausgelastet ist und der Durchsatz sinkt. Indem die Instruktionen früher als bei A17 und A72 in µOps aufgeteilt werden, konnten Pipeline-Lücken laut ARM quasi vollständig eliminiert werden.

Fast schon traditionell investiert ARM viel Zeit in die Verbesserung der Sprungvorhersage (Bild 3). Dies ist kein Wunder, führt doch jede Fehlvorhersage zum Löschen der Pipeline, was die hohe IPC (Befehle pro Taktzyklus) ruiniert. Bedauerlicherweise werden diese Verbesserungen jedoch auch regelmäßig als Staatsgeheimnis behandelt. Was wir wissen ist, dass der Sprungzieladressen-Puffer (BTAC) weiter vergrößert wurde und dass ein zusätzlicher Micro-BTAC hinzugekommen ist, der nur 64 Einträge umfasst und Geschwindigkeitsgewinne bei wenigen aber häufig angesprungenen Zieladressen bringt. Um die immer noch verbliebenen Fehlvorhersagen möglichst energieeffizient abarbeiten zu können, wurde ein Stack mit Rücksprungadressen für verschachtelte Unterprogramme eingeführt.