Certes les perfs d'OCAML n'ont pas à rougir face au C. Même si elles étaient moins bonnes le langage resterait intéressant de par ses qualités intrinsèques (même si je suis jamais arrivé à me faire aux langages fonctionnels...).
Attention cependant à ne pas prendre au pied de la lettre ces benchs notamment pour les perfs des langages utilisant une machine virtuelle (avec JIT et autres optimisations à la volée) comme Java et C#. On avait déjà parlé il y a quelques temps ici de cette page.
Certains des bench s'exécutent en quelques secondes, sans prendre en compte ni le temps de démarrage de la machine virtuelle ni les optimisations faites comme la recompilation native du code à la volée. Contrairement à ce qui est prétendu sur le site, si le programme s'exécute en 3s l'impact est important.
Je rajouterai que les compétences exprimées dans chaque langages ne sont pas forcément équivalentes. J'avais jetté un coup d'oeil sur un des programmes Java proposé et j'avais vu des choses qui ne me semblaient pas optimales (genre recopie d'un tableau case par case alors que souvent il vaut mieux faire un arraycopy). Il n'est pas impossible que la même chose puisse être observée avec les autres langages du panel.
Enfin j'ignore si c'est le cas ici mais avec un langage objet haut niveau on va avoir tendance à batir un model objet qui sera plus lisible et plus facilement (ré-)utilisable mais que les compilateurs ont encore du mal à bien optimiser; alors qu'en C ce sera disons plus 'crade', presque illisible mais plus optimisée. (Il y a peut-être une différence de philosophie)
Il n'est pas impossible que l'on obtienne de meilleures performances aux benchs, sur certains langages, en partant de la version C traduite au plus près vers le langage cible.
A contrario un langage de haut niveau rendra peut-être plus facile l'implémentation d'un algorithme optimisée, alors que sera un casse tête en C.
Tout ça pour dire que les benchs, mieux vaut ne pas y accorder une importance démesurée et programmer avec le langage que l'on préfère.
[^] # Re: Tout bon!
Posté par ndesmoul . En réponse à la dépêche OCaml summer project. Évalué à 3.
Attention cependant à ne pas prendre au pied de la lettre ces benchs notamment pour les perfs des langages utilisant une machine virtuelle (avec JIT et autres optimisations à la volée) comme Java et C#. On avait déjà parlé il y a quelques temps ici de cette page.
Certains des bench s'exécutent en quelques secondes, sans prendre en compte ni le temps de démarrage de la machine virtuelle ni les optimisations faites comme la recompilation native du code à la volée. Contrairement à ce qui est prétendu sur le site, si le programme s'exécute en 3s l'impact est important.
Je rajouterai que les compétences exprimées dans chaque langages ne sont pas forcément équivalentes. J'avais jetté un coup d'oeil sur un des programmes Java proposé et j'avais vu des choses qui ne me semblaient pas optimales (genre recopie d'un tableau case par case alors que souvent il vaut mieux faire un arraycopy). Il n'est pas impossible que la même chose puisse être observée avec les autres langages du panel.
Enfin j'ignore si c'est le cas ici mais avec un langage objet haut niveau on va avoir tendance à batir un model objet qui sera plus lisible et plus facilement (ré-)utilisable mais que les compilateurs ont encore du mal à bien optimiser; alors qu'en C ce sera disons plus 'crade', presque illisible mais plus optimisée. (Il y a peut-être une différence de philosophie)
Il n'est pas impossible que l'on obtienne de meilleures performances aux benchs, sur certains langages, en partant de la version C traduite au plus près vers le langage cible.
A contrario un langage de haut niveau rendra peut-être plus facile l'implémentation d'un algorithme optimisée, alors que sera un casse tête en C.
Tout ça pour dire que les benchs, mieux vaut ne pas y accorder une importance démesurée et programmer avec le langage que l'on préfère.
(C'était le dicton du jour...)