p
u
b
l
i
c
i
t
é

Le langage Go se mesure à C++, Java et Scala
Une nouvelle étude comparative des performances, menée par un ingénieur de Google

Le , par Idelways, Expert Confirmé Sénior
L'ingénieur de Google Robert Hundt vient de publier un rapport comparatif entre Java, Scala, C++ et Go, le langage de programmation maison de Google.
Ce rapport se base sur l'analyse de différents facteurs suite à l'implémentation compacte du même algorithme dans les quatre langages.

Sans surprise, le langage C++ est le plus économe en mémoire vive et celui qui offre la Runtime la plus rapide.
Le résultat de ce benchmark dévoile en revanche que c'est le langage qui nécessite le plus « d'effort d'optimisation », des manipulations parmi lesquelles certaines sont « à un niveau de sophistication hors de la portée du développeur moyen », affirme Robert Hundt.

La mise en oeuvre du code de l'implémentation Java de l'algorithme a été la plus facile d'après le rapport. L'analyse des performances du langage est en revanche la plus complexe, notamment autour des effets du ramasse-miette (Garbage Collector), très difficile à optimiser.

Le langage Scala, qui tourne sur la JVM, et compile tout comme Java en byte-code, partage la même complexité d'analyse et d'optimisation des performances, mais sa notation concise et les puissantes fonctionnalités du langage offrent la meilleure optimisation de la complexité du code.

Quant à Go, Robert Hundt estime qu'il offre des fonctionnalités de langage intéressantes qui rendent possible l'écriture d'expressions concises et standardisées.
Le rapport rappelle que les compilateurs pour ce langage « restent immatures, ce qui se traduit à la fois sur les performances et la taille de l'exécutable »

Sur ce dernier point, les résultats de l'implémentation sont à la traine pour Go qui produit un exécutable de 1.2 Mo contre 13 Ko pour Java et 41 Ko pour C++.
C++ et Go compilent en code-machine, contrairement à Java et Scala. À ce propos, Go compile nettement plus vite que ses trois rivaux.

Le langage Go a été conçu depuis sa création il y a un an et demi comme un langage de programmation concurrentielle tout en conservant les performances d'un langage de bas niveau comme C++ et étant proche en apparence des langages dynamiques type Python.

Cette étude comparative de Google s'est déroulée en deux phases afin d'offrir l’équivalence la plus objective qui soit.
La première phase n'a utilisé que les fonctionnalités idiomatiques des langages (classes, boucles, schéma d'allocation de la mémoire...), sans utiliser des outils spécifiques destinés à maximiser les performances.

Après la publication des résultats de cette phase, divers ingénieurs de Google se sont attelés à optimiser par tous les moyens disponibles l'implémentation de chaque langage.

La comparaison des résultats des deux phases est d'après l'étude « révélatrice de la difficulté typique d'optimisation dans les langages respectifs ».

Le rapport est consultable via ce lien (PDF, 330 Ko, 10 pages)

Et vous ?

Que pensez-vous des résultats de cette étude ?
Et du langage Go et ses perspectives d'avenir ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de kimelto kimelto - Invité régulier http://www.developpez.com
le 07/06/2011 à 0:09
Citation Envoyé par TropMDR  Voir le message
Le fait que le compilo lui même aille vite, c'est assez secondaire. Donc je ne vois vraiment pas l'intéret d'un code moisi juste pour que "ça aille vite".

De un le code est pas si moisi que ca. Il faut aussi savoir que plus le compilo fait des optimisations, plus de risque d'avoir une miscompilation est grand (gcc -O3 est deconseille). Le fait d'avoir une compilation rapide ameliore la productivite. Et la raison pour laquelle il est rapide est pas due au fait qu'il fait moins d'optimisations (en fait si, mais qu'en partie) mais au fait que si a.o a besoin de b.o (le package a utilise le package b par example) alors le code de b que a utilise est inclu dans a.o. Ca veut dire que le compilateur fait beaucoup moins de lectures, et a large echelle ca change tout.

Citation Envoyé par TropMDR  Voir le message
A part la verbosité, j'aimerai bien savoir de quoi ils parlent

Ils parlent surtout du fait que Java encourage heritage, et que donc le programmeur raisonne en pensant aux types.
Avatar de xelab xelab - Membre Expert http://www.developpez.com
le 07/06/2011 à 9:18
Citation Envoyé par kimelto  Voir le message
Ils parlent surtout du fait que Java encourage heritage, et que donc le programmeur raisonne en pensant aux types.

L'héritage c'est quand même un principe de la POO! Et puis la généricité permet aussi une certaine souplesse...
Avatar de gangsoleil gangsoleil - Modérateur http://www.developpez.com
le 07/06/2011 à 14:55
Que pensez-vous des résultats de cette étude ?

Ca ne semble pas tres revelateur... Un seul algorithme teste, meme s'il est large, ce n'est que peu representatif. Et puis au survol du rapport, on trouve un truc bizarre avec la question du python, qui est nomme mais non compare.

Et du langage Go et ses perspectives d'avenir ?

Des langages, il y en a beaucoup aujourd'hui. Et les seuls qui sont vraiment utilises (meme sur des marches de niche) sont ceux qui repondent a un besoin. Go repond-il a un besoin ? A priori non - je ne me base pas sur les explications fumeuses disant que c'est plus simple et mieux que les autres langages.
Sans un besoin ou un but, je ne vois pas comment Go pourrait servir a quelque chose.
Avatar de gorgonite gorgonite - Rédacteur/Modérateur http://www.developpez.com
le 07/06/2011 à 18:51
Citation Envoyé par kimelto  Voir le message
Ils parlent surtout du fait que Java encourage heritage, et que donc le programmeur raisonne en pensant aux types.

Citation Envoyé par xelab  Voir le message
L'héritage c'est quand même un principe de la POO! Et puis la généricité permet aussi une certaine souplesse...

+1 avec xelab... en quoi est-réellement du raisonnement, côté langage ? la plupart du temps ce travail est déjà fait en amont sur des outils UML-like... ça n'a rien de spécifique à Java. seul le côté verbeux pour compléter ce qui n'a pas été généré est ensuite lourd à écrire (et encore )

si tu veux raisonner en terme de types... regardes du côté des langages plus formels ayant des modélisations orientée-type et non orientée-objet
Avatar de kimelto kimelto - Invité régulier http://www.developpez.com
le 08/06/2011 à 0:28
Parce que Go ne gere pas l'heritage, tout simplement.
Le duck typing est beaucoup plus puissant que ce qu'on peut penser Surtout si on decouple bien les "roles" (e.g. writer, reader, ...) avec les interfaces.
Avatar de gangsoleil gangsoleil - Modérateur http://www.developpez.com
le 08/06/2011 à 10:15
Bonjour,

Citation Envoyé par Idelways  Voir le message
Sans surprise, le langage C++ est le plus économe en mémoire vive et celui qui offre la Runtime la plus rapide.
Le résultat de ce benchmark dévoile en revanche que c'est le langage qui nécessite le plus « d'effort d'optimisation », des manipulations parmi lesquelles certaines sont « à un niveau de sophistication hors de la portée du développeur moyen », affirme Robert Hundt.

En meme temps, c'est pour ca que c'est de l'optimisation : ce n'est pas une chose que fait le developpeur moyen, mais une chose que fait un specialiste du domaine.

Si le but de Go est de faire un langage moyen, permettant a n'importe quel developpeur moyen de faire un programme moyen, ils ont des chances de reussir.
Par contre, faire optimiser a outrance un developpeur moyen, c'est en faire un expert, et donc on en revient a ce qu'ils reprochent a C++.
Avatar de TropMDR TropMDR - Membre émérite http://www.developpez.com
le 08/06/2011 à 11:24
Citation Envoyé par kimelto  Voir le message
Parce que Go ne gere pas l'heritage, tout simplement.
Le duck typing est beaucoup plus puissant que ce qu'on peut penser Surtout si on decouple bien les "roles" (e.g. writer, reader, ...) avec les interfaces.

Si vous voulez du duck typing, de l'héritage, le tout dans un système statiquement et strictement typé, il y a toujours OCaml
Avatar de Tommy31 Tommy31 - Membre Expert http://www.developpez.com
le 08/06/2011 à 13:33
Citation Envoyé par TropMDR  Voir le message
Si vous voulez du duck typing, de l'héritage, le tout dans un système statiquement et strictement typé, il y a toujours OCaml

Comment "duck typing" et "statiquement et strictement typé" peuvent cohabiter ensemble ?

Je suis pas un pro d'ocaml, loin de là, mais je pensais que l'inférence de type rendait justement le duck typing impossible.

Tu as des exemples ? Ca m'intéresse.
Avatar de TropMDR TropMDR - Membre émérite http://www.developpez.com
le 08/06/2011 à 14:13
Citation Envoyé par Tommy31  Voir le message
Comment "duck typing" et "statiquement et strictement typé" peuvent cohabiter ensemble ?

Je suis pas un pro d'ocaml, loin de là, mais je pensais que l'inférence de type rendait justement le duck typing impossible.

Tu as des exemples ? Ca m'intéresse.

Alors, disons qu'un canard, c'est un objet qui sait faire coincoin. Donc je peux utiliser un canard

Code : Sélectionner tout
1
2
3
let utilise_canard c = 
  print_string "J'utilise un canard. "; 
  c#fait_coin_coin
Ensuite tu peux définir un vrai canard

Code : Sélectionner tout
1
2
3
4
5
class canard = 
  object 
    method fait_coin_coin = print_endline "Je suis un canard qui fait coin coin" 
    method envoler = print_endline "Je suis un canard et je m'envole" 
  end
Mais tu peux aussi par exemple avoir un vélo qui fait coincoin quand il klaxonne

Code : Sélectionner tout
1
2
3
4
5
class velo = 
  object 
    method fait_coin_coin = print_endline "Je suis un vélo qui fait coincoin quand il klaxonne" 
    method pedaler = print_endline "Je suis un vélo et je pédale" 
  end
Et là tu peux utiliser les deux avec utiliser_canard

Code : Sélectionner tout
1
2
3
4
5
6
7
let () = 
  let c = new canard in 
  let v = new velo in 
  utilise_canard c; 
  utilise_canard v; 
  v#pedaler; 
  c#envoler
Avec comme output
Code : Sélectionner tout
1
2
3
4
J'utilise un canard. Je suis un canard qui fait coin coin 
J'utilise un canard. Je suis un vélo qui fait coincoin quand il klaxonne 
Je suis un vélo et je pédale 
Je suis un canard et je m'envole
Donc voilà, duck typing !

Pourtant, tout ça est bien statiquement typé. La première fonction a comme type
Code : Sélectionner tout
val utilise_canard : < fait_coin_coin : 'a; .. > -> 'a = <fun>
ce qui signifie "je suis une fonction qui attend un objet qui a au minimum une méthode 'fait_coin_coin' qui retourne un certain type, et je retourne ce même type"

D'ailleurs, on peut ajouter une classe avec un type de retour différent
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class canard_compteur = 
  object 
    val mutable count = 0 
    method fait_coin_coin = 
      count <- count + 1; 
      Printf.printf "Je suis un canard qui a fait coin coin %i fois\n" count; 
      count 
    method envoler = print_endline "Je suis un canard et je m'envole" 
  end 
 
let () = 
  let cc = new canard_compteur in 
  ignore (cc#fait_coin_coin); 
  ignore (utilise_canard cc); 
  let i = utilise_canard cc in 
  Printf.printf "Le canard a fait coin coin %i fois\n" i
avec comme sortie
Code : Sélectionner tout
1
2
3
4
Je suis un canard qui a fait coin coin 1 fois 
J'utilise un canard. Je suis un canard qui a fait coin coin 2 fois 
J'utilise un canard. Je suis un canard qui a fait coin coin 3 fois 
Le canard a fait coin coin 3 fois
Voilà voilà
Avatar de meteors meteors - Invité de passage http://www.developpez.com
le 08/06/2011 à 15:28
Je suis assez d'accord avec thierrybenji

Google n'aurait jamais dû faire un moteur de recherche, après tout il y a altavista
Pourquoi citroen a inventé le chevron? les voitures existaient avant lui
et puis Pasteur nous emm** avec ses vaccins, les plantent ça fonctionne tout seul

Plus sérieusement, je ne dis pas qu'essayer c'est réussir, je dis que réussir c'est commencer par essayer.Nous verrons bien où ils nous embarquent avec ce langage.
Avatar de dolanor dolanor - Membre habitué http://www.developpez.com
le 07/02/2015 à 1:38
J'aime beaucoup déterrer des topics de prévision après que de l'eau a coulé sous les ponts !
C'est assez amusant de voir ce qui s'est passé depuis ! Et j'avoue que je partageais votre avis à l'époque aussi. Et pourtant maintenant je suis bien accroc de ce langage.

Quel est votre avis maintenant sur le sujet ?
Offres d'emploi IT
Ingénieur études et développement confirmé h/f
CDI
Société Générale - Ile de France - Paris (75000)
Consultant décisionnel informatica (h/f)
CDI
ELANZ - Ile de France - Paris (75000)
Ingénieur Conception Développement .Net (H/F)
CDI
SQLI Entreprise - Ile de France - Saint-Denis (93210)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Accueil : le Service Publications -