Concis certes, mais je ne me prononcerai pas pour la lisibilité du code Python. Les goût et les couleurs...
Pour les performances, rien ne vaut un petit test.
De base je constate effectivement que dans les conditions précisées sur le site le programme Python s'exécute plus vite que la version Java (par un ratio d'environ 4 avec 500 comme argument)! Sauf que j'estime que le démarrage d'une JVM est relativement long dans le cadre de ces benchmarks et que les optimisations du JIT ne sont pas non plus négligeables.
Donc pour tenter de minimiser l'effet de démarrage de la JVM j'ai mis une boucle for pour exécuter 10 fois la fonction main et j'ai fait de même pour la version Python:
J'ai lancé la JVM en mode client qui ici est plus rapide que le mode -server. Je sais pas pourquoi c'est le cas ici, mais de toute façons lancer une JVM en mode server pour un aussi petit programme est stupide vu qu'elle va se lancer nettement plus lentement.
Pour info la première exécution du main du programme Java s'effectue en environ 530 ms et tombe à environ 300 ms. L'optimisation du JIT n'est tout de même pas négligeable.
Un simple time -p me donne pour Python:
real 2.82
user 2.48
Et pour Java:
real 3.39
user 2.58
Tiens, bizarre la version Python reste certes plus rapide mais on est loin du facteur 3.
L'écart se ressert si on augmente le nombre d'itération et/ou la valeur de l'argument. Par exemple avec 200 itérations:
Python:
real 54.63 / 53.60 (version compilée)
user 49.45 / 48.66 (version compilée)
Java:
real 60.18
user 47.08
Si je ne m'abuse la version officielle de Python est codée en C et j'imagine que c'est également le cas de la partie chargée de traiter les grands nombres. L'aspect "interprétation" n'intervient que très peu dans ce programme, d'où la faible différence avec la version compilée.
Moi j'en conclu que si on laisse le temps à la JVM de se lancer (un petit bout de programme comme celui-là c'est vraiment la pire des situations pour une VM), on obtient des résultats assez différents.
Alors Python a une classe intégrée performante, mais au final pas franchement plus que celle de Java et manifestement elle n'est pas non plus optimisée avec de l'assembleur. Mais de toute façon je crois qu'un binding GMP pour Python existe...
[^] # Re: mon avis
Posté par ndesmoul . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 3.
Pour les performances, rien ne vaut un petit test.
De base je constate effectivement que dans les conditions précisées sur le site le programme Python s'exécute plus vite que la version Java (par un ratio d'environ 4 avec 500 comme argument)! Sauf que j'estime que le démarrage d'une JVM est relativement long dans le cadre de ces benchmarks et que les optimisations du JIT ne sont pas non plus négligeables.
Donc pour tenter de minimiser l'effet de démarrage de la JVM j'ai mis une boucle for pour exécuter 10 fois la fonction main et j'ai fait de même pour la version Python:
J'ai lancé la JVM en mode client qui ici est plus rapide que le mode -server. Je sais pas pourquoi c'est le cas ici, mais de toute façons lancer une JVM en mode server pour un aussi petit programme est stupide vu qu'elle va se lancer nettement plus lentement.
Pour info la première exécution du main du programme Java s'effectue en environ 530 ms et tombe à environ 300 ms. L'optimisation du JIT n'est tout de même pas négligeable.
Un simple time -p me donne pour Python:
real 2.82
user 2.48
Et pour Java:
real 3.39
user 2.58
Tiens, bizarre la version Python reste certes plus rapide mais on est loin du facteur 3.
L'écart se ressert si on augmente le nombre d'itération et/ou la valeur de l'argument. Par exemple avec 200 itérations:
Python:
real 54.63 / 53.60 (version compilée)
user 49.45 / 48.66 (version compilée)
Java:
real 60.18
user 47.08
Si je ne m'abuse la version officielle de Python est codée en C et j'imagine que c'est également le cas de la partie chargée de traiter les grands nombres. L'aspect "interprétation" n'intervient que très peu dans ce programme, d'où la faible différence avec la version compilée.
Moi j'en conclu que si on laisse le temps à la JVM de se lancer (un petit bout de programme comme celui-là c'est vraiment la pire des situations pour une VM), on obtient des résultats assez différents.
Alors Python a une classe intégrée performante, mais au final pas franchement plus que celle de Java et manifestement elle n'est pas non plus optimisée avec de l'assembleur. Mais de toute façon je crois qu'un binding GMP pour Python existe...