> Mais il n'utilise qu'un seul core [1], tout comme Mozart, Smalltalk et
> Scheme.
A priori, la machine Erlang est capable du multi-coeur depuis quelques années déjà (ele était mono coeur avant).
> Mon petit doit me dit que ce test crée plein de thread qui ne font
> quasiment rien. Du coup ce test test la rapidité de création de thread, et
> les implémentations purement userspace gagne haut la main car il n'y a
> pas tout l'overhead kernel...
On sais bien en utilisant la bibliothèque OpenMP qu'on a intérêt à lancer la boucle parallèle la plus large possible sur le code source, c'est à dire le plus tôt possible et de la fermer le plus tard possible. En effet, le lancement des threads est terrible en terme de performance.
On utilise donc des prama OpenMP de type singleton pour dire que certains passages ne sont pas à faire en parallèle. Cela permet de garder les threads ouvert mais qui ne font rien (sauf un) pour la suite du programme.
Un petit tour du coté d'OpenMP est aussi très intéressant pour comprendre une partie de la problématique.
Il est clair que si la conception du langage fait que le compilateur est capable de faire cela a notre place, c'est génial.
[^] # Re: perf
Posté par Sytoka Modon (site web personnel) . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 1.
> Scheme.
A priori, la machine Erlang est capable du multi-coeur depuis quelques années déjà (ele était mono coeur avant).
> Mon petit doit me dit que ce test crée plein de thread qui ne font
> quasiment rien. Du coup ce test test la rapidité de création de thread, et
> les implémentations purement userspace gagne haut la main car il n'y a
> pas tout l'overhead kernel...
On sais bien en utilisant la bibliothèque OpenMP qu'on a intérêt à lancer la boucle parallèle la plus large possible sur le code source, c'est à dire le plus tôt possible et de la fermer le plus tard possible. En effet, le lancement des threads est terrible en terme de performance.
On utilise donc des prama OpenMP de type singleton pour dire que certains passages ne sont pas à faire en parallèle. Cela permet de garder les threads ouvert mais qui ne font rien (sauf un) pour la suite du programme.
Un petit tour du coté d'OpenMP est aussi très intéressant pour comprendre une partie de la problématique.
Il est clair que si la conception du langage fait que le compilateur est capable de faire cela a notre place, c'est génial.