Endlich schnell ! Intels »Goldmont« macht »Atom« wettbewerbsfähig

Mit dem ersten vollständigen Out-of-Order-Design »Goldmont« erreicht Intels Atom-Prozessor jetzt eine um rund 50 % höhere Integer-Rechenleistung als Vorgänger Silvermont. Im Bereich Krypto ist der neue Core sogar rund 290 Prozent schneller. Damit kommt Goldmont an ARMs stärkste Prozessoren heran.

Die für viele Anwendungen immer noch so wichtige Single-Thread-Performance von Intels »großen« CPUs, verbaut in Designs wie Skylake oder Kaby Lake, liegt über der von ARMs Top-Prozessoren Cortex-A72 und Cortex-A73 – freilich auf Kosten einer deutlich höheren Leistungsaufnahme. Das Gegenteil war bei Atom-Prozessoren der Fall: Um die Leistungsaufnahme für Embedded-Anwendungen in typischen Zielmärkten von ARM wettbewerbsfähig zu halten, musste Intel Kompromisse bei der Rechenleistung eingehen. Bislang konnte keine Atom-CPU mit der jeweils aktuellen Spitzen-ARM-CPU mithalten, zuletzt scheiterte man mit der Silvermont-Mikroarchitektur am Cortex-A72. 

Die jüngste Intel-Entwicklung Goldmont wurde ursprünglich für den Smartphone-Markt entwickelt, aus dem sich Intel bekanntlich verabschiedet hat. Als Atom E3900 [1] basierend auf der 14-nm-Apollo-Lake-Plattform findet Goldmont nunmehr Einzug in den Embedded-Markt, theoretisch könnte Intel zukünftig auch in seinem FPGA-SoCs Stratix 10 die ARM-Cortex-A53-CPUs durch Goldmont ersetzen, um mehr Rechenleistung auf Kosten von Leistungsaufnahme und Siliziumfläche zu erzielen.

Im Vergleich zur Vorgänger-CPU Silvermont, die zwei Instruktionen parallel decodieren kann, handelt es sich bei der Mikroarchitektur der Goldmont-CPU um ein 3-Issue-Out-of-Order-Design, dessen Pipeline mit zwei Stufen allerdings eine Stufe kürzer ist als die des Vorgängers (Bild). Bevor das Design näher erläutert wird, zunächst ein Blick auf die ARM-Konkurrenz. 

Schneller als A72, fast so schnell wie A73 

Die Tabelle zeigt Goldmont im Vergleich zu Arms Cortex-A72 und -A73. Auffällig ist der kleinere L1-Befehls-Cache, der auch mit dem um etwa 20 Prozent dichteren x86-Befehlssatz nicht kompensiert werden kann und somit eine geringere Trefferrate aufweist. Dafür hat er eine geringere Latenz (drei statt vier Taktzyklen) und eine höhere Assoziativität, wodurch weniger Zugriffskonflikte entstehen. Wegen der geringeren Latenz kann das Out-of-Order-Fenster mehr Anfragen enthalten. Desweiteren auffällig ist, dass die ARM-CPUs sieben sogar acht Instruktionen ausführen können, allerdings haben sie auch nur zwei oder drei Decoder, so dass dieser Unterschied in der Praxis nicht zum Tragen kommt. 

Im Vergleich zu Silvermont wird alleine durch die Mikroarchitektur eine um 50 Prozent bessere Integer-Rechenleistung erreicht, dazu kommen nochmal mindestens 10 Prozent durch die Implementierung in 14-nm-Fertigung statt in 22 nm – in Summe also 60 bis 65 Prozent. Verschlüsselungen werden durch neue SHA-Instruktionen und beschleunigte AES-Befehle sowie vorzeichenlose Multiplikation um sogar um fast 290 Prozent schneller ausgeführt, was allerdings auch dringend notwendig war, da z. B. der Atom Z3590 mit Silvermont gegenüber ARM-SoCs überhaupt nicht konkurrieren konnte.

