Multifrac-Benchmark: Java vs. C

2009-08-13

Man sagt Java ja nach, dass es lahm ist. So rein subjektiv gesehen kommt mir das auch ziemlich oft so vor, trotzdem sind es wohl meistens eher nur die GUIs und/oder "verschwenderische" Programmierer. Sagt man ja so.

Jetzt, wo das Multifrac so schön aufgeteilt ist, wollte ich's dann mal selbst rausfinden. Vorallem ist ein Mandelbrot-Loop ziemlich einfach und man hat es eigentlich nur mit primitiven Datentypen zu tun, folglich umginge man mit einem "Java vs. C"-Benchmark hier die subjektiven Gefühle und auch erweiterte Konstrukte relativ gut.

Also: Eine Rendernode in C gehackt, die -- aufgrund der Syntaxnähe von Java und C -- sich auch nur in Details vom Java-Code unterscheidet. Zumindest, was den rechenintensiven Mandelbrot-Loop angeht. Dazu kommt noch ein bisschen Netzwerk-Code, dessen zeitlicher Einfluss später auch noch separat gemessen wurde. Den absoluten Hauptteil der Zeit verbringt eine solche Rendernode aber damit, das Fraktal zu berechnen, was dann also auch Dreh- und Angelpunkt dieses Benchmarks ist.

Setup

Benchmark-Szene
640x480
Immer nur ein Kern
Kein direkter Stream
Koordinator immer Desktop-Rechner

Ich lasse also auf meinem Desktop-Rechner den Koordinator laufen und trage als Remote Host den zu benchenden Rechner ein. Diesen beschränke ich aus einem bestimmten Grund auf einen Kern: Wenn sich der Prozess auf mehrere Prozessoren aufteilt, wird es am Ende des Bildes zwangsläufig dazu kommen, dass nur noch ein Kern rechnet, da für den anderen nichts mehr übrig ist. Um insgesamt den Overhead durch Netzwerkverkehr gering zu halten, habe ich den Koordinator so gebaut, dass er jeden "Bunch" etwa 5 Sekunden rechnen lässt. Wenn nun Java und C unterschiedlich schnell sind, dann gibt es am Ende eine unterschiedlich starke Nebenläufigkeit, was das Ergebnis verschwimmen lässt. Je nach Setup würden, wie man sehen wird, 5 Sekunden auch schon etwas ausmachen. Daher immer nur ein Kern.

Gebencht wurde jeweils einmal ohne Supersampling und einmal mit 2x2 Supersampling. Aus mehreren Läufen wurde das beste Ergebnis genommen, wobei die Zeiten bei Java durchaus um 2-5 Sekunden schwankten, bei C aber ziemlich konstant waren.

Die C-Binary wurde einmal auf dem Desktop-Rechner mit dem GCC 4.4.1 und "-O2 -march=i686" kompiliert und dann verteilt.

Die Hardware

Alter Testrechner:

Duron 1300
512MB SDRAM, 133MHz, CL2
Linux 2.6.27, Java 1.6.0u10

Videorekorder:

Athlon XP 2200+ (1800MHz)
384MB DDR RAM, 166MHz, CL3
Linux 2.6.26.2, Java 1.6.0u14

Alter Arbeitsrechner:

Athlon XP 2800+ (2079MHz)
1280MB DDR RAM, 166MHz, CL2
Linux 2.6.24, Java 1.6.0u7

Laptop:

Intel Core Duo T2300 (2x 1667MHz)
1GB DDR2 RAM, 200MHz (?), Timing unbekannt
Linux 2.6.30.4, Java 1.6.0u14

Desktop:

Athlon X2 4200+ (2x 2200MHz)
2GB DDR RAM, 200MHz, CL3
Linux 2.6.30.4, Java 1.6.0u14

Überall sind 100Mbit-NICs drin.

Die Ergebnisse

Grafik

Testrechner:

kein AA               2x2 AA
--------------        ---------------
Java   : 45.7s        Java   : 179.7s
C      : 19.4s        C      :  79.5s
==============        ===============
Speedup: 2.36x        Speedup:  2.26x

Videorekorder:

kein AA               2x2 AA
--------------        ---------------
Java   : 30.5s        Java   : 121.2s
C      : 13.6s        C      :  54.5s
==============        ===============
Speedup: 2.24x        Speedup:  2.22x

Alter Arbeitsrechner:

kein AA               2x2 AA
--------------        ---------------
Java   : 26.2s        Java   : 105.7s
C      : 11.9s        C      :  46.8s
==============        ===============
Speedup: 2.20x        Speedup:  2.26x

Laptop:

kein AA               2x2 AA
--------------        --------------
Java   : 18.1s        Java   : 72.0s
C      : 14.1s        C      : 56.2s
==============        ==============
Speedup: 1.28x        Speedup: 1.28x

Desktop:

kein AA               2x2 AA
--------------        --------------
Java   : 11.5s        Java   : 45.4s
C      : 10.9s        C      : 41.9s
==============        ==============
Speedup: 1.06x        Speedup: 1.08x

Bewertung

