Entwickler verneint 4000 Prozent schnelleren Linux-Kernel
Von CPU und Software hängt ab, ob eine derzeit viel diskutierte Änderung an Linux irgendwas schneller macht. Womöglich reduziert sie die Leistung auch.
Der Entwickler einer Änderung, die den Linux-Kernel laut zahlreichen News-Meldungen und Internet-Videos 3888,9 Prozent schneller machen soll, hat genug vom Hype und klargestellt: Einen großen Performance-Vorteil gibt es in der Praxis nicht, denn dieser gigantische Zuwachs entsteht nur durch eine vernachlässigbare und praxisferne Eigenart der verwendeten Messmethode. Zugleich wies Vlastimil Babka darauf hin, dass etwas anderes kaum Beachtung fand: Der den Zuwachs erwähnende Testbericht nennt zugleich eine Verlangsamung von knapp 9 Prozent in einem zweiten Benchmark.
Die ganze Geschichte ist noch komplizierter, denn die gehypte und für Linux 6.12 vorgenommene Änderung bringt auf manchen Systemen durchaus einen Geschwindigkeitsgewinn. Memory-Management-Entwickler und SLUB-Maintainer Vlastimil Babka hat diese – letztlich nur eine Zeile umfassende – Anpassung eingebracht, nachdem ein Nutzer beklagte, der Darktable-Benchmark erreiche seit einigen Monaten 15 bis 25 Prozent schlechtere Werte bei der RAW-in-JPG-Umwandlung.
Genau wie bei einem zweiten, ähnlich gelagerten Bug Report über Geschwindigkeitseinbußen von bis zu 600 Prozent zeigte sich das Problem bei allerlei Prozessoren von AMD, aber nicht bei solchen von Intel.
Knackpunkt Speicherseiten-Größe und -Ausrichtung
Als Schuldiger wurde schnell eine bei Linux 6.7 integrierte Änderung erspäht; dieser war damals eine 95,3 prozentige Performance-Einbuße mit dem verwendeten Benchmark attestiert worden, die Entwickler aber als irrelevant einstuften. Durch diese Anpassung lässt der Kernel angefragten Arbeitsspeicherbereiche unter bestimmten Bedingungen an Stellen beginnen, die es modernen Prozessoren ermöglicht, automatisch große Speicherseiten (Transparent Huge Pages/THP) zu nutzen. Wie Babka feststellte, müssen CPUs dadurch aber in manchen Fällen rund 2 Megabyte zusätzlichen Speicher allozieren und somit dabei auch bereinigen – was manchen Prozessoren aufgrund von Implementierungsdetails oder verschiedenen Optimierungsstrategien signifikant mehr Arbeit macht als anderen, was zu den Einbußen führt.
Durch die für 6.12 vorgenommene Änderung verzichtet der Kernel jetzt in einem weiteren Fall auf eine solche Ausrichtung. An Details interessierte finden diese in der Mail von Babkas, in der er den Performance-Gewinn als unbedeutend einstuft. Dort erklärt er auch, wieso der Benchmark erst über 95 Prozent nachgelassen hat und jetzt knapp 4000 zulegt: Er erstellt wiederholt 128 MByte große Puffer, nutzt diese aber praxisfern nie, sondern greift nur einmalig auf den Header zu; dadurch schlug der Overhead der bei 6.7 vorgenommene Änderungen massiv durch, was die für 6.12 vorgenommene Änderung korrigiert.
Die Änderung wurde zwischenzeitlich schon in das am 8. November veröffentlichte Linux 6.11.7 integriert – und erreicht so über Updates schon seit einigen Tagen Nutzer von Distributionen wie Arch Linux, Fedora Linux, oder openSUSE Tumbleweed. Einen Geschwindigkeitsgewinn dürften nur Anwender bemerken, die eine der problematischen Prozessoren besitzen und zugleich eine Software wie Darktable nutzen, bei der die bei 6.7 eingeführte Speicherausrichtung zu einem signifikanten Performanceverlust führte.
Womöglich führt die Änderung bei einigen Nutzern auch zu Einbußen, wie das zweite Messergebnis der gehypten Performance-Analyse zeigt, die in einem anderen Benchmark einen Verlust oft 9,2 Prozent attestiert. Nachgegangen ist dem aber wohl noch niemand. Das ist aber auch nicht weiter erstaunlich, denn diese Messungen finden alle naselang derartige Zugewinne oder Verluste.
Vielfach sind solche Schwankungen bei den Resultaten eher theoretischer Natur und haben in der Praxis keinerlei oder vernachlässigbare Bedeutung. Entwickler schenken diesen daher manchmal keine Bedeutung. Sie spotten zudem in ihren Kreisen häufiger mal über zumeist werbefinanzierte Anbieter, die regelmäßig Meldungen oder Videos zu vermeintlich großen Zugewinnen mit eigenen oder von anderen durchgeführten Benchmarks produzieren, zugleich aber viel bedeutsame Änderungen unter den Tisch fallen lassen. In diesem Fall sah sich Babka aber offenbar genötigt, die Zugewinne ins rechte Licht zu rücken.
(dmk)