Misleading Microbenchmarks on the Java Virtual Machines
Dieser Artikel zeigt, dass selbst bei Befolgung der Java Microbenchmark Harness (JMH)-Richtlinien Mikrobenchmarks auf der JVM irreführende Leistungsergebnisse liefern können, indem sie unrealistische Ausführungsprofile hervorrufen, die aggressive, nicht repräsentative Optimierungen auslösen, und er schlägt erweiterte Richtlinien vor, um diese Probleme zu mildern.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind ein Koch, der entscheiden muss, welches von zwei neuen Messern schärfer ist. Sie richten einen Test ein, bei dem Sie exakt dasselbe Stück Papier 1.000 Mal hintereinander schneiden, ohne dass sich jemand sonst in der Küche aufhält, ohne andere Aufgaben und mit Papier, das immer die gleiche Dicke hat.
Basierend auf diesem Test scheint Messer A unglaublich schnell zu sein. Aber in der realen Welt, in der Sie gleichzeitig Zwiebeln hacken, Tomaten schneiden und durch zähes Steak schneiden, könnte Messer A tatsächlich langsamer sein als Messer B.
Genau das passiert Softwareentwicklern beim Testen ihres Codes, so argumentiert die Arbeit mit dem Titel „Misleading Microbenchmarks on the Java Virtual Machines".
Das Problem: Die „sterile" Testküche
Entwickler verwenden häufig ein Werkzeug namens JMH (Java Microbenchmark Harness), um kleine Codeabschnitte zu testen. Sie wollen wissen: „Ist meine neue Art, Mathematik zu betreiben, schneller als die alte?"
Die Arbeit bezeichnet die Umgebung, in der diese Tests laufen, als „sterile Umgebung". Es ist wie ein Labor, in dem:
- Nur eine Aufgabe stattfindet: Der Code wird isoliert getestet, ohne dass andere Programme laufen.
- Die Eingabe sich nie ändert: Dem Code werden exakt dieselben Daten immer und immer wieder zugeführt.
- Der Computer „faul" wird: Die Java Virtual Machine (JVM) – der Motor, der Java-Code ausführt – ist intelligent. Sie beobachtet, was Sie tun, und versucht zu erraten, was Sie als Nächstes tun werden, um Dinge zu beschleunigen. Dies wird als spekulative Optimierung bezeichnet.
Die Falle: Der „über-spezialisierte" Koch
Hier liegt der Haken: Weil der Test so „steril" ist (wiederholend und isoliert), gerät der Motor der JVM in Verwirrung. Er sieht, dass der Code jedes Mal exakt dasselbe tut, und denkt: „Aha! Dieser Code wird immer ein 5-Zoll-Stück Papier erhalten. Ich werde eine spezielle Maschine bauen, die nur 5-Zoll-Stücke perfekt schneidet."
Der Motor baut eine hochspezialisierte, superschnelle Version des Codes für genau diesen einen spezifischen Szenario.
Das Ergebnis: Der Test sagt: „Wow, dieser Code ist 40 % schneller!"
Die Realität: In einer echten Anwendung erhält der Code alle möglichen Papiergrößen. Die spezialisierte Maschine bricht zusammen, und der Code läuft tatsächlich langsamer als die ursprüngliche, flexiblere Version.
Die Arbeit zeigt drei konkrete Beispiele, bei denen dieser Trick wirkt:
1. Der „Ein-Größe-für-Alle"-Hash-Code
- Der Test: Ein Entwickler erstellt eine neue Methode, um einen „Fingerabdruck" für eine Liste von Zahlen zu berechnen. Im Test erhält er nur Listen mit genau 10 Zahlen.
- Die Illusion: Der neue Code sieht fantastisch aus, weil der Motor ihn speziell für Listen mit 10 Elementen optimiert hat.
- Die Realität: Wenn der Code in einer echten App mit Listen von 3, 50 oder 100 Zahlen verwendet wird, ist der „spezialisierte" Code ungeschickt und langsam. Der alte, langweilige Code war eigentlich von Anfang an besser.
2. Die Stream-API (Das Fließband)
- Der Test: Entwickler testen eine moderne Methode zur Datenverarbeitung (genannt Streams), indem sie nur eine spezifische Abfrage isoliert ausführen.
- Die Illusion: Der Motor sieht diese eine Abfrage und optimiert das Fließband perfekt dafür.
- Die Realität: Echte Anwendungen führen Tausende verschiedener Abfragen aus. Die „perfekte" Fließband-Optimierung des Motors kann mit der Vielfalt nicht umgehen, und die Leistung sinkt. Die Arbeit fand heraus, dass Code, der im Test 41 % schneller aussah, im echten Leben tatsächlich langsamer war.
3. Der „ungerechte" Vergleich von Sammlungen
- Der Test: Ein Entwickler möchte beweisen, dass sein neues „List"- oder „Map"-Werkzeug (Daten-speichernde Tools) schneller ist als die in Java integrierten Standardwerkzeuge.
- Die Illusion: Er führt den Test durch, und sein neues Werkzeug gewinnt.
- Die Realität: Die Standard-Java-Werkzeuge waren bereits „aufgewärmt" und wurden optimiert, bevor der Test überhaupt begann, weil das Java-System sie zur Einrichtung selbst nutzt. Das neue Werkzeug erhält einen „frischen Start" im sterilen Test, während das alte Werkzeug durch seine Vorgeschichte belastet wird. Es ist wie ein Rennen, bei dem ein Läufer am Startstrich beginnt und der andere Läufer gezwungen wird, zuerst eine Runde um die Bahn zu laufen, aber die Stoppuhr erst startet, wenn beide die Ziellinie überqueren. Die Arbeit zeigt, dass, wenn man dieses Unrecht korrigiert, das „neue" Werkzeug oft nicht tatsächlich schneller ist.
Die Lösung: Den Test „verunreinigen"
Die Arbeit schlägt eine einfache Lösung vor: Lassen Sie den Test nicht zu sauber sein.
Bevor Sie die Geschwindigkeit messen, sollten Sie die Umgebung „verunreinigen". Das bedeutet, den Code mit vielen verschiedenen Eingaben und Szenarien auszuführen, bevor Sie den Timer starten.
- Analogie: Bevor Sie Ihr Messer stopfen, hacken Sie eine Karotte, eine Kartoffel, eine Tomate und ein Stück zähes Fleisch. Lassen Sie den Motor die Vielfalt sehen.
- Ergebnis: Der Motor hört auf, eine Maschine nur für eine Sache zu bauen. Er baut eine vielseitige Maschine, die alles gut handhabt. Jetzt spiegeln die Testergebnisse tatsächlich wider, was in der realen Welt passieren wird.
Das Fazit
Wenn Sie Ihren Code in einer perfekten, isolierten Blase testen, in der sich nichts jemals ändert, erhalten Sie möglicherweise ein Ergebnis, das großartig aussieht, aber eine Lüge ist. Um die Wahrheit zu erhalten, müssen Sie Ihren Code in einer chaotischen, realistischen Umgebung testen, in der sich Dinge ändern, genau wie im echten Leben.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.