En ce qui concerne les perfs des I/O, c'est effectivement une limitation d'erlang.
Ce n'est pas ce que je voulais dire. Je disais qu'il me semble que c'est un modèle de programmation surtout fait pour des programmes I/O bound (et même latence bound). Les threads légers sont conçu (il me semble, hein) pour gérer des I/O concurrentes et pas pour de la parallélisation. Si je prend par exemple la génération d'une rainbow table (premier truc qui me vient en tête cpu bound parallélisable) il n'y a pas d'intérêt (en tout cas en terme de perf) de spawn un thread léger par entrée plutôt que d'itérer avec un threads système par cpu.
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.
J'ai pas encore lu le lien, mais ça me parait très casse gueule. Il n'y a pas de raison particulière qu'une bibliothèque C respecte le scheduler erlang... Il n'y a pas moyen de plutôt faire interagir ça avec un passage de message ? Tu as du code erlang/C qui attend/envoi des messages et qui se fout du scheduler erlang et le reste du programme vie sa meilleure vie ? Ça demande soit des api particulières (par exemple avec un binding C du protocole udp des messages) soit de pouvoir créer un thread qui ne soit pas géré par l'ordonnanceur erlang.
C'est comme ça que bosse elm toute interaction avec du js se fait par envoi de message et il y a une api js d'envoi/réception de message. Je trouve ça très propre.
En tout cas merci je vais regarder les liens que tu m'a donné.
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par barmic 🦦 . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 3.
Merci pour tes précisions.
Ce n'est pas ce que je voulais dire. Je disais qu'il me semble que c'est un modèle de programmation surtout fait pour des programmes I/O bound (et même latence bound). Les threads légers sont conçu (il me semble, hein) pour gérer des I/O concurrentes et pas pour de la parallélisation. Si je prend par exemple la génération d'une rainbow table (premier truc qui me vient en tête cpu bound parallélisable) il n'y a pas d'intérêt (en tout cas en terme de perf) de spawn un thread léger par entrée plutôt que d'itérer avec un threads système par cpu.
J'ai pas encore lu le lien, mais ça me parait très casse gueule. Il n'y a pas de raison particulière qu'une bibliothèque C respecte le scheduler erlang... Il n'y a pas moyen de plutôt faire interagir ça avec un passage de message ? Tu as du code erlang/C qui attend/envoi des messages et qui se fout du scheduler erlang et le reste du programme vie sa meilleure vie ? Ça demande soit des api particulières (par exemple avec un binding C du protocole udp des messages) soit de pouvoir créer un thread qui ne soit pas géré par l'ordonnanceur erlang.
C'est comme ça que bosse elm toute interaction avec du js se fait par envoi de message et il y a une api js d'envoi/réception de message. Je trouve ça très propre.
En tout cas merci je vais regarder les liens que tu m'a donné.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll