Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Une étude compare différents langages pour le calcul intensif
Le résultat va-t-il vous faire changer de langage ?

Le , par Davidbrcz

21PARTAGES

6  1 
Une étude compare différents langages pour le calcul intensif
Le résultat va-t-il vous faire changer de langage ?


Une équipe universitaire a sorti une étude comparant différents langages pour le calcul intensif. L'étude se base sur un modèle économique mais peut être appliqué à d'autres domaines.

Ils ont comparé

  • C++11
  • Fortran 2008
  • Java
  • Julia
  • Python
  • MATLAB
  • Mathematica
  • R


Afin de na pas biaiser les résultats, ils n'ont en général pas cherché à tirer profit des particularités de chaque langage. L'étude ne commente pas la difficulté à porter l'algorithme dans un langage donné.

Les résultats principaux sont :

  • Le C++ et Fortran tiennent toujours les meilleures performances
  • L'avantage du C++ sur le Fortran n'est que de 5-7%
  • Julia avec son compilateur JIT donne un exécutable qui tourne en moyenne 2.7 fois plus lentement que le meilleur programme C++
  • L’implémentation Pypy donne un programme 44 fois plus lent que celui en C++. Quant a l’Interpréteur CPython, la facteur oscille entre 155 et 269
  • Utiliser Numba (un compilateur JIT Python) , demande de revoir un peu le code mais donne des performances très proches du C++ (1.6 plus lent en moyenne)
  • MATLAB est entre 9 et 11 fois plus lent que le C++. Mais combiné avec des fichiers Mex, la différence tombe entre 1.24 et 1.64
  • R est entre 500 et 700 fois plus lent que le C++. Compiler le code augmente par deux la performance
  • Mathematica donne de bonnes performances (4 fois lent que le C++) mais au prix d'un grand effort de ré-écriture de code pour tirer parti des optimisations du langage,


Les résultats détaillés sont ici et le code est accessible sur Github

Cette étude va-t-elle vous faire changer de langage pour vos applications lourdes en calcul ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 18/07/2014 à 14:20
Citation Envoyé par Davidbrcz Voir le message
Afin de na pas biaiser les résultats, ils n'ont en général pas cherché à tirer profit des particularités de chaque langage.
Bah c'est complètement débile

Quand on utilise un langage particulier pour une tâche donnée, c'est généralement parce qu'il y est particulièrement adapté. Je me fous pas mal de savoir si X est plus rapide que Y sans utiliser les particularités de Y ; si justement ces particularités permettent à Y d'être plus rapide pour la tâche que je dois effectuer, c'est Y que je choisirai, parce qu'il est plus adapté.

Un langage n'est pas "meilleur" ou "plus performant" qu'un autre dans l'absolu, il faut utiliser le plus approprié à chaque besoin et c'est tout...
15  0 
Avatar de Grabeuh
Membre confirmé https://www.developpez.com
Le 18/07/2014 à 13:56
Citation Envoyé par Shuty Voir le message
Et le java du coup... ?
Il mouline toujours...
16  7 
Avatar de NicoV
Membre régulier https://www.developpez.com
Le 18/07/2014 à 14:16
Citation Envoyé par Grabeuh Voir le message
Il mouline toujours...
la méthode de comparaison est assez mal faite :
  • Les calculs ne sont faits qu'une fois par exécution, alors que parmi les langages testés certains sont compilés à la volée (Java, langages de script, ...). N'exécuter le test qu'une fois fait que le temps de compilation est compté dans le temps de calcul...
  • Les options d'exécution ne sont pas étudiées (par exemple -server pour du Java est quand même la moindre des choses pour du calcul intensif).

Résultat: sur mon PC (pas une bête de course), avec ces simples points, le temps de calcul Java passe de 2.5s à 1.9s...

Avec ce genre de conditions d'analyse, les résultats ne veulent pas dire grand chose
6  0 
Avatar de nchal
Membre expérimenté https://www.developpez.com
Le 18/07/2014 à 15:04
Il y a un concours organisé pour savoir qui va arriver à pondre l'étude la plus débile ? Parce qu'en ce moment, on est bien servi.

Si on me dit, "on va comparer les performances en cherchant à optimiser le code le plus possible suivant le langage", je dis OUI, un grand OUI. On sait tous que le C++ est le plus rapide, mais on ne sait pas si le Java est 15x ou 2x plus lent, et ça peut-être intéressant comme info. Mais l'étude se présente comme un bête copier-coller entre les langages, alors qu'il aurait pu sortir quelques préco sur comment programmer ou configurer la JVM par exemple pour optimiser les perfs Java.
6  0 
Avatar de Sekigo
Membre régulier https://www.developpez.com
Le 19/07/2014 à 15:47
Citation Envoyé par Davidbrcz Voir le message
Cette étude va-t-elle vous faire changer de langage pour vos applications lourdes en calcul ?
Non, parce que je suis développeur :

In this paper, we take a first step at correcting this unfortunate situation. The target au-
dience for our results is younger economists (graduate students, junior faculty) or researchers
who have used the computer less often in the past for numerical analysis and who are searching
for guideposts in their first incursions into computation.
En gros, la cible est le jeune économiste tout droit sortis de l'école, ou le chercheur pas très doué avec la programmation. Rien de honteux, on ne peux pas masteriser dans tous les domaines. Et avec cette cible en tête, l'étude semble beaucoup moins absurde, on veut le langage avec les meilleurs perfs avec du code pas forcément idiomatique.
Mais sur developpez.com, la cible n'est pas le jeune économiste, c'est le développeur. Et donc, venir nous poser ce genre de questions avec ce genre d'études, je trouve ça grotesque.
4  0 
Avatar de spidetra
Membre confirmé https://www.developpez.com
Le 19/07/2014 à 15:50
Citation Envoyé par cueffic Voir le message
Dommage, il n'y a pas de test sur Linux.
en sachant que pratiquement tous les super calculateurs sont sur Linux
Dommage surtout qu'il n'y a pas de tests de calculs intensifs
Le test est basé sur un vecteur de 17.000 entrées. C'est à dire peanuts !
En ce moment traiter une matrice de 500.000 entrées, ça me prend juste quelques secondes en java sur une vieille rogne (un amd athlon) et sans aucune recherche d'optimisation.
4  0 
Avatar de forthx
Membre éclairé https://www.developpez.com
Le 20/07/2014 à 15:02
Il y a un bout de temps j'avais fait un petit comparatif perso basé sur une résolution de sodoku en brute force.Cela pour me faire une idée (pas pour lancer un troll web ^^) entre java/C++/asm x86 , je ne l'ai jamais publié je l'ai juste partager avec des connaissances qui m'en ont fait la demande, car je trouvais ce comparatif a peine suffisent pour se faire une idée. Quant je vois ce que l'on trouve actuellement sur la toile, finalement mon comparatif était presque scientifique

A mon humble avis si l'on veut comparer 2 langages on doit le faire sur un critère donné (vitesse d'exécution, empreinte mémoire, temps de développement, efficacité de déploiement, ...) et une équipe d'experts dans chacun des langages. Si l'on mélanges plusieurs critères les résultats sont tous sauf pertinent. On peu ajouter pleins d'autres critères, parfois même subjectifs, mais on se retrouve face a une réalité : le résultats dépend toujours en partie de l'équipe d'experts
4  0 
Avatar de Shuty
Membre éprouvé https://www.developpez.com
Le 18/07/2014 à 13:45
Citation Envoyé par Davidbrcz Voir le message

...
  • Le C++ et Fortran tiennent toujours les meilleures performances
  • L'avantage du C++ sur le Fortran n'est que de 5-7%
  • Julia avec son compilateur JIT donne un exécutable qui tourne en moyenne 2.7 fois plus lentement que le meilleur programme C++
  • L’implémentation Pypy donne un programme 44 fois plus lent que celui en C++. Quant a l’Interpréteur CPython, la facteur oscille entre 155 et 269
  • Utiliser Numba (un compilateur JIT Python) , demande de revoir un peu le code mais donne des performances très proches du C++ (1.6 plus lent en moyenne)
  • MATLAB est entre 9 et 11 fois plus lent que le C++. Mais combiné avec des fichiers Mex, la différence tombe entre 1.24 et 1.64
  • R est entre 500 et 700 fois plus lent que le C++. Compiler le code augmente par deux la performance
  • Mathematica donne de bonnes performances (4 fois lent que le C++) mais au prix d'un grand effort de ré-écriture de code pour tirer parti des optimisations du langage,


Et le java du coup... ?
3  1 
Avatar de Davidbrcz
Rédacteur https://www.developpez.com
Le 20/07/2014 à 21:51
Citation Envoyé par Sekigo Voir le message
Non, parce que je suis développeur :

En gros, la cible est le jeune économiste tout droit sortis de l'école, ou le chercheur pas très doué avec la programmation. Rien de honteux, on ne peux pas masteriser dans tous les domaines. Et avec cette cible en tête, l'étude semble beaucoup moins absurde, on veut le langage avec les meilleurs perfs avec du code pas forcément idiomatique.
Mais sur developpez.com, la cible n'est pas le jeune économiste, c'est le développeur. Et donc, venir nous poser ce genre de questions avec ce genre d'études, je trouve ça grotesque.
Je me permets juste réagir cette intervention.
Il est vrai que j'ai pas assez (re)contextualise la news, mea culpa.

Mais il ne faut pas oublier que dans beaucoup d'endroits (recherche entre autre), il y a aussi beaucoup de programmes qui sont pondus par chercheurs - non développeurs.Et que pour eux developpez.com est un peu un phare dans la nuit. Je pense donc que cette étude est pertinente sur ce site.
2  0 
Avatar de Adrass
Membre à l'essai https://www.developpez.com
Le 18/07/2014 à 14:02
Il faut allez voir les résultats complets....
java 2.69 fois plus lent 3 ème.
1  0