UNIXwork

Vor Jahren hatte ich ein Raspberry Pi 1B als Server für ein paar kleine Dienste im Einsatz. Ersetzt habe ich das Teil aber später durch einen Fujitsu Futro s920, ein Thin-Client mit einer AMD G-Serie Quad-Core CPU (GX-415 GA). Die AMD G-Serie ist für embedded Computer entwickelt und daher hat der Fujitsu Thinclient auch eine recht niedrige Leistungsaufnahme. Zumindestens im Idle ist diese nicht viel höher als beim Raspberry Pi, aber dafür mit deutlich mehr Rechenleistung.

Ein Raspberry Pi 4 bietet ebenfalls eine Quadcore-CPU mit ähnlichem Takt. Daher hatte ich die Idee, mal ein bisschen die Hardware zu benchmarken. Und aus Spaß vergleiche ich das noch mit einer Sun Ultra 45 Workstation, die zumindestens einen ähnlichen CPU-Takt hat. Diese hat zwei UltraSPARC IIIi CPUs, ich glaube aus dem Jahr 2003.

Test-Hardware

• Raspberry Pi 1 Model B: CPUs (ARMv6): 1 x 700 MHz
• Raspberry Pi 4 Model B: CPUs (ARMv8): 4 x 1500 MHz
• Sun Ultra 45: CPUs (spar4u): 2 x 1600 MHz
• Fujitsu S920: CPUs (amd64): 4 x 1500 MHz

Sowohl beim Raspberry Pi 1 als auch 4 kommt ein 32bit Raspbian zum Einsatz. Vielleicht nicht optimal für die Performance, auf grund des wenigen RAMs (2 GB) aber praktisch vielleicht die bessere Wahl für den Produktivbetrieb.

Benchmarks

Als Integer-Benchmark wird die Schach-Engine stockfish benutzt. Stockfish bietet sehr gute Optimierung für x86 und auch ARM, aber nicht für sparc. Daher habe ich das ganze ohne spezielle Architekturoptimierungen kompiliert, also nur mit normaler Compiler-Optimierung.

stockfish bench 128 <num-cpus>

Als Floatingpoint-Benchmark kommt c-ray zum Einsatz. Dies ist ein einfacher in C geschriebener Raytracer.

c-ray-mt -t <num-cpus> -s 1000x1000 -r 10 -i scene -o out.ppm

Ergebnisse Stockfish

Die Ausgabe von stockfish bench sieht so aus:

Total time (ms) : 14304
Nodes searched  : 5607358
Nodes/second    : 392013

Für den Vergleich nehm ich nur Nodes/second. Je größer hier der Wert ist, desto besser:

rpi1     u45-1cpu   u45-2cpu   rpi4-1cpu   rpi4-4cpu   s920-1cpu   s920-4cpu
----------------------------------------------------------------------------
26503    277715     559029     392013      1421621     403146      1595700
26655    277386     559604     393222      1402173     402682      1530797
26623    277002     549077     385544      1424797     403261      1580684
26303    277152     566223     391739      1458121     402191      1551561
26926    277317     548266     391411      1435041     403146      1503410

Mittelwert mit Standardabweichung:

rpi1           26.602   ±    203,68
u45-1cpu      277.314,4 ±    240,66
u45-2cpu      556.439,8 ±  6.832,99
rpi4-1cpu     390.785,8 ±  2.691,36
rpi4-4cpu   1.428.350,6 ± 18.298,75
s920-1cpu     402.885,2 ±    400,12
s920-4cpu   1.552.430,4 ±  3.293,49

Ergebnisse C-Ray

C-Ray liefert am Ende die Anzahl der Millisekunden, die das Rendern gedauert hat.

rpi1     u45-1cpu   u45-2cpu   rpi4-1cpu   rpi4-4cpu   s920-1cpu   s920-4cpu
----------------------------------------------------------------------------
88444    29585      16133      10015       3128        13699       4282
86406    29013      16112      10028       3118        13698       4189
87455    29014      16134      10032       3138        14068       4186
86456    29000      16106      10032       3119        14058       4189
86676    28998      16033      10004       3110        13701       4185

Mittelwert mit Standardabweichung:

rpi1        87.087,4 ± 775,59
u45-1cpu    29.122   ± 231,59
u45-2cpu    16.103,6 ±  37,01
rpi4-1cpu   10.022,2 ±  11,03
rpi4-4cpu    3.122,6 ±   9,58
s920-1cpu   13.844,8 ± 178,19
s920-4cpu    4.206,2 ±  37,93

Auswertung

Der Unterschied zwischen Raspberry Pi 1 und 4 ist gigantisch. Allein im Single-Core Benchmark ist ein rpi4 14 mal schneller als ein rpi1. Dafür bietet ein rpi4 aber statt einem Core gleich 4. Auch die FP-Geschwindigkeit ist deutlich höher. Aber das war auch nicht anders zu erwarten.

Spannender ist der Kampf zwischen rpi4 und Fujitsu s920. Diese sind in etwa auf Augenhöhe. Im Integer-Benchmark führt die AMD-CPU, im FP-Benchmark die ARM-CPU. Interessanterweise ist beim Stockfish-Benchmark die Standardabweichung beim s920 deutlich geringer als beim rpi4. Eine mögliche Ursache könnten die thermischen Probleme beim rpi4 sein, die zu einer Reduzierung des CPU-Takts führen könnten. Doch bei C-Ray ist es genau umgekehrt. Ich habe noch keine Erklärung dafür, wieso beim rpi4 hier die Werte so viel stabiler sind, als bei den anderen Testkandidaten.

Etwas schwach finde ich die Resultate bei der Ultra 45. Die Hardware ist natürlich schon etwas in die Jahre gekommen, aber da es sich hier nicht um kleine embedded CPUs handelt, hätte ich doch mehr erwartet. Eine Ursache könnte aber auch sein, dass ich auf der Ultra 45 ein recht altes OS (Solaris 10) betreibe und zum kompilieren hatte ich nur gcc 5.5 zur Verfügung. Auf dem rpi4 z.B. kam gcc 8.3 zum Einsatz.

Das war jetzt ein einfacher CPU-Benchmark. Interessant wäre ein IO-lastiger Benchmark. Die Ultra 45 wird nicht kampflos aufgeben. Gerade die Bus-Architektur ist beim rpi4 immer noch Schrott, daher könnte die Ultra 45 hier punkten. Fortsetzung folgt (irgendwann).

Die neue Armv8.5-A Architektur hat ein sehr interessantes neues Feature, nämlich Memory Tagging. Ein großer Teil heutiger Sicherheitslücken in Software ist auf Memory-Access-Fehler zurückzuführen, verursacht beispielsweise durch Bufferoverflows oder Use-after-free.

Memory Tagging soll dem entgegen wirken, indem Speicherbereichen und den dazugehörigen Pointern Tags zugeordnet werden. Nur wenn der Tag des Pointers dem des Speicherbereichs entspricht wird der Speicherzugriff gestattet.

Die Idee ist nicht neu, die SPARC M7 CPU hat das ähnliche Feature Silicon Secured Memory.

Jetzt gibt es natürlich auch Software-Profiling-Tools, die auch Speicherzugriffsfehler erkennen können, jedoch können die Programme damit schon mal 100 mal langsamer laufen. Mit Memory Tagging hingegen hat man praktisch keinen Performanceverlust und damit kann dies auch bei Software im Produktiveinsatz verwendet werden.

Insgesammt also ein sehr interessantes Feature, das hoffentlich auch von Intel und AMD eingeführt wird. Wer auch immer dies zuerst anbietet, könnte auf dem Servermarkt einen deutlichen Pluspunkt sammeln.

Hardware-RAID hat gegenüber ZFS so einige Nachteile. Keine Checksums, resilvern dauert lange, Inkompatiblitäten zu anderen RAID-Controllern, da ist man echt froh, wenn man das nicht hat. Ein Argument gegen ZFS ist allerdings der Ressourcen-Verbrauch, denn statt Hardware-RAID-Controllern muss jetzt Software den selben Job und noch mehr erledigen. Spüren tut man das allerdings nicht, denn die CPUs sind heutzutage so schnell, dass die das locker nebenbei erledigen.

Dieses prähistorische Dinosaurier-RAID ist vielleicht nicht so toll, doch wenn man nur die passenden Dinosaurier-CPUs dazu hat, dann hat das ganze doch ein paar Vorteile. Ich habe kürzlich auf einer Sun Ultra 25 Workstation ein raidz1 mit 3 Platten gebildet. Die Workstation stammt aus dem Jahr 2006, die darin verbaute UltraSPARC IIIi CPU gibt es allerdings seit 2003. Und damit merkt man leider schon, was ZFS so an Rechenleistung verbrennt.

Ein Ausschnitt der Ausgabe von prstat wärend mit dd auf den raidz1 pool geschrieben wurde:

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
   107 root        0K    0K run      0  -20   0:00:25  58% zpool-storage/136
   967 root     4624K 2152K run     53    0   0:00:08  12% dd/1

Und wenn parallel dazu noch auf den rpool, der nur aus einer Festplatte besteht, geschrieben wurde:

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
   107 root        0K    0K sleep   99  -20   0:01:55  41% zpool-storage/136
   980 root     4624K 2216K sleep   53    0   0:00:04  11% dd/1
	 5 root        0K    0K run      0  -20   0:00:23 6,1% zpool-rpool/136
   981 olaf     4624K 2320K run     39    0   0:00:01 4,1% dd/1

Es ist also doch kein Mythos, dass ZFS ein paar Ressourcen braucht. Und ein zpool scrub verursacht sogar über 90% CPU-Auslastung.