Was ist das Ergebnis? Im Netz findet man diverse Benchmark-Ergebnisse (z. B. Geekbench 4, der Speicher-, Integer-, Gleitkomma- und Verschlüsselungs-Operationen ausführt) für Qualcomms Snapdragon 835, der offiziell zwar eine Qualcomm-eigene CPU mit der Bezeichnung »Kryo« enthält, die aber realistisch betrachtet eher einen Original-Cortex-A73 darstellt [2]. Vergleicht man diese mit den Atom-Prozessoren Z3590 (Silvermont) und T5700 (Goldmont), stellt man fest, dass der mit 2,4 GHz getaktete T5700 unter Linux Geekbench-4-Ergebnisse zwischen 1760 und 1800 Punkten erzielt [3] (unter Windows werden geringere Werte erreicht), der mit 2,5 GHz getaktete Z3590 unter Android zwischen 1100 und 1130 Punkte [4] und ein mit 2,45 GHz getakteter Snapdragon 835 kommt auf 2059 Punkte [5]. Bricht man diese Ergebnisse auf dieselbe Taktfrequenz herunter, ist der auf dem Cortex-A73 basierende Snapdra­gon 835 rund 15 Prozent schneller als ein Atom mit Goldmont-CPU. Mit dem Cortex-A72 befindet sich Goldmont hingegen mindestens auf Augenhöhe. Neben der CPU sind weitere Einflussfaktoren wie Speichercontroller, Schaltmatrix oder Stromversorgung für das Ergebnis verantwortlich, so dass man nur bedingt einen direkten Rückschluss auf die CPU ziehen kann.

Abgesehen von dem Snapdragon 835, der von Samsung mit dessen 10-nm-Prozess [6] gefertigt wird, nutzen im Embedded-Umfeld die meisten ARM-SoCs deutlich ältere Fertigungstechnologien. NXPs Layerscape-Chip LS2088A mit acht Cortex-A72 wird in 28-nm-Fertigung hergestellt. In diesen Fällen sind Intels Atom-Chips nicht nur bezüglich der Rechenleistung, sondern auch in puncto Chipfläche und Leistungsaufnahme wettbewerbsfähig – geschuldet dem Vorsprung der 14-nm-Fertigung gegenüber 28 nm. 

Breiteres Front-End 

Bei Goldmont wurde wie schon bei Silvermont die Sprungvorhersage in zwei getrennte Komponenten aufgeteilt, die zusammen arbeiten, um Trefferhäufigkeit, Genauigkeit und Leistungsaufnahme optimal auszubalancieren. Der erste Block steuert das Holen der Befehle und ist auf Vorhersagen mit geringen Verzögerungszeiten zugeschnitten. Der zweite Block – der im Zweifel den ersten überstimmt – kommt später in der Decodierstufe, er hat wesentlich mehr Zeit und Informationen für seine Vorhersagen zur Verfügung, was die Genauigkeit erhöht und die Leistungsaufnahme verringert. Der zweite Block steuert die spekulativen Anweisungen, die ans Backend übergeben werden, und er kann frühere Vorhersagen überschreiben, was die Gesamtrechenleistung verbessert und den Energiebedarf senkt. 

Die Programmzählerindizes in dem Sprungzielpuffer BTB legen die nächste Holadresse fest. Der BTB enthält einen vier Einträge großen Rücksprung-Stack-Puffer (RSB), um die im Instruktionsstrom erkannten Aufrufe (Call) und Rücksprünge (Return) zu behandeln. Der RSB kann durch Sprungfehlvorhersagen in diverser Weise verfälscht werden, es gibt jedoch Strategien, ihn aus solchen Szenarien wiederherzustellen. Korrekt vom BTB vor­hergesagte Verzweigungen führen zu einer Verzögerung von einem Taktzyklus im Instruktionsstrom, die Prefetch-Puffer sollten aber solche kleinen Verzögerungen sogleich neutralisieren.

Der L1-Befehls-Cache ist ein 32 KB großes 8-fach-assoziatives Design mit 64 Byte umfassenden Zeilen, die vor-decodierte Bits für zuvor decodierte Anweisungen enthalten. Die Cache-Zeilen sind paritätsgeschützt und die Ersetzung erfolgt gemäß einer Pseudo-LRU-Strategie (LRU steht für Least Recently Used, d. h. der Eintrag, auf den am längsten nicht zugegriffen wurde, wird durch einen neuen verdrängt). Der Befehls-Cache enthält eine Prefetch-Einheit, welche die nächste Zeile aus dem L2-Cache anfordern kann, um die Latenzzeit zu reduzieren. Die Instruktionsströme verlaufen außer für Verzweigungen und Ausnahmen (Exeptions) linear, daher ist dies ein sehr effektiver und kostengünstiger Ansatz.

Sobald eine Adresse vorhergesagt wurde, wird der L1-Befehls-Cache überprüft. Da die Kapazität kleiner oder gleich der minimalen Page-Größe mal der Assoziativität (4 KB × 8) ist, wird parallel zum Cache-Zugriff auch der L1-Befehls-TLB (ITLB) überprüft. Der L1-ITLB enthält 48 voll assoziative Einträge für die Übersetzung der 4 KB- oder 2 MB- großen Pages. Speicheroperationen auf Code-Pages (z. B. selbstmodifizierender Code) machen die ITLB-Page ungültig. Ein neuer L2-Pre-Decodier-Cache ent­hält 16 K Einträge, die zusammen mit einer 64-Byte-Cache-Linie für die Decoder Informationen über die Länge der zugehörigen Instruktionen geben, und somit den Durchsatz der Decoder steigern (wenn die Längeninformationen korrekt sind). 

 
Intel Goldmont

ARM Cortex-A72

ARM Cortex-A73
Befehlssatz
x86-64

ARMv8-A
ARMv8-A

Taktfrequenz (maximal)
2,6 GHz

2,8 GHz


2,5 GHz

Leistungsaufnahme (typ.) ...


Unbekannt
1,0 W

0,8 W

... bei Fertigungsprozess


Intel 14 nm FinFET
TSMC 16 nm FinFET+
TSMC 16 nm FinFET+

Pipeline

12 Stufen
15 Stufen11 Stufen

Decoder

3 x86 CISC

3 ARM RISC

2 ARM RISC


Ausführung parallel

3 µOPs
8 µOPs7 µOPs

Integer ALUs
332

SIMD 128 bit
222

L1-Cache Daten

24 KB, 6 Wege assoziativ


32 KB, 2 Wege assoziativ

32-64 KB, 4 Wege assoziativ

L1-Cache Daten parallele Zugriffe


128 bit Laden + 128 bit Speichern

128 bit Laden + 128 bit Speichern

2 × 128 bit beliebige Kombination


L1-Cache Daten Latenzzeiten minimal
3 Taktzyklen
4 Taktzyklen

4 Taktzyklen
L2-Cache
1-2 MB (2 Cores)

0,5-4 MB (bis zu 4 Cores)

0,3-8 MB (bis zu 4 Cores)

Rechenleistung pro MHz relativ
111,15

 

Vergleich der Goldmont-CPU mit den beiden aktuellen High-End-Cores von ARM.

Befehle decodieren 

Für die Befehls-Decodierung gibt es nunmehr drei statt zwei Decoder. Alle Anweisungen, die nicht mikrocodiert sind, werden von beiden Decodern bei vollem Durchsatz verarbeitet. Maximal können 20 Byte gelesen (statt 16 bei Silvermont) und drei Befehle pro Taktzyklus decodiert werden, wenn die erste Anweisung 4-Byte-Aligned ist. Alle drei Decoder können bis zu 4 Byte große Befehls-Präfixe ohne Ver­zögerung auflösen und Instruktionen beliebiger Länge decodieren. Bei Silvermont konnte nur ein Decoder Befehle größer als 8 Byte decodieren und zudem konnten nur Präfixe bis zu 3 Byte aufgelöst werden. Die neuen Decoder benötigen dazu weniger Mikrocode-Unterstützung aus dem ROM, die Mikrocode-Engine kann statt bislang zwei nun drei Mikro-Ops auswerfen. Eine weitere Verbesserung der Decoder gegenüber Silvermont ist die Verdoppelung der Verzweigungen pro Taktzyklus von eins auf zwei (vorausgesetzt, es handelt sich nicht um unmittelbar aufeinanderfolgende Verzweigungen). 

Wenn ein Verzweigungsbefehl deco­diert wird, kann die übergeordnete Sprung­vorhersage über verschiedene Mechanismen eine genauere Vorhersage abgeben. Für bedingte Verzweigungen wird eine Gshare-basierte Vorhersage verwendet, um zu bestimmen, ob gesprungen wird oder nicht. Die Zieladresse wird in dem Befehl selbst codiert.

