Durch einen Post auf Mastodon, dessen Link ich leider nicht gespeichert habe bin ich auf die Funktion TAK aufmerksam geworden, mit der - so die Auskunft des Internet - Benchmarks von auf Rekursion optimierten Programmiersprachen durchgeführt werden können.

Zunächst erst einmal: ich weiß, dass Java inzwischen in einer viel neueren Version vorliegt.

Ich habe die Funktion implementiert und da für die drei Parameter (x,y,z) = (18,12,6) die Tiefe der Rekursion (63609) bekannt ist, konnte ich auf einfache Art und Weise die Korrektheit der Implementation testen.

Erste Messungen schwankten um 400 Microsekunden. Da ich aber weiß, dass Java einen JIT-Compiler einsetzt, habe ich zunächst erst einmal die Anzahl der Aufrufe erhöht und mir den ersten und den letzten Messwert angesehen - der Verdacht bestätigte sich: Der letzte Messwert nach 100000 Durchläufen war mit 100 Mikrosekunden deutlich geringer.

Um mir sicher sein zu können, dass dies wirklich eine Auswirkung der JIT Kompilierung war, stellte ich die gemessene Zeit für die Ausführung der 100000 Aufrufe mittels Gnuplot visualisiert.

Der JIT-Compiler ist durch verschiedene Kommandozeilenparameter steuerbar - die Visualisierung habe ich für verschiedene Kombinationen der Parameter durchgeführt (wobei nur die ersten 1500 Messungen wirklichj gezeigt werden, da der JIT-Compiler sich meist recht früh einschwingt), um die Auswirkungen zu demonstrieren - die genaue Version der verwendeten Java Laufzeitumgebung war übrigens

openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)

Gnuplot Visualisierung von 6 verschieden parametrierten Bechmarks der Funktion TAK mit Java Version 17

Im mit default bezeichneten Subplot sieht man den zeitlichen Verlauf der für jeweils einen Durchlauf benötigten Laufzeitbedarf. Beim Vergleich mit dem mit mixed gelabelten Subplot sieht man, dass dieser Modus, der durch die Option -Xmixed erzwungen werden kann auch die Voreinstellung ist.

Der Verlauf der Kurve zeigt, dass die Laufzeit zunächst relativ hoch ist - in der ersten Phase analysiert Java den Zeitbedarf und die Häufigkeit der Aufrufe von Methoden um die auszuwählen, bei denen sich eine Konvertierung in nativen Code lohnt. Nach ungefähr 200 Durchläufen wird der Laufzeitbedarf auf einen Wert unter 100 Mikrosekunden gedrückt - hier kommt dann der native Code zur Anwendung.

Der Einfluss des Parameters -Xcomp ist in dem Subplot namens comp zu erkennen: Hier werden alle Methoden sofort zu Beginn in nativen Code übersetzt und anschließend nur noch dieser benutzt. Das erklärt den fast völlig waagerechten Verlauf der Kurve. Dabei ist zu bemerken, dass sich der Startup der Anwendung durch die benötigte Umwandlung des gesamten Bytecodes in nativen Code enorm auf die Startupgeschwindigkeit einer Anwendung auswirkt!

Die drei restlichen Sublopts zeigen die Ergebnisse des Spielens mit dem Parameter -XX:CompileThreshold, der allerdings nur wirksam wird, wenn gleichzeitig -XX:-TieredCompilation gesetzt ist: Der Wert bestimmt, nach wie vielen Aufrufen die JIT-Optimierung beginnt. Wenn man die drei Subplots mit den Namen 1000, _10000 und 100000 vergleicht stellt man auch fest, dass der kleinste Wert einen Verlauf ergibt, der dem des Plot der Voreinstellung sehr ähnlich ist, während beim mittleren Wert die Optimierung deutlich später beginnt und beim Größten die Optimierung (bei der für die Visualisierung gewählten Fenstergröße) noch gar nicht begonnen hat.