Comment est-ce que les threads légers peuvent utiliser plusieurs nœuds de calcul ? L'ordonnanceur noyau prend un thread système d'un processus et lui donne un temps d'exécution sur un CPU. Il ne voit pas les threads légers et ne peut donc les exécuter en parallèle sur des cores distincts.
Je crois savoir que go crée un thread système/cpu et associe les threads légers à ces threads systèmes1.
Si beam fait pareil il n'y a pas de problème si le profile de travail n'est pas homogène entre les paquets de threads légers par exemple ? C'est un truc au quel il faut faire attention ? Par exemple ne pas créer tous les threads cpu intensive au même moment ou quelque chose du genre ?
Tu parle de passage de messages constant ça me parait aller à l'encontre de la démarche d'erlang, l'objectif du passage de message c'est d'avoir un couplage faible et de gérer les latences élevées par exemple parce que tu ne sais pas si le destinataire de ton message est sur le même thread léger/instance que toi. Si dans bien des cas c'est très performant si on souhaite que ce soit transparent il faut pas trop s'appuyer sur cette performance au risque d'avoir des problèmes quand on quitte les tests sur sa machine et qu'on passe dans un environnement cluster.
Il me semble que s'orienter vers des threads léger est surtout utile pour des workloads qui nécessitent un très grand nombre de petits I/O. C'est à dire quand ce qui freine l'application c'est la latence des I/O et pas le temps de calcul par exemple. En effet l'ordonnanceur en espace utilisateur ne préempte pas les threads léger et va s'appuyer sur leurs I/O pour les commuter. Ça ne paraît pas idiot pour des télécoms et pour rabbitmq d'avoir ce genre de besoins d'ailleurs.
Tu as des retours sur comment c'est implémenter et sur dans quel cas ça marche moins bien ?
J'y pense après coup une autre solution, celle de node, est de ne pas gérer de parallélisme du tout et de lancer un nodejs par cpu pour pouvoir être parallèle. ↩
[^] # 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é à 2.
Comment est-ce que les threads légers peuvent utiliser plusieurs nœuds de calcul ? L'ordonnanceur noyau prend un thread système d'un processus et lui donne un temps d'exécution sur un CPU. Il ne voit pas les threads légers et ne peut donc les exécuter en parallèle sur des cores distincts.
Je crois savoir que go crée un thread système/cpu et associe les threads légers à ces threads systèmes1 .
Si beam fait pareil il n'y a pas de problème si le profile de travail n'est pas homogène entre les paquets de threads légers par exemple ? C'est un truc au quel il faut faire attention ? Par exemple ne pas créer tous les threads cpu intensive au même moment ou quelque chose du genre ?
Tu parle de passage de messages constant ça me parait aller à l'encontre de la démarche d'erlang, l'objectif du passage de message c'est d'avoir un couplage faible et de gérer les latences élevées par exemple parce que tu ne sais pas si le destinataire de ton message est sur le même thread léger/instance que toi. Si dans bien des cas c'est très performant si on souhaite que ce soit transparent il faut pas trop s'appuyer sur cette performance au risque d'avoir des problèmes quand on quitte les tests sur sa machine et qu'on passe dans un environnement cluster.
Il me semble que s'orienter vers des threads léger est surtout utile pour des workloads qui nécessitent un très grand nombre de petits I/O. C'est à dire quand ce qui freine l'application c'est la latence des I/O et pas le temps de calcul par exemple. En effet l'ordonnanceur en espace utilisateur ne préempte pas les threads léger et va s'appuyer sur leurs I/O pour les commuter. Ça ne paraît pas idiot pour des télécoms et pour rabbitmq d'avoir ce genre de besoins d'ailleurs.
Tu as des retours sur comment c'est implémenter et sur dans quel cas ça marche moins bien ?
J'y pense après coup une autre solution, celle de node, est de ne pas gérer de parallélisme du tout et de lancer un nodejs par cpu pour pouvoir être parallèle. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll