Pendant longtemps, BEAM utilisait un ordonnanceur (scheduler) interne et un thread système. Le système (Linux, par exemple), ne voit qu'un seul thread.
Avec la massification des systèmes SMP/multicore, la BEAM démarre (par défaut) un thread par core, un scheduler par thread système.
Par défaut, les processus erlang ne sont pas liés à un scheduler particulier, et les schedulers piochant dans une run list partagée.
Go a une mise en œuvre similaire.
Pour le passage de message en temps constant, c'est dans le cadre d'un benchmark s'exécutant bien sûr toujours sur la même machine. Cela démontre juste que le nombre de processus erlang ne crée pas un 'overhead' impactant les performances.
Par contre, effectivement, erlang a été conçue dès le début pour être extrêmement tolérant aux pannes et, donc, aucune garantie sur le temps de délivrance de message n'est donnée, pas même de garantie de délivrance. Au sein d'un même 'node', on peut raisonnablement estimer que les messages sont tous délivrés, mais ce n'est pas le cas entre différents 'node' (qui communiquent par défaut en UDP). D'où également une gestion explicite du temps qui permet d'avoir un système toujours réactif. Par défaut, toute attente de message est limitée par un timeout.
En ce qui concerne les perfs des I/O, c'est effectivement une limitation d'erlang. Limitation assez théorique d'ailleurs puisque:
1. des optimisations sont possibles, et ont été mises en œuvre: les messages ne sont copiés que si vraiment nécessaires (modification ou transfert sur un autre noeud);
2. erlang intègre la possibilité de mapper des fonctions erlang sur des fonctions écrites en C. C'est même considéré comme une bonne pratique pour peu que le code soit circonscrit, bien testé :P et interagisse avec les scheduler pour ne pas bloquer les autres processus (lire Respecting the scheduler in erlang NIFs.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par Jean Parpaillon . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 4.
Il y un papier assez complet sur le sujet: http://www.erlang.se/euc/08/euc_smp.pdf
Pendant longtemps, BEAM utilisait un ordonnanceur (scheduler) interne et un thread système. Le système (Linux, par exemple), ne voit qu'un seul thread.
Avec la massification des systèmes SMP/multicore, la BEAM démarre (par défaut) un thread par core, un scheduler par thread système.
Par défaut, les processus erlang ne sont pas liés à un scheduler particulier, et les schedulers piochant dans une run list partagée.
Go a une mise en œuvre similaire.
Pour le passage de message en temps constant, c'est dans le cadre d'un benchmark s'exécutant bien sûr toujours sur la même machine. Cela démontre juste que le nombre de processus erlang ne crée pas un 'overhead' impactant les performances.
Par contre, effectivement, erlang a été conçue dès le début pour être extrêmement tolérant aux pannes et, donc, aucune garantie sur le temps de délivrance de message n'est donnée, pas même de garantie de délivrance. Au sein d'un même 'node', on peut raisonnablement estimer que les messages sont tous délivrés, mais ce n'est pas le cas entre différents 'node' (qui communiquent par défaut en UDP). D'où également une gestion explicite du temps qui permet d'avoir un système toujours réactif. Par défaut, toute attente de message est limitée par un timeout.
En ce qui concerne les perfs des I/O, c'est effectivement une limitation d'erlang. Limitation assez théorique d'ailleurs puisque:
1. des optimisations sont possibles, et ont été mises en œuvre: les messages ne sont copiés que si vraiment nécessaires (modification ou transfert sur un autre noeud);
2. erlang intègre la possibilité de mapper des fonctions erlang sur des fonctions écrites en C. C'est même considéré comme une bonne pratique pour peu que le code soit circonscrit, bien testé :P et interagisse avec les scheduler pour ne pas bloquer les autres processus (lire Respecting the scheduler in erlang NIFs.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier