Java:BenchmarkLanguages/fr

From Alexandre Navarro's Wiki

Current revision

Introduction

On entend souvent parler de performance concernant des 2 "nouveaux" langages à savoir le Java et le C#.

Difficile de se faire une idée en démelant les vrais arguments des ressentis subjectifs ou autres appréhensions. Nous proposons dans cet article de faire un certain nombre de tests, afin de se faire une opinion la plus objective possible.

Objectifs

L'objectif est de de mesurer les performances intrinsèques de C# (csharp) versus Java. Pour ce faire nous proposons une série de tests sur un ensemble de fonctionnalités que nous jugeons représentative d'un code C# ou Java. Un benchmark C/C++ a été rajouté pour avoir une comparaison (à titre indicatif) avec ces 2 languages pseudo-compilé. Aucune description du code C/C++ ne sera présent sur le wiki mais les sources sont disponibles. Le code C/C++ est optimisé mais n'est pas ultra optimisé comme pourrait l'écrire un expert pour de la performance extrême (ce qui est aussi le cas pour le java ou le C#).

L'idée n'est pas d'écrire un code hyper optimisé pour arriver à un résultat particulier, mais plutôt d'utiliser les mécanismes standards offerts par ces langages. Le code managé (unsafe) ou C/C++ wrappé est hors scope pour le C#. A contrario, si un langage propose plusieurs solutions pour arriver au même resultat, nous choisirons la plus performante.

• Ce que ne couvre pas cette étude:

• Les couches graphiques.
• Les outils autour des langages.
• Le wrapping du C++.

Environnement de Test

Le détail de l'environnement de compil/run se trouve ICI.

Procedure de test

La procédure de test se trouve ICI.

La liste des tests

• Getter et setter sur les objets
• Appel de methode
• Les containers (Array, List, Map, ...)
• Création d'objets (Pas de Pool d'objets, Pas d'Objet sur la stack)
• Calculs arithmétiques (+, -, /, *)
• Le Multithreading
• L'autoboxing (overhead)
• File manipulation (Read, Write)
• La gestion du temps
• La récursivité
• La gestion des Strings
• Nested Loops
• Calcul de matrice
• La gestion des exceptions
• Tri de tableau
• Reflection
• Enum
• Calculs trigonométriques (sin, cos, tan, exp, log, sqrt)

Les tests sont plus ou moins dans l'ordre de leur importance pour les performances. Attention, les commentaires ont été fait seulement à partir des résultats de l'environnement 1 dont les résultats diffèrent un petit peu de l'environnement 2.

Synthese des résulats

Sur les graphiques, moins le temps est important, mieux c'est.

Le meilleur temps de chaque test est mis abitrairement à 1 afin de montrer le rapport entre le meilleur temps et les autres.

Environnement 1

Image:Summary-benchmark.png

Environnement 2

Image:Summary-benchmark-1-env2.png

Image:Summary-benchmark-2-env2.png

Les tests indiqués à 0 en C/C++ n'ont été effectués.

• soit car cela n'a pas de sens (Autoboxing)
• soit car cela a un sens très différent (Enum)
• soit car cela est impossible à faire dans le langage (Reflection)
• soit car le test est complexe à faire (différents suivant les

environnements, différentes implémentations possibles notamment pour les thread : pthread, thread windows, boost) et par manque de temps (Threading)

Source et Résultats

[file:http://javageek.free.fr/downloads/benchmark-languages.rar

Source + Résultats] [last update 2008-01-16]

Arborescence des répertoires

• benchmark-languages
  • benchmark-cpp : projet C/C++ avec un fichier README.txt pour savoir comment compiler et runner les tests
    • src/main/cpp : source C/C++
  • benchmark-csharp : projet C# avec un fichier README.txt pour savoir comment compiler et runner les tests
    • src/main/csharp: source C#
  • benchmark-java : projet java avec un fichier README.txt pour savoir comment compiler et runner les tests
    • src/main/java: source java
  • results : résultats
    • env1 : résultats pour environnement 1
    • env2 : résultats pour environnement 2

Auteur du benchmark

Alexandre Navarro (navarroa@free.fr)

Conclusion

Comparaision des languages pseudo-compilés Java-C#