Im Gegensatz dazu verzweigen indirekte Sprünge zu einer unbekannten Adresse, die in einem Register oder Speicher abgelegt ist. Indirekte Sprünge können mehrere Zieladressen haben und kommen üblicherweise in Interpreter-Sprachen (z. B. Android Dalvik) oder stark objektorientiertem Code vor. Ein spezielles Sprungvorhersage-Array für indirekte Sprünge prognostiziert die Zieladresse für indirekte Sprünge sowohl auf Basis des Programmzählers als auch der globalen Sprunghistorie. Schließlich umfasst die übergeordnete Sprungvorhersage einen 16 Einträge umfassenden Rücksprung-Stack-Puffer (RSB) für Aufrufe und Rücksprünge, es gibt an dieser Stelle keine RSB-Umbenennung, da Adressverfälschungen so spät in der Pipeline eher ungewöhnlich sind.

Während die BTB die Befehlsholung steuert, legt die übergeordnete Sprungvorhersage fest, welche Anweisungen spe­kulativ zur Ausführung in das Out-of-Order-Backend geschickt werden. Wenn die Sprungvorhersage korrekt war, muss die Pipeline nicht geleert werden. Wenn allerdings die frühere BTB-Vorhersage korrigiert wird, wird die Befehlsholung abgewürgt während das Front-End zurückgesetzt wird. Wenn z. B. der Prädiktor Gshare eine Verzweigung korrekt vorhergesagt hat und diese nicht mit dem BTB übereinstimmt, wird eine Verzögerung von sechs Taktzyklen erzeugt.

Die komplexe Sprungvorhersageeinheit vermeidet häufig das in Bezug auf verschwendete Taktzyklen »teure« Leeren der Pipeline. Die Verzögerung einer Fehlvorhersage beträgt zehn Taktzyklen. Darüber hinaus können die Decoder starten, sobald der korrekte Pfad bekannt ist, anstatt auf die vollständige Leerung der Pipeline zu warten. Die Verschiebung der übergeordneten Sprungvorhersage auf spä­ter in der Pipeline ist auch sehr nützlich für den Energiebedarf: Sie wird so nur verwendet, wenn ein Sprung in der Decodierung erkannt wird, statt in jedem Taktzyklus zu überprüfen.

Die 32 Einträge umfassende Befehlswarteschlange mit den decodierten Mikro-Ops trennt das Front-End der Pipeline von der Out-of-Order-Maschinerie und arbeitet auch als »Schleifen-Cache«. Bei der Ausführung aus dem Schleifen-Cache wird das gesamte Front-End per Clock-Gating von der Taktversorgung abgeschnitten, um die Energieaufnahme zu reduzieren. Darüber hinaus kann die Warteschlange einen Teil der Pipeline-Verzögerungen neutralisieren, die durch die übergeordnete Sprungvorhersage hervorgerufen werden. 

Out-of-Order-Befehlsausführung 

Der Out-of-Order-Teil der Pipeline be­an­sprucht drei Taktzyklen: Zwei für die Umbenennung und Zuweisung der erforderlichen Register, um einen Befehl bis zur endgültigen Erledigung zu verfolgen, und einen Dritten für das Einbringen des Befehls in die Ausführungsscheduler. 

Befehle werden in der Reihenfolge des Programms aus der Befehlswarteschlange an die Out-of-Order-Engine geschickt. Der erste Schritt ist die Zuweisung der entsprechenden Puffer und die Umbenennung der architektonischen Register in physikalische Register. Dazu verwendet die Registerumbenennung einen separaten 78 Einträge umfassenden Reorder-Puffer (ROB) und physikalische Registersätze. Jeder Befehl wird von einem der 78 ROB-Einträge allokiert, wo Informationen über den Status, Verzweigungen und Ende der Ausführung gespeichert und verfolgt werden. Es gibt zwei physikalische Registersätze, einen für Integer- und einen für SSE- und Gleitkommadaten. Beide haben 96 Einträge. Speicheroperationen allokieren in den Lade- und Speicher-Puffern Einträge, die eine korrekte Reihenfolge erzwingen.

