Leur objectif, clairement affiché (« we are porofoundly unintersted »), n'est pas de se servir des résultats comme base pour determiner les performances relatives des différents langages.
Je déteste me répéter. Encore une fois, ce qu'ils annoncent c'est que ces benchmarks ne sont pas représentatifs des performances d'un langage dans son ensemble mais pour un problème donné justement défini par le toy benchmark lui même.
Je te conseil sincèrement de te renseigner plus sur le concept de "mini-app" et ce que ça implique dans le domaine du Calcul à haute performance (HPC). Ça t'evitera de sortir ce genre d'anerie à l'avenir.
Ensuite, passons à l'analyse d'un des tests, celui qui semble te préoccuper le plus : la gestion de la mémoire. Pour mettre à l'épreuve les GC, il y a le test binary trees
Toute les mini-app à base binary tree montrent principalement l'impact du trashing du cache du processeur.
Si tu veux un benchmark qui pousse un GC à ses limites dans un context des calculs mathématiques plus intensif. Le mini-app sur sur mandelbrot est beaucoup plus intéressant.
Tiens, on se rapproche déjà plus des performances de OCaml et Haskell ! Mais que ce passe-t-il donc dans ce code C par rapport au super code de la mort qui tue en 3.26 secondes ? Tout simplement il optimise bien moins le parallélisme. Il utilise pthread là où le plus rapide utilise apr-1.0.
Tu ne sais pas lire du code C j'ai juste ?
apr n'a rien à voir avec pthread ni même avec le threading. gcc#3 utilise openMP et gcc#5 pthread.
La différence de performance provient trés probablement du fait que gcc#3 utilise une gestion manuel de la mémoire avec une memory pool ( utilisant apr ).
Ironiquement, tu as selectionner un bench qui valide ce que je disais précédemment sur les memory pool.
vu que c'est lui qui a soumis le code le plus lent (enfin, il a apporté des modifications sur le code d'un autre) : il sait pertinemment optimiser du calcul parallèle en OCaml
Ou peut-être que OCaml a un global interpreter lock qui l'empeche d'utiliser proprement du multi-threading, et que même le meilleur programmeur du monde ne peut pas changer ça ?
C'est d'ailleurs pour cela que le benchmark OCaml#2 fork() / join() et multi-process pour pouvoir compenser.
Les benchmarks, c'est bien, encore faut-il en analyser correctement les résultats. ;-)
Assez ironique en soit quand on réalise que ton analyse est presque fausse du début à la fin.
Ceci dit, je déteste perdre mon temps avec des personnes dont l'argumentation n'étaye sur aucun fait mais juste sur leur propre théologie. Je cesserai donc de poster ici.
Je te conseille par contre de t’intéresser un poil plus au langages à bas niveau et pas seulement au calcul formelle. tu risques de voir le monde un peu plus pragmatiquement :)
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 0. Dernière modification le 12 mai 2016 à 21:27.
Je déteste me répéter. Encore une fois, ce qu'ils annoncent c'est que ces benchmarks ne sont pas représentatifs des performances d'un langage dans son ensemble mais pour un problème donné justement défini par le toy benchmark lui même.
Je te conseil sincèrement de te renseigner plus sur le concept de "mini-app" et ce que ça implique dans le domaine du Calcul à haute performance (HPC). Ça t'evitera de sortir ce genre d'anerie à l'avenir.
Toute les mini-app à base binary tree montrent principalement l'impact du trashing du cache du processeur.
Si tu veux un benchmark qui pousse un GC à ses limites dans un context des calculs mathématiques plus intensif. Le mini-app sur sur mandelbrot est beaucoup plus intéressant.
Tu ne sais pas lire du code C j'ai juste ?
apr n'a rien à voir avec pthread ni même avec le threading. gcc#3 utilise openMP et gcc#5 pthread.
La différence de performance provient trés probablement du fait que gcc#3 utilise une gestion manuel de la mémoire avec une memory pool ( utilisant apr ).
Ironiquement, tu as selectionner un bench qui valide ce que je disais précédemment sur les memory pool.
Ou peut-être que OCaml a un global interpreter lock qui l'empeche d'utiliser proprement du multi-threading, et que même le meilleur programmeur du monde ne peut pas changer ça ?
C'est d'ailleurs pour cela que le benchmark OCaml#2 fork() / join() et multi-process pour pouvoir compenser.
Assez ironique en soit quand on réalise que ton analyse est presque fausse du début à la fin.
Ceci dit, je déteste perdre mon temps avec des personnes dont l'argumentation n'étaye sur aucun fait mais juste sur leur propre théologie. Je cesserai donc de poster ici.
Je te conseille par contre de t’intéresser un poil plus au langages à bas niveau et pas seulement au calcul formelle. tu risques de voir le monde un peu plus pragmatiquement :)