Ce genre de benchmark mesure surtout la connaissance de celui qui l'a écrit dans les différents langages concernés
[...]
Laissez le calcul haute performance aux spécialistes et pas au économistes :-)
J'ai envie de dire que ce genre de benchmark mesure surtout ma méconnaissance des langages.
Déjà un problème conceptuel. Dans l'article ils décrivent leur problème, mais ils ne décrivent pas leur algo. Qui semble aller de soi quand on lit l'article, mais quand on regarde dans le détail il y a plein de petits trucs qui peuvent tout changer. Il aurait été un minimum de mettre dans l'article ou dans une annexe l'algo de manière dissociée du language.
Un autre problème conceptuel est sur le choix de l'algo utilisé dans la comparaison. C'est un algo qui est vectorisable, où beaucoup d'étape (peut-être toutes) peuvent êtres écrites sous forme de calcul matriciel. Ça implique pas mal de chose, quand à l'utilisation des libs adaptées et quand à la capacité des differents compilateurs de de faire des opérations utiles comme changer l'ordre des boucles.
Le point du calcul matriciel m'amène à voir que dans certains programmes (MATLAB par exemple) certaines étapes vectorisables sont vectorisés, mais pas d'autres (pourquoi ?) et dans d'autres (en C++ par exemple) ces mêmes étapes ne sont pas vectorisées (pourquoi ? ils ne connaissent pas les libs comme armadillo ?). Dans un benchmark, le minimum est de mettre toutes les possiblilités dans des conditions équivalentes. Soit on utilise les subtilitées et les capacités de chaque language pour optimiser au mieux le code, et dans ce cas on compare les langages dans un cas très particulier, les conclusions sont attachées à ce cas particulier. Soit on utilise rigoureusement le même algo (et ne vectorise pas dans un code sans le faire dans l'autre), et dans ce cas on a une comparaison tellement générale qu'elle ne retranscrira pas la particularité d'un langage à résoudre un problème donné. Mais en faisant un mélange entre les deux, au lieu d'obtenir une conclusion partielle, ils obtiennent une conclusion invalide.
Après dans le détail, je viens juste de l'évoquer, pour les quelques langages que je connais, je saute au plafond. En C++ outre les boucles dans un ordre étrange, c'est du code vectorisable, il y a des libs pour ça. Dans un des code, j'ai eu l'horreur de voir une definition d'un template Matrix à la main. Moi aussi quand j'étais jeune j'ai codé intégralement sans rien y connaître mes libs de calcul matriciel (j'ai même écrit une lib d'algèbre linéaire en PHP, oui j'ai honte), oh ben on a des opérations inefficace aussi bien en temps qu'en mémoire, c'est étrange.
Au niveau du choix des langages, on a également de qui être dubitatif, Mathematica, vraiment. Oui un logiciel de calcul symbolique n'est pas un logiciel de calcul numérique. MATLAB, c'est efficace pour du calcul matriciel, oui les trois premières lettres du noms ne sont pas là par hasard. On peut être dubitatif également sur le soin apporté à chaque logiciel, par exemple en MATLAB on fait un MEX, en R on pourrait implémenter une procédure C ou C++ (qui aurait les perfs du C, et avec les libs adaptés genre Rcpp ça a le niveau de simplicité du R), et après la conclusion sur R est négative, on s'y attendait.
Après pour les conclusions, elles ne sont pas vraiment fausse (enfin certaines me laissent séptique pour ne pas dire ahuri), mais elles enfoncent des portes ouvertes. Oui les langages compilés sont plus rapide pour faire des boucles, oui les langages adaptés pour le calcul matriciel (R, MATLAB) ne sont pas adaptés pour faire des boucles, oui les langages de calculs symbolique ne sont pas adaptés pour faire du calcul numérique, oui la compilation JIT c'est le bien.
Bref, ça vaut rien ce benchmark. L'article ne semble pas publié dans une revue, autrement il aurait clairement mérité une réponse en règle.
# Du grand n'importe quoi
Posté par jben . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 10. Dernière modification le 27 juin 2014 à 03:57.
J'ai envie de dire que ce genre de benchmark mesure surtout ma méconnaissance des langages.
Déjà un problème conceptuel. Dans l'article ils décrivent leur problème, mais ils ne décrivent pas leur algo. Qui semble aller de soi quand on lit l'article, mais quand on regarde dans le détail il y a plein de petits trucs qui peuvent tout changer. Il aurait été un minimum de mettre dans l'article ou dans une annexe l'algo de manière dissociée du language.
Un autre problème conceptuel est sur le choix de l'algo utilisé dans la comparaison. C'est un algo qui est vectorisable, où beaucoup d'étape (peut-être toutes) peuvent êtres écrites sous forme de calcul matriciel. Ça implique pas mal de chose, quand à l'utilisation des libs adaptées et quand à la capacité des differents compilateurs de de faire des opérations utiles comme changer l'ordre des boucles.
Le point du calcul matriciel m'amène à voir que dans certains programmes (MATLAB par exemple) certaines étapes vectorisables sont vectorisés, mais pas d'autres (pourquoi ?) et dans d'autres (en C++ par exemple) ces mêmes étapes ne sont pas vectorisées (pourquoi ? ils ne connaissent pas les libs comme armadillo ?). Dans un benchmark, le minimum est de mettre toutes les possiblilités dans des conditions équivalentes. Soit on utilise les subtilitées et les capacités de chaque language pour optimiser au mieux le code, et dans ce cas on compare les langages dans un cas très particulier, les conclusions sont attachées à ce cas particulier. Soit on utilise rigoureusement le même algo (et ne vectorise pas dans un code sans le faire dans l'autre), et dans ce cas on a une comparaison tellement générale qu'elle ne retranscrira pas la particularité d'un langage à résoudre un problème donné. Mais en faisant un mélange entre les deux, au lieu d'obtenir une conclusion partielle, ils obtiennent une conclusion invalide.
Après dans le détail, je viens juste de l'évoquer, pour les quelques langages que je connais, je saute au plafond. En C++ outre les boucles dans un ordre étrange, c'est du code vectorisable, il y a des libs pour ça. Dans un des code, j'ai eu l'horreur de voir une definition d'un template
Matrixà la main. Moi aussi quand j'étais jeune j'ai codé intégralement sans rien y connaître mes libs de calcul matriciel (j'ai même écrit une lib d'algèbre linéaire en PHP, oui j'ai honte), oh ben on a des opérations inefficace aussi bien en temps qu'en mémoire, c'est étrange.Au niveau du choix des langages, on a également de qui être dubitatif, Mathematica, vraiment. Oui un logiciel de calcul symbolique n'est pas un logiciel de calcul numérique. MATLAB, c'est efficace pour du calcul matriciel, oui les trois premières lettres du noms ne sont pas là par hasard. On peut être dubitatif également sur le soin apporté à chaque logiciel, par exemple en MATLAB on fait un MEX, en R on pourrait implémenter une procédure C ou C++ (qui aurait les perfs du C, et avec les libs adaptés genre Rcpp ça a le niveau de simplicité du R), et après la conclusion sur R est négative, on s'y attendait.
Après pour les conclusions, elles ne sont pas vraiment fausse (enfin certaines me laissent séptique pour ne pas dire ahuri), mais elles enfoncent des portes ouvertes. Oui les langages compilés sont plus rapide pour faire des boucles, oui les langages adaptés pour le calcul matriciel (R, MATLAB) ne sont pas adaptés pour faire des boucles, oui les langages de calculs symbolique ne sont pas adaptés pour faire du calcul numérique, oui la compilation JIT c'est le bien.
Bref, ça vaut rien ce benchmark. L'article ne semble pas publié dans une revue, autrement il aurait clairement mérité une réponse en règle.