Sobald ein Befehl umbenannt und zugeteilt wurde, wird er einer oder mehreren Warteschlangen zugewiesen. Goldmont setzt auf verteilte Scheduler und Warteschlangen, die Mikro-Ops enthalten, bis diese für die Zuweisung an eine der Ausführungseinheiten bereit sind. Dieser Ansatz unterscheidet sich deutlich von einem einheitlichen Scheduler, der in anderen Hochleistungskernen von Intel eingesetzt wird.

Verteilte Scheduler sind aus der Perspektive einer Durchsatzmaximierung weniger flexibel und effizient. So bleibt bei der Ausführung von Code, der nur Integerwerte verarbeitet, die Gleitkommaeinheit unbenutzt und wird mittels Clock-Gating von der Taktversorung abgekoppelt. Allerdings ist die Energie, die durch einen Scheduler aufgenommen wird, nicht proportional zur Anzahl der wartenden Befehle, so dass mehrere kleinere Scheduler oft energieeffizienter arbeiten als ein einzelner großer Scheduler. Keiner der Ansätze ist grundsätzlich besser, sie repräsentieren lediglich unterschiedliche Optimierungspunkte.

Goldmont enthält fünf Scheduler. Jeder Scheduler ist an eine dedizierte Ausführungseinheit gekoppelt und akzeptiert nur die zugehörige Art von Mikro-Ops. Die drei Integerscheduler haben jeweils zehn Einträge und enthalten die Eingangsoperanden, die aus den Registersätzen oder anderen Quellen gelesen werden. Sobald alle Eingabeoperanden verfügbar sind, kann der Mikro-Op an die Ausführungseinheit geschickt werden. Befehle können beliebig von jedem Scheduler an Port 0, 1 oder 2 oder an allen dreien zugewiesen werden. Der Scheduler schickt generell das älteste Mikro-Op. Ein Gleitkommascheduler hat 20 Einträge, darunter aber keine Daten. Stattdessen werden die Eingangsoperanden gelesen, wenn der Befehl an die Ausführungseinheiten geschickt wird, um die Transfers der größeren 128-bit-SSE-Daten zu minimieren. Der Scheduler weist die Instruktionen Port 0 oder 1 zu und arbeitet, anders als Silvermont, vollständig Out-of-Order. Der zehn Einträge umfassende Speicherscheduler ist genauso an zwei Ports angeschlossen und arbeitet ebenfalls vollständig Out-of-Order. Jeder Port ist an einen bestimmten Satz von Integer-, Gleitkomma- und Speicherausführungseinheiten gebunden. 

Ausführungseinheiten 

Jeder der verteilten Scheduler weist den ältesten zur Ausführung bereiten Mikro-Op dem entsprechenden Port zur Abarbeitung zu. Die Integer­scheduler enthalten die Eingangsoperanden für die zugehörigen Mikro-Ops, so dass diese Daten zusammen mit dem Mikro-Op verschickt werden. Auf der Integer­seite führen beide Ports (0 und 1)grundlegende ALU- und logische Operationen aus. Port 0 enthält auch einen Integer­schieber und wandelt Gleitkommazahlen in Integerwerte um. Port 1 führt LEA-Anweisungen aus (berechnet LEA-Instruktion, lädt die effektive Adresse einer Speicherstelle und legt diese in ein Allzweck-Register), d. h. Basis + Index + Offset und kümmert sich um Verzweigungsbefehle, grundlegende Bit-Verarbeitung, Integermultiplikationen und -divisionen sowie die Berechnung von Prüfsummen (CRC). Port 2 wandelt Integer- in Gleitkommazahlen um und kümmert sich um die Zusammenführung der Flags. LEA-Anweisungen ohne Index können übrigens von allen drei Ports ausgeführt werden. 

