Java:BenchmarkLanguages/fr

From Alexandre Navarro's Wiki

Revision as of 20:36, 2 April 2008 by Anavarro (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Contents

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


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

Test Name Java (windows x86) C# (windows x86) C/C++ (VS windows x86)
Getter Setter 1.012.971
Invoke 13.62.53
Collection 12.467.6
Creation 11.39126.76
Arithmetic 11.531.03
Threading 11.490
Autoboxing 11.720
File 11.031.08
Timing 111.511.12
Recusive 13.522.63
StringConcat 11.071.44
Nested Loops 13.472.47
Matrix Multiply 1.751.71
HeapSort 11.141.1
Exception 120.1325.56
Reflection 140.230
Enum 138.950
Trigo 10.6111.29

Environnement 2

Image:Summary-benchmark-1-env2.png

Image:Summary-benchmark-2-env2.png

Test Name Java (windows x86) Java (linux x86) Java (linux x86_64) C# (windows x86) C/C++ (VS windows x86) C/C++ g++ (linux x86_64))
Getter Setter 1.021.021.081.891.221
Invoke 1.011.0612.382.161.27
Collection 11.011.32.115.631.95
Creation 11.022.041.2853.5539.6
Arithmetic 1.061.511.551.041.02
Threading 1.011.0411.4800
Autoboxing 1.171.181.76100
File 4.062.513.613.971.92
Timing 110.775.9815.141.177.86
Recusive 1.031.0311.731.81.17
StringConcat 1.251.231.0811.111.28
Nested Loops 2215.894.377.63
Matrix Multiply 2.742.741.82.471.581
HeapSort 1.111.121.121.121.011
Exception 11.161.049.9612.7416.89
Reflection 11.311.1321.0300
Enum 1.1211.1342.0200
Trigo 7.56.236.7511.371.4


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.

Others Links

Personal tools