Bonjour,
J'aimerais avoir une notion du nombre de threads qu'un programme est capable de générer tout en limitant la perte de performance. Certes le gain de performance peut-être énorme par l'utilisation des threads mais j'imagine que le changement de contexte pour passer d'un thread à un autre coûte en nombre de cycles et que le changement de contexte pourrait devenir trop coûteux. J'imagine que théoriquement si les portions de code par thread sont petites, il serait possible que le CPU passe plus de temps à changer de thread qu'à exécuter le code.
D'après mes recherches, le nombre maximum de threads dépend:
- de la machine (cpu cores, pile)
- de l'OS de la machine hote (apparement OSX limite à 2000)
- du scheduler
Et ce nombre est très variable dans ce que je trouve (cf. les articles ci-dessous). Certains parlent de quelques centaines (lien 2). Pour ma part si j'execute les commandes du 3 ième lien j'obtiens:
bob@hp840g3:~$ cat /proc/sys/kernel/threads-max
256309
bob@hp840g3:~$ ulimit
unlimited
Ce qui dirait que je peux créer autant de threads que je veux tant qu'il y en a moins de 256 309 sans que l'OS (debian 9) me l'interdise. Ce qui n'empeche pas que je peux perdre du temps dans le changement de contexte.
Comment est-il possible de définir le nombre de thread sans qu'il y est de perte importante de performance? Est-il dépendant du language utilisé? Par exemple, a-t-on la capacité de définir la taille de la pile par thread en Python?
Mon code peut-il créer quelques dizaines de milliers de thread?
Tout éclairage est la bienvenue
En espérant que mes explications du problème sont claires,
Merci,
https://www.jstorimer.com/blogs/work...ds-is-too-many
https://apps.fz-juelich.de/jsc-pubsy...30c53024f3.pdf
https://ubuntuplace.info/questions/1...eads-autorises
Partager