Die Gleitkommascheduler enthalten keine Daten, um die Leistungsaufnahme zu reduzieren. Daher müssen die Eingangsoperanden nach der Zuweisung für die Ausführung aus dem Architekturregistersatz und den Umbenennungspuffern gelesen werden. Beide Ports enthalten Vektor-ALUs für grundlegende arithmetische und logische Operationen. Port 0 führt SIMD-Integerverschiebungen und -vermischungen für jeden denkbaren Datentyp durch. Vielleicht am wichtigsten ist, dass Port 0 einen 64-bit-Vektor-Multiplizierer enthält, der sowohl für Integer- als auch für Gleitkommadaten verwendet wird. Viele andere Anweisungen werden ebenfalls mit Port 0 ausgeführt, einschließlich AES-NI (mikrocodiert), SSE4.1 (bedingtes Überblenden), den String-Verarbeitungsanweisungen in SSE4.2, der neuen SHA-Verschlüsselung und einer vorzeichenlosen Multiplikation für die Verschlüsselung. Die Gleitkommaeinheit auf Port 1 besteht im Wesentlichen aus dem Gleitkommaaddierer, sie vergleicht Gleitkomma- mit Integerzahlen und hat die neue SIMD-Shuffle-Einheit.

Mit verschiedenen Techniken hat Intel den Durchsatz auf der Integer- und auf der Gleitkommaseite gesteigert. Speziell durch Änderungen an den Ausführungseinheiten konnte z. B. eine Gleitkommaaddition mit doppelter Genauigkeit um Faktor 2 bis 4 beschleunigt werden, die Division um Faktor 2 bis 3. Verschlüsselungsoperationen wie eine vorzeichenlose Multiplikation oder AES-Verschlüsselung sind doppelt so schnell wie bei Silvermont.

Verschiebungen von Registerinhalten werden mit einer bei »Ivy Bridge« eingeführten Technik vereinfacht, nämlich durch einen Wechsel der Umbenennungs­tabelle. Die Decoder enthalten eine sogenannte Stapelzeiger-Engine, so dass die Berechnung des Stapelzeigers keine Ressourcen verschlingt und die Operationen PUSH und POP zu einfachen ALU-Instruktionen mutieren. 

Speichersystem und Speicherzugriffe 

Die größten Verbesserungen erzielt Goldmont zweifelsfrei im Speichersystem. Lade- und Speicherbefehle allokieren einen von 20 Einträgen in den Lade- und Speicher-Puffern, bevor sie an den Scheduler gehen. Dieser weist Operationen zur Adressgenerierung für Ladebefehle an Port 0 und für Speicherbefehle an Port 1 zu. Da der Scheduler bei Goldmont vollständig Out-of-Order arbeitet, können Ladebefehle vor älteren Speicherbefehlen ausgeführt werden, was potenziell zu Speicherkonflikten führen kann. Speicher-Disambiguierung trifft eine Vorhersage, ob eine Ladeoperation mit einer älteren Speicheroperation, deren Adresse noch nicht bekannt ist, in einen Konflikt geraten wird. Wird ein solcher Konflikt vorhergesagt, kann die CPU die Operationen In-Order ausführen, um bei einer potentiellen Verletzung der Speicherordnung zeitaufwendiges Löschen der Pipeline zu verhindern. 

Goldmonts L1-DTLB ist eine vollständig assoziative Struktur mit 32 Einträgen, welche die Übersetzung von virtuellen auf physische Adressen für 4-KB-Pages zwischenspeichern. Nicht erfolgreiche Zugriffe auf den L1-DTLB werden dann von dem L2-DTLB bearbeitet, einer 4-fach assoziativen Struktur mit 512 Einträgen (Silvermont: 128) für 4-KB-Pages und 32 Einträgen (statt 16) für große 2-MB-Pages.

Der L1-Datencache hat ein 24 KB großes Datenarray und ist 6-fach assoziativ mit 64 Byte umfassenden Cachezeilen. Der Cache arbeitet mit einer pseudozufälligen Ersetzungsstrategie. Da die minimale Page-Größe 4 KB beträgt, kann der Zugriff auf den DTLB und eine Überprüfung des L1-Daten-Tags parallel vorgenommen werden. Der L1-Datencache ist physikalisch mit 8T-Zellen und Paritätsschutz statt mit fehlerkorrigierenden Codes (ECC) implementiert. Um mehrere Zugriffe zu ermöglichen, ist er in 16 Bänken organisiert, aus denen pro Taktzyklus jeweils 4 Byte Daten gelesen werden können. Der L1-Datencache kann gleichzeitig eine Leseanforderung im Umfang von 16 Byte von dem Scheduler oder der Reissue-Warteschlange sowie eine Schreibanforderung ebenfalls im Umfang von 16 Byte von den Speicher-Datenpuffern bedienen. Im Gegensatz zu Silvermont, wo dieser Durchsatz nicht konstant aufrechterhalten werden konnte, weil nur eine einzige Operation pro Taktzyklus ausgelöst wird, kann Goldmont den Durchsatz unbegrenzt liefern. Der L1-Datencache wird durch einen große einheitlichen L2-Cache ergänzt, der von jeweils zwei Cores geteilt wird. Der L2-Cache ist 1 bis 2 MB groß, arbeitet 16-fach assoziativ und hat eine Latenzzeit mindestens 14 Taktzyklen (vom Laden aus dem Speicher bis zur Einsatzbereitschaft). Da jeder Core nur sechs Misses auf den Datencache haben kann, ist es möglich aber außerordentlich unwahrscheinlich, dass die Speicherpipeline durch das Warten auf einen Treffer im L2-Cache blockiert wird. Der L2-Cache weist ein Writeback-Design mit vollem ECC-Schutz auf und arbeitet mit einem Pseudo-LRU-Ersetzungsverfahren. Goldmont hat einen einfachen Prefetcher für die nächste Zeile im L1-Datencache sowie auch im L2 einen zudem noch anspruchsvolleren Prefetcher. Intel legt die Anzahl der möglichen L2-Cache-Misses nicht offen, es sind wahrscheinlich aber mehr als 16, um Misses beim Laden, bei Befehls-Ladeoperationen und beim Pre­fetching von beiden Cores gerecht zu werden. Pro Taktzyklus können aus dem L2-Cache 32 Byte gelesen werden, Cache-Misses führen über die XQ-Warteschlange, welche ausstehende Lese- und Schreibzugriffe überwacht, zu einem Zugriff auf die On-Chip-Schaltmatrix.

Da physikalische Adressen mit 39 bit Breite angesprochen werden können, beträgt der maximale Adressraum 512 GB, was 8-mal soviel ist wie bei Silvermont. Die minimale Latenzzeit bei Integerzugriffen beträgt drei Taktzyklen, für 128 bit breite Gleitkommazahlen und Vektoren kommt noch ein Taktzyklus dazu. Das Store-to-Load-Forwarding ist bei Goldmont einen Taktzyklus langsamer als bei Silvermont (vier statt drei). 

Fazit 

Es ist irgendwie schon eine abstruse Situation: Da entwickelt Intel eine CPU, die zum ersten Mal tatsächlich für Smartphones geeignet erscheint, doch ausgerechnet dann steigt der Chiphersteller aus genau diesem Geschäftsfeld aus. Profitieren soll nun neben dem Kommunikationsmarkt, für den Ende 2017 ein SoC namens Deverton mit 16 Goldmont-Cores und Netzwerk- sowie Verschlüsselungs-Beschleunigerblöcken erscheinen wird, der Embedded Markt, was durchaus realistisch erscheint, würden die Kalifornier endlich beginnen, dafür besser geeignete SoCs zu bauen, als es mit Apollo Lake der Fall ist [1]. 

An der Goldmont-CPU jedenfalls liegt es nicht, wenn diese Märkte weiter ARM-dominiert sein werden. Gegenüber dem Vorgänger Silvermont ist das Goldmont-Design – auch wenn dies physikalisch natürlich vollkommen falsch ausgedrückt ist – zumindest umgangssprachlich ein »Quantensprung«. 

Referenzen 

[1] Riemenschneider, F.: Eintauchen in Intels Apollo Lake. DESIGN&ELEKTRONIK, Ausgabe 2/2017, S. 85ff.

[2] Riemenschneider, F.: Snapdragon 835 ist erster 10-nm-Chip. DESIGN&ELEKTRONIK, Ausgabe 7/2017 (geplant).

[3] Geekbench-4-Benchmark-Ergebnisse für Intel Atom T5700: http://bit.ly/2pNVZU6

[4] Geekbench-4-Benchmark-Ergebnisse für Intel Atom Z3590: http://bit.ly/2pHZMla

[5] Geekbench-4-Benchmark-Ergebnisse für Qualcomm Snapdragon-835: http://bit.ly/2qI4nSZ

[6] Riemenschneider, F.: Samsung ist neuer Fertigungsmeister. DESIGN&ELEKTRONIK Ausgabe 3/2017, S. 13 ff.