En dehors de la concaténation des chaines de caratère avec des + et les opérations trigonométriques, le java est toujours au moins aussi rapide que C# et dans de nombreux cas plus rapide voire beaucoup plus rapide.

Le java se distingue particulièrement dans tout ce qui est Création, getter, setter d'object, Invocation de méthode (surtout par interface), gestion des Collections (Array, List, Map), Timing, Exception et Reflection.

Comparaison du meilleur language pseudo-compilé (Java) avec le C/C++

Attention, les 2 languages ont certains concepts très différents ce qui rend certains benchmarks très avantageux pour l'un des 2 langages.

Voici 2 exemples :

Le new en java/c# (allocation de la mémoire sur le Heap déjà préalloué) est conceptuellement totalement différent du new en C++ (demande à l'OS d'allocation de la mémoire physique) et est très avantageux pour le java/C# en terme de performance (mais très désavantageux terme d'occupation mémoire).

La String en java/c# étant immutable comparé au C++ où la String est mutable, la concaténation de String avec des + n'a pas du tout le même sens en java/C# qu'en C++ et est très avantageux pour le C++.

Le C/C++ est plus rapide dans le cas de manipulation très bas niveau de registres (multiplication de matrices par exemple) et permet d'avoir une optimisation à la compilation plus importante (beaucoup de tests modifiés pour qu'ils aient du sens en C/C++) notamment pour dérouler des boucles (Nested Loops avant modification pour le tromper l'optimiseur gcc) par exemple. Même si ce n'est pas l'objet du test, C/C++ prend moins de mémoire que du Java/C#. Ces différentes raisons peuvent expliquer pourquoi il est intéressant de faire de C (pas du C++) pour faire certains choses comme un kernel d'OS (linux par exemple).

Le java permet de faire des optimisations à la compilation (un peu moins globalement que le C/C++) mais aussi à l'éxecution ce qui n'est pas possible en C/C++ (voir [http://en.wikipedia.org/wiki/Escape_analysis l'article sur l'Escape Analysis de java]). Les tests Getter Setter ont été modifiés pour qu'ils ne soient pas optimisés. Le java est très bon pour tout ce qui création d'objet sur le Heap (pouvant être + ou - contourné en C/C++ par de l'allocation sur la stack ou des pools d'objet) et l'invocation de méthode (notamment par interface / méthodes virtuelles en C/C++ et non statiques). On voit que les tests où le java est meilleur sont des tests où l'on fait de la programmation objet.

Le benchmark compare du Java, C# et du C++ pas beaucoup de C. Le C et le C++ sont différents et non pas les mêmes performance (en désavantage au C++).

Globalement on peut se rendre compte que les résultats sont souvent proches en dehors de cas particuliers comme la création des objets sur le Heap, la manipultation de Collection (stdlib pas très optimisé notamment sous Visual Studio et lié au temps mis pour mettre des objets sur le heap) et les Exception (pas très important en C/C++).

Précision importante

Je précise fortement que CECI N'EST QU'UN BENCHMARK et il faut le prendre comme tel. Il se veut le plus réaliste possible et le plus objectif possible. Les rapports de performance ne seront pas les mêmes sur une vraie application de production.

D'autres en parle

PS: Merci de n'indiquer que des comparatifs récents.

• Java1.6 vs C#Mono vs Gcc
• C++ vs Java6
• comparatif multi language
• Quand Java est plus rapide que le C dans une vraie application (Quake2)
• Encore plus de perf sous windows avec la version 1.7 et un usage intensif de DirectX
• Benchmark java, C/C++, java (attention les JVM et CLR sont très anciennes(jdk-1.4 C#-1.0)
• Comparaison C/C++ et java

Others Links

• Wikipedia Java Performance (Très bon article comme point d'entrèe)
• Article très intéressant sur l'Escape Analysis de java
• C# performance
• Comparaison Java / C# (features)
• Article sur le C++/CLI avec ses désavantages et ses avantages
• Article explicant que l'interop entre la CLR et C++ natif/DLL utilise exactement le même méchanisme pour PInvoke et pour ManagedC+
• Article indiquant que depuis la .Net 2.0, les CLR n'évolue plus notamment en .Net 3.0 ou dans le futur .Net 3.5
• Sun Performance whitepaper (1.6)
• C# Improving Managed Code Performance