UPDATE: Mit erstem iPhone 6 Video

Unsere Prognose zu Apples A8-Chip im iPhone 6

1. September 2014, 16:04 Uhr | Frank Riemenschneider

Fortsetzung des Artikels von Teil 1

Der Weg zur Cyclone-CPU - Teil 1

Bevor wir die CPU-Core-Prognose beginnen, soll zum besseren Verständnis nochmals die Entwicklung von Swift zu Cyclone dargestellt werden. In der Tabelle sind beide Architekturen nebeneinandergestellt, eine umfängliche Analyse und ein Schaubild der Mikroarchitekturen finden Sie für Swift bzw. Cyclone in den beiden verlinkten Artikeln.

Abgesehen von der Änderung des Befehlssatzes von ARMv7 zu ARMv8 fällt die Verdoppelung der Anzahl der Befehlsdekoder ins Auge. Dies bedeutet, dass der Cyclone-Core doppelt so viele Befehle wie Swift gleichzeitig bearbeiten kann. Mit ihren identischen Taktraten ist es leicht zu sehen, wo die behauptete Beschleunigung um Faktor 2 herkam. Es erklärt auch, warum man keine Quald-Core-Architektur gebaut hat: Ein breiterer CPU-Core liefert mehr Rechenleistung ohne den Overhead zusätzlicher Schaltkreise für einen zusätzlichen Core, auf dem unabhängige Threads laufen. Dafür gibt es ein anderes Problem: Die parallele Ausführung von derart vielen Befehlen führt oft zu Datenabhängigkeiten. Wenn ein Befehl vom Ergebnis des anderen abhängt, wird diese Anweisung blockiert, bis die erforderlichen Daten bereitstehen, was den Prozessor insgesamt verlangsamt.

Dies führt uns zu dem Re-Order-Puffer. Es ist mehr als viermal so groß wie bei Swift, das heißt, die Befehlsausführreihenfolge kann so verschoben werden, dass diese Datenabhängigkeiten sich so gut wie nie sich in der tatsächlichen Ausführung manifestieren.

Desweiteren hat sich die Latenz für Sprungfehlvorhersagen leicht erhöht. Dies ist wahrscheinlich ein Nebenprodukt eines komplexeren Cores mit mehreren parallel ausgeführten Befehlen und einer längeren Pipeline. Dies bedeutet, dass wenn man eine bedingte Verzweigung erreicht, die auf einer Variablen basiert, welche erst zur Laufzeit bestimmt wird, muss man Annahmen über das Ergebnis dieser bedingten Verzweigung treffen, um Anweisungen, die nach ihr kommen, ohne auf das Ergebnis warten zu müssen, ausführen kann. Für den Fall, dass die CPU-Architektur falsch „rät“, muss die Pipeline gelöscht und alle Ergebnisse verworfen werden, die von einer korrekten Vorhersage abhingen. Alle Techniken, die zu einer Verringerung der Fehlvorhersage führen, zu diskutieren, würde den Rahmen dieses Beitrags sprengen, generell handelt es sich um einen wichtigen Teil der CPU-Architektur, der einen wesentlichen Beitrag zur Gesamt-Rechenleistung beiträgt. Außerdem wurde neben der Verdoppelung der Ausführungseinheiten für Verzweigungen noch eine Einheit für indirekte Sprünge hinzugefügt. Dies ist eine Art von Verzweigung, bei welcher die Zieladresse nicht unmittelbar bekannt ist, da sie in einer Speicheradresse abgelegt ist. Da diese Adressen nicht zwangsläufig in den Cache geladen werden, kann es eine Weile dauern, um diese Daten abzurufen, so dass eine Einheit, die speziell für diese Fälle designt wurde, die Anzahl ungenutzter CPU-Taktzyklen reduzieren kann.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

	Apple A6	Apple A7
CPU-Codename	Swift	Cyclone
Befehlssatz	ARMv7-A 32 bit	ARMv8-A 32/64 bit
Befehlsdekoder	3	6
Reorder-Puffer-Größe	45 Mikro-Ops	192 Mikro-Ops
Latenz Sprungfehlvorhersage	14 Taktzyklen	14-19 Taktzyklen (typisch: 16)
Integer-ALUs	2	4
Laden-/Speicher-Einheiten	1	2
Latenzzeit Daten laden	3 Taktzyklen	4 Taktzyklen
Verzweigungseinheiten	1	2
Einheiten für indirekte Sprünge	0	1
Gleitkomma/NEON-Einheiten	3	3
L1-Cache (Befehle/Daten)	32 KB/32 KB	64 KB/64 KB
L2-Cache	1 MB	1 MB
L3-Cache	-	4 MB