Wenn der Artikel typisch ist für Computer Weekly, dann würde ich von der Publikation abraten.
Java ist eine interpretierte Sprache. Im Gegensatz dazu ist C++ – eine Sprache, mit der Java oft verglichen wird – statisch typisiert. Es ist die dynamische Natur der Java-Sprache, die den Benutzern oft Sorgen über mögliche Geschwindigkeitsprobleme bereitet.
Ob man Java eine interpretierte Sprache nennt ist strittig, das stellt der Artikel aber nicht falsch dar, denn es wird ja dann erklärt, dass ein Zwischencode (Javaslang: Bytecode) per Compiler erzeugt wird, der dann auf der JVM läuft und da es JVMs für verschiedene Betriebssysteme und Rechnerarchitekturen/CPUs gibt, kann jede ihre eigenen Optimierungen vornehmen, ohne dass beim Kompilieren eine Optimierungsentscheidung getroffen werden muss.
Was aber falsch ist, dass ist die Behauptung, dass die statische Typisierung von C++ ein Unterschied zu Java wäre und damit zu tun hätte. Die vage Formulierung "dynamische Natur der Javasprache" ist auch fishy; Java wird in der Regel nicht zu den dynamischen Programmiersprachen gezählt, weil sie eben statisch typisiert ist.
Statisch typisiert heißt, dass man für die Variablen (Objekte, Member, Parameter von Methoden, Rückgabewerte von Mehoden, ...) vorher festlegen muss (deklarieren), welchen Typs sie sind (int, boolean, String, Integer, JFrame, ResultSet, BufferedOutputStream, ...).
Das ist die große Gemeinsamkeit von C/C++/Java.
Wenn ein Java-Programm ausgeführt wird, untersucht es das zugrunde liegende System, und die JVM kann den von ihr erstellten Maschinencode auf der Grundlage der verfügbaren Funktionen optimieren.
Nein, das macht nicht das Javaprogramm. Sonst müsste ja jeder Programmierer, der Javaprogramme schreibt, davon wissen und wissen wie es geht. Das macht die JVM.
Was richtig ist, ist, dass Javaprogramme in Microbenchmarks oft Kopf an Kopf mit C oder C++-Programmen sind, dass aber immer ein Crack in der Sprache X mit der Optimierung Y ums Eck kommen kann, und die andere Sprache liegt wieder vorn.
Idiomatischer Javacode, der nach Möglichkeit Wort für Wort nach C++ übersetzt wird, das funktioniert oft, weil die Syntax der Sprachen so ähnlich ist und weil der Code so ähnlich aussieht, sieht es dann wie ein fairer Vergleich aus. Und Java ist dann wahrscheinlich schneller, aber idiomatischer C++-Code, den man wortweise nach Java übersetzt, ist dann wahrscheinlich schneller als der Javacode.
Mikrobenchmarks wie hier werden gerne und oft angestellt, aber haben nur eine begrenzte Aussagekraft. Für verschiedene Operationen haben verschiedene CPUs eingebaute Optimierungen oder auch nicht, ein Crack würde den Code oft anders schreiben, insbes. wenn es wichtig wäre das letzte aus einem Programm herauszukitzeln - evtl. würde ein C- oder C++-Programmierer sogar zu Assembler greifen.
Optimierende Compiler oder ein optimierendes JRE können auch den Code analysieren und reinen Rechenaufwand, dessen Ergebnis am Ende ignoriert wird, komplett wegoptimieren, so dass man aufpassen muss, wie man seinen Mikrobenchmark implementiert.
Eine sehr große Rolle spielt das Problem des Cachings, d.h. ob alle Werte und Zwischenwerte in den Cache passen (L1, L2, ...). So kann ein Programm A bei 100.000 Elementen vorne sein, Programm B bei 1.000.000 Elementen und bei 10.000.000 vielleicht wieder A.
Die JVM optimiert Code, abhängig davon, wie oft der läuft, d.h. wenn man einen Schwellwert übersteigt kann es plötzlich um eine Größenordnung schneller werden.
Wenn Du einen Server der im Netz hängt, und 10 Mio. User täglich mit einem Wordlerätsel beschäftigt optimierst, dann wirst Du wohl genau für den Rechner, die mittlere Userzahl, Anzahl Cores und Größe des RAMs optimieren (oder einen doppelt so schnellen Server kaufen - das ist oft billiger). Wenn Du Anwendercode schreibst wie eine Officesuite, die auf 1000 unterschiedlichen Systemen performant laufen soll sind die Optimierungsprobleme ganz andere.
Allgemein sind die interpretierten Sprachen, die nicht in Zwischencode compiliert werden, wie Ruby, Python, PHP usw. langsamer als compilierte Sprachen wie C/C++/Java, aber für viele gibt es Bindungs an die JVM, und man kann den Code auch in Bytecode für die JVM übersetzen lassen (keinerlei Erfahrungen aus der Praxis meinerseits) und wahrscheinlich für manche Sprachen auch Tools, um sie in C-Code u.ä. zu transformieren.
Für Java sieht es vergleichweise schlecht aus, wenn es um sehr kleine Scripts geht. Beim ersten Start muss erst die JVM in den Speicher geladen werden - da ist das C-Programm längst fertig. Beim zweiten Lauf hat das OS aber vielleicht noch im Speicher gelassen und startet deutlich schneller.
Benchmarking ist eine komplizierte Sache bei der viel zu beachten ist.
Als langjähriger Javaprogrammierer, der vorher aber C und C++ benutzt hat und nur deswegen bei Java gelandet ist, weil es sich ganz ordentlich geschlagen hat, sind meine Äußerungen auch nicht frei von Bias. Dass Java 8x oder 10x schneller sein soll - bei diesem speziellen Test aber nur - das klingt verdächtig. Meist hat man Unterschiede von 80%-120% oder nur von 95%-105% in der Laufzeit.
