Linux: Wie gut skalieren 128 Threads in Benchmarks und Anwendungen?
Aktuelle AMD Epyc-Prozessoren warten mit bis zu 32 Kernen und 64 Threads auf. Im Dual-Socket-Systemen ergibt sich so eine Gesamtzahl von 64 Kernen und 128 Threads. In einem aktuellen Test wurde ein derartiges System durch den Benchmark-Parcours geschickt, um zu sehen, wie gut unterschiedliche Linux-Benchmarks und -Anwendungen skalieren.
Die Webseite phoronix.com hat in der vergangenen Woche einen Dual-Epyc-Server in Form des Dell Poweredge 7425 in die Finger bekommen und direkt im hauseigenen Linux-Benchmark-Labor einigen Tests unterzogen. Dabei nahmen die Tester unter die Lupe, wie gut unterschiedliche Linux-Anwendungen und -Benchmarks mit den insgesamt 128 Threads der zwei, im Dell Poweredge 7425 verbauten AMD Epyc 7601-CPUs zurechtkommen.
Ordentliche Skalierung bis 64 Threads mit wenigen Ausnahmen
Neben den beiden AMD Epyc 7601-Prozessoren sind im Dell Poweredge 7425 512 GiByte Arbeitsspeicher verbaut, die sich aus insgesamt 16 Modulen mit je 32 GiByte DDR4-Speicher zusammensetzen. Als Massenspeicher dienen 20 Samsung 860 Evo SSDs mit je 500 GB Speicherplatz. Im Zuge des Tests nutzte phoronix.com ein Array bestehend aus 18 Samsung 860 SSDs im RAID 10-Verbund. So sollten, wie es im Bericht heißt, mögliche I/O-Flaschenhälse in den Benchmarks vermieden werden. Als Betriebssystem diente Ubuntu 18.04 LTS inklusive Linux 4.19-rc6-Kernel. Als Randnotiz wird außerdem angemerkt, dass es sich bei den Benchmarks lediglich um erste Messungen handelt, die noch in der "Burn-In"-Phase des Servers vorgenommen wurden und daher lediglich als Indikatoren dienen und zudem den Zweck erfüllen, zu zeigen, wie gut die unterschiedlichen Workloads bei 128 Threads skalieren. Getestet wurde mit 2, 4, 8, 16, 32, 64 und 128 aktiven Threads.
Insgesamt bleibt festzuhalten, dass nahezu alle Benchmarks und getesteten Anwendungen mit bis zu 64 Threads gut klarkommen. Lediglich beim Sprung auf 128 Threads - also bei Aktivierung aller Kerne sowie SMT - halten sich die Steigerungen bei den Resultaten mit einigen Ausnahmen in Grenzen. Ein deutliches Vorbeiziehen ist nur selten zu beobachten, in drei Fällen schneiden 128 Threads sogar schlechter ab als 64.
Auch lesenswert: Linux-Gaming mit Proton im Test: Kleines Update für Steam, großer Schritt für Linux
Dabei handelt es sich zum einen um die Datenkompression via 7-Zip in Version 16.02. Während die Steigerung bei der Nutzung von 64 Threads gegenüber 32 Threads noch mehr als 100 Prozent beträgt, wird bei 128 Threads ein Minus von gut 2,5 Prozent verzeichnet. Ähnliches ist beim TTSIOD 3D Renderer in Version 2.3b der Fall. Rund 56 Prozent beträgt die Differenz zwischen 32 und 64 aktiven Threads. Bei 128 Threads geht es wiederum um 5 Prozent runter. Phoronix.com merkt jedoch an, dass es bei diesem Benchmark deutlich größere Variationen gab, als es sonst der Fall ist. Als dritter und letzter Benchmark mit schlechterer Performance bei 128 Threads zeigt sich Tensorflow mit einem Minus von rund 9,5 Prozent. Weniger gut sieht es mit der Skalierung auch beim Java-basierten DaCapo-Benchmark aus. Das Leistungsplus hält sich arg in Grenzen. Glänzen können die 128 Threads jedoch beispielsweise in Stockfish 9, asmFisch, PostgreSQL pgbench und BRL-CAD. Alle Benchmark-Resultate finden Sie auf der Webseite von phoronix.com.
![[PLUS] Gaming unter Linux - Treiber, Benchmarks und Tipps](/screenshots/1020x/2018/08/aufmacher_linux-pcgh1.png)
[PLUS] Gaming unter Linux - Treiber, Benchmarks und Tipps
mehr ...
Da musste ich auch teilweise übergangsweise auf inoffizielle Treiber zurückgreifen, als ich noch eine Windows-Installation hatte, weil die offiziellen nicht rechtzeitig mit Windows kompatibel waren.
Ich hatte schon Scanner, die auf neuen Windowsversionen (ich weiß nicht mehr ob ab Win 7 oder ab Win 8) nicht mehr liefen. Unter Linux war das kein Problem.
Selbst wenn man eine neuere Karte vor Polaris hat, kann es sein, dass man im Grub Optionen für den Systemstart hinterlegen muss, die das Laden des Radeon-Moduls verhindern, weil das teilweise noch als Standard benutzt wird, statt AMDGPU. Erst ab Polaris sollte wirklich bei allen Distributionen sofort der AMDGPU-Treiber geladen werden, und mit RadeonSI und RADV hat man auch entsprechende OpenGL- und Vulkan-Treiber
Probleme kann man immer haben, aber ich finde unter Windows sind sie die viel größere Pest. Dann soll man irgendwelche MS-Tools installieren, muss irgendwelche Ordner löschen, am besten noch in der Registry rumpfuschen und natürlich alle Nase lang die Kiste neustarten. Wer keine Angst vor Configdateien hat, nur weil da Text drinsteht und keine Häkchen und Knöpfchen angezeigt werden, und eine Suchmaschine bedienen kann, hat eigentlich ganz gute Chancen, dass ihm bei Linux zielgerichteter geholfen werden kann. Habe den letzten Freitagabend zur Hälfte damit verbracht, den Update-Service von meinem Windows 7 zu reanimieren. Marvelous.