Leistung und Zuverlässigkeit

Hard- und Softwareaspekte für optimierte Embedded Systeme

Seite: 2/2

Anbieter zum Thema

In der folgenden Tabelle sind die Ergebnisse exemplarisch für einige CPUs gegenübergestellt. Andere CPUs mit anderen Speichern ergeben natürlich andere Werte! Wichtige Erkenntnisse liefert der Faktor der Beschleunigung. Dieser variiert zwischen 3 und 30. Eine „gute“ Programmierung kann damit oftmals von sehr viel größerer Bedeutung sein, als eine schnellere CPU.

CPU
MHz Vertical (Code1)
msec.
Vertical
MB/sec
Horiz. (Code2)
msec.
Horiz.
MB/sec
Faktor
Vert./Horiz.
ARM Cortex-A9
NXP i.MX6
800 19782 20 1209 338 16
ARM Cortex-A9
Xilinx Zynq
666 20077 20 1399 292 14
PowerPC
QorIQ P2020
1200 41415 9 1351 303 30
Vortex86-DX 800 15676 26 5246 78 3
Intel i7
2100 1480 270 376 1080 4

Was bedeuten die Unterschiede für die Gesamtperformance?

Tabelle 2 und Tabelle 3: Links ist die Ausführung des C-Code 1 dargestellt, rechts die Ausführung des C-Code 2. Das Laden und Lesen der Daten aus den jeweiligen Caches hat erheblichen Einfluss auf die gesamte Systemperformance.
Tabelle 2 und Tabelle 3: Links ist die Ausführung des C-Code 1 dargestellt, rechts die Ausführung des C-Code 2. Das Laden und Lesen der Daten aus den jeweiligen Caches hat erheblichen Einfluss auf die gesamte Systemperformance.
(Bild: MicroSys)

Das Ausführen von C-Source 1 wird in Tabelle 2 dargestellt und zeigt das Lesen von Daten in vertikaler Reihenfolge. Das Ausführen von C-Source 2 wird in Tabelle 3 dargestellt und zeigt das Lesen von Daten in horizontaler Reihenfolge.

Zunächst die Analyse von Tabelle 3 (Abbildung rechts). Es soll von Adresse $0000 ein 32bit Wert geladen werden. Der Wert befindet sich nicht im L1/L2 Cache, deswegen wird per Burst Read mit 32 oder 64 Byte (je nach Cache Line Size) das RAM gelesen (blau). Dieses dauert im Vergleich zum Lesen aus dem Cache extrem lange. Die CPU wartet („stallt“), bis der Wert im L1-Cache angekommen ist und gelesen werden kann (grün). Die nächsten Zugriffe auf $4, $8, $C, $10… kommen dann direkt aus dem L1-Cache, sind also extrem schnell gelesen (grün). Somit wurde für acht mal 32Bit lesen nur einmal auf das RAM gewartet und die sieben weiteren Zugriffe kamen aus dem L1-Cache.

In Tabelle 2 (links) hingegen wird $1000 und gleich danach $2000 gelesen. Wie auch oben beschrieben wird beim Lesen von $1000 eine ganze Cache Line gelesen (blau). Der folgende Zugriff auf Adresse $2000 muss also zunächst warten (rot), bis die Cache Line für Adresse $1000 fertiggelesen ist und danach wird erst die Cache Line für $2000 gelesen. Die CPU Stallt (rot) hier also so lange, bis die Daten an $2000 im Cache Verfügbar sind. Somit wird für jedes 32Bit lesen einmal auf den RAM Zugriff gewartet, bevor es weitergehen kann.

Typischerweise sind die L1 Caches 32 KByte groß und enthalten 1024 Daten Lines a 32 Byte (Cache Line Size). In diesem Beispiel werden jetzt genau 1024 Zeilen gelesen, wodurch der Cache exakt genau gefüllt sind. Somit können die weiteren Daten bei $X004 / $X008 / $X00C bei der nächsten Runde nun aus dem Cache gelesen werden. Soviel zur Theorie, die aber leider so nicht ganz stimmt. Denn die Caches sind meist „multi-way set associative“, was dazu führt, dass sich nicht alle Daten eines 32 KByte linearen Blockes auf mal im Cache befinden und somit dann doch einige Zeilen mehrfach gelesen werden müssen.

Weiterhin spielt die MMU (Memory Management Unit) eine maßgebliche Rolle für die Systemleistung. Jede MMU Page ist 4 KB groß (ARM kann auch 64 KByte). Ein Eintrag zeigt also auf genau eine Datenzeile von 1024*32bit. Da die Adresse $0 nicht in der MMU-Tabelle zu finden ist, wird eine Exception ausgelöst, um per Software den MMU-Eintrag für diese Adresse erneut zu laden, was folglich für jeden Zugriff geschieht. Hier hat der PowerPC einen kleinen Nachteil, da er nicht wie bei ARM & X86 mit L1/L2 Tabellen arbeitet, sondern 512 Einträge a 4 KByte besitzt und somit in jedem Durchlauf eine Exception für die Zeile erzeugt, was den schlechteren Faktor 30 (Tabelle 1) für den PowerPC erklärt. Wenn das Beispiel etwas geändert wird (Array mit 512*512 statt 1024*1024), dann hat der PowerPC nur noch den Faktor 8 (weil er nicht in jeden Durchlauf eine MMU Exception bekommt) während ARM immer noch bei 10-12 bleibt. Somit ergibt sich die Erkenntnis: Entwerfe und optimiere einen Benchmark so, dass das gewünschte Ergebnis dabei herauskommt!

Programmierung auch von Architektur abhängig

Es kommt maßgeblich auf die CPU-Architektur an, inwieweit sich „schlechtes Programmieren“ auf die Performance auswirken kann. Bei „guter Programmierung“ sind alle Prozessoren etwa gleich schnell (bei gleichen Speichertypen) und nur minimal abhängig von der CPU-Geschwindigkeit (666 / 800 / 1200 MHz im Beispiel). Was daran liegt, dass bei häufigem RAM Zugriff die Speichergeschwindigkeit entscheidend ist und die ist bei den meisten RAM Chips dann doch sehr ähnlich. Die CPU-Geschwindigkeit kommt erst dann zum Zug, wenn viel gerechnet wird und die Daten größtenteils im L1-Cache vorliegen. Der Intel i7 Prozessor sticht hier besonders heraus, weil der Speicher bei dem vorliegenden System mit 128Bit Dual Channel angebunden ist und damit in 2 Zyklen eine Cacheline füllt. Die anderen Systeme benötigen für diesen Vorgang typischerweise 8 Zyklen.

Nun stellt sich die Frage: Sollte das nicht der Compiler entsprechend optimieren können? Die Antwort darrauf ist ein klares Nein: Er kann und darf es eigentlich auch nicht. Sonst wird der logische Ablauf, den der Programmierer vorgegeben hat, nicht mehr eingehalten. In unserem Beispiel wäre es vielleicht möglich, aber selbst dort wird es nicht optimiert.

Im nächsten Teil des Beitrages wird nun näher auf die Bereiche Systemzuverlässigkeit hinsichtlich Speicherarchitektur eingegangen.

* Dipl.Ing. Kei Thomsen ist Entwickler, Support und Trainer für das Betriebssystem OS-9 bei MicroSys.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Artikelfiles und Artikellinks

(ID:44498621)