Das ist ein sehr unerwartetes Bild. Man sieht einen deutlichen Sprung bei den "kleinen" Maschinen, die nur einen Kern besitzen -- die DualCores dagegen werden bei weitem nicht so viel schneller, der Laptop zwar noch 25%, aber der Desktop fast gar nicht. Ich hatte gedacht, dass Java höchstens 5-10% langsamer ist, da es sich eigentlich um sehr einfachen Code handelt, zum Beispiel ist bei den Nodes keinerlei explizites Locking involviert. Mit einem solchen Unterschied abhängig von der Hardware hatte ich nicht gerechnet.

Was könnte hier los sein:

Es könnte eine absolute zeitliche untere Schranke geben -- unter 10 Sekunden könnte durch irgendwelchen Overhead gar nichts gehen. Dagegen sprechen zwei Dinge: Erstens ist es kein Problem, ein ganz einfaches Julia-Fraktal in 0.4 Sekunden im Netzwerk rendern zu lassen. Zweitens müsste dann der Speedup beim Desktop-Rechner im Supersampling-Benchmark größer sein. Alleine deshalb habe ich zusätzlich mit Supersampling gebencht und auch diese Ergebnisse hier reingestellt, denn eigentlich tut sich da außer einem Faktor 4 durch die höhere Auflösung ja nicht viel.
DualCore-Rechner könnten prinzipiell weniger Vorteile aus C ziehen, wenn nur ein Kern rechnet, weil Java weitere Nebenaktivitäten wie Garbage Collection hat, die sich dann auf dem freien Kern ausbreiten können. Allerdings war laut "htop" und dem Xfce-cpuload-Applet keine merkliche Aktivität auf den zweiten Kernen zu beobachten.
Der Netzwerk-Code könnte in C wesentlich effizienter sein, was sich auch darin äußern könnte, dass der Desktop-Rechner (hier liefen Koordinator und Node auf localhost) am wenigsten profitiert. Allerdings: Mit vertauschten Rollen (Koordinator auf dem Laptop, Node auf dem Desktop) sind die Ergebnisse nahezu identisch (etwa +0.2 Sekunden in beiden Sprachen). Hier hätte ich dann mindestens einen ähnlichen Speedup wie beim Laptop erwartet (~1.25).
Trotzdem könnte es immernoch sein, dass der Java-Netcode langsamer ist. Messungen zeigen, dass die Übertragungszeit mit Java pro "Bunch" im Bereich von 5-10 Millisekunden liegt -- sowohl auf dem Desktop-Rechner als auch zum Beispiel auf dem Videorekorder und dem alten Duron 1300. Im Rendervorgang mit 2x2 Supersampling finden etwa 30 solcher Übertragungen statt (Videorekorder), die zusammen etwa 0.2 Sekunden benötigen. In der Gesamtzeit von ca. 120 Sekunden geht das unter.
Damit dürfte auch die These vom Tisch sein, dass die Übertragung als solche einfach eine gewisse Zeit benötigt, was vorallem dem Desktop-Rechner eine harte untere Schranke setzen könnte. Die Übertragung geht de facto so schnell, dass sie nicht ins Gewicht fällt.
Java auf Linux älter als 2.6.30 könnte langsam sein. Um das zu klären, habe ich exemplarisch den alten Testrechner genommen (auch, weil hier die Diskrepanz am größten war) und dort den Benchmark mit der aktuellen Arch Linux LiveCD wiederholt, sodass dort auch Linux 2.6.30.4 und Java 1.6.0u14 liefen. Bis auf leichte Abweichungen im Nachkommabereich war das Ergebnis aber gleich.
Die Umkehrung bringt auch keine neuen Erkenntnisse ans Tageslicht: Xubuntu 8.10 (LiveCD) auf dem Desktop-Rechner als Node (also Linux 2.6.27 und Java 1.6.0u10) und der Laptop als Koordinator -- keine Änderung.

Ich hoffe, dass damit alle offensichtlichen Fehlerquellen beseitigt sind. Eine mögliche Idee wäre, dass Java auf einem Mehrkernrechner mehr Zeit in die Optimierung zur Laufzeit steckt, Stichwort JIT. Allerdings muss ich mich da erst noch etwas schlauer machen, denn auf diesem Gebiet thront gefährliches Halbwissen. :D Sachdienliche Hinweise nehme ich da sehr gerne entgegen.

Trotzdem ein kurzer Blick auf den Desktop-Rechner mit beiden Kernen (Laptop als Koordinator). Hier habe ich mit 4x4 Supersampling rendern lassen, um den Effekt der ungleichen Nebenläufigkeit am Ende zu dämpfen. Wie man sieht, würden nämlich auch 2-3 Sekunden Unterschied schon ins Gewicht fallen:

4x4 AA
--------------
Java   : 90.6s
C      : 85.7s
==============
Speedup: 1.06x

So ganz zu obiger These passt das leider nicht, denn das entspricht dem Faktor von einem einzelnen Kern.

Tja, woran liegt das? Ich lasse das jetzt einfach mal so offen stehen. ;) Interessant finde ich die Beobachtung auf jeden Fall und es ist wirklich nicht das, womit ich gerechnet hatte. Wenn ich die Gelegenheit dazu habe, werde ich mal versuchen, tiefer in das Thema einzusteigen.

Den Code für die C-Node wird es dann demnächst auch im Multifrac-Repo geben, wenn er noch etwas aufgeräumter und getesteter ist. :)

Comments?