Nombre Maximum de Threads

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

Tu n'as pas de changement de contexte lors d'un changement de thread dans un même processus, les threads ont juste chacun leur pile.

Sur une VM Debian Stretch avec 2 Go de RAM threads-max me retourne 16037. Si je passe ma VM à 1 Go, j'ai 7953. T’aurais pas 32 Go de RAM ?

Il doit y avoir quelque chose que je n'ai pas bien compris, aurais-tu de la doc de référence au sujet des threads et de ces histoires de contexte?
Celà veut-il alors dire qu'on peut quasiment créer autant de thread qu'on le veut sans perte notable des performances à condition que ces threads soient du même processus? Aussi, qu'entends tu processus? Mon programe = 1 processus par exemple on a bien la même définition?
Oui c'est ça, j'ai bien 32Go de RAM.
Merci de ton aide

Un processus c'est l'instance en mémoire et en cours d'execution d'un exécutable. Il est constitué des pages mémoires correspondant aux pages de codes, de données, de bss, de pile et de son contexte. Le contexte est la structure de gestion du processus, il va représenter et contenir : l'état du processus, les registres processeur de celui-ci (à travers leur sauvegarde sur la pile du processus), l'espace d'adressage (les pages mémoires désignés ci-dessus, plus les bibliothèques partagées disponibles pour le processus, les pages noyau accessibles), l'état des fichiers ouverts, etc.

Un changement de contexte va en simplifiant interrompre le processus le marquant interrompu dans sa structure, sauvegarder les registres sur sa pile, élire le nouveau processus à activer, charger sa table d'adressage, éventuellement sortir ses pages mémoire du swap si nécessaire, récupérer sa pile, dépiler les registres et reprendre le code là ou il était interrompu, ce qui requiert beaucoup de manips. Un thread aussi appelé processus léger partage le contexte (table d'adressage, fichiers ouverts, etc.) avec les autres thread du processus, il a juste sa propre pile.
Un processus contient à minima un thread. Chaque thread va bouffer au moins une page mémoire, tu comprend donc qu'il faut limiter le nombre de processus et de threads pour éviter par exemple les fork bomb. Par ailleurs l'OS va réserver un pourcentage d'espace disque et de processus possible au compte root, pour pouvoir gérer en cas de problème justement. Le nombre max de threads/processus est modifiable du moins sous Linux, ce sont des valeurs par défaut. Sur d'autres OS, ces valeurs peuvent être différentes.

Le temps des différentes core du cpu est partagé entre tous les processus.

Plus tu as des processus travaillant en parallèle, plus il y a de commutations de contexte pendant lequel le cpu fait un travail qu'on pourrait qualifier d’administratif au lieu de technique. et quand tu fais de l'administratif, tu ne fais pas autre chose.

Donc avoir une multitude de thread pour notre programme ne fait pas perdre énormément de temps puisque c'est le même processus, c'est bien ça?
Et la taille d'une page fait 124Ko (32000/256309)?
Et donc le nombre de thread dépend plus de la quantité de RAM que du processeur?

Citation:

---

Donc avoir une multitude de thread pour notre programme ne fait pas perdre énormément de temps puisque c'est le même processus, c'est bien ça?

---

ça fait perdre beaucoup moins de temps, mais ça en fait perdre quand même, changement de thread=sauvegarde des registres sur la pile, restauration des registres de l'autre thread. Sans compter que si tu ne gères pas bien les variables globales, les mutex, tu peux générer de sacrés problèmes.

Citation:

---

Et la taille d'une page fait 124Ko (32000/256309)?

---

La taille d'une page c'est en général 4K.

Citation:

---

Et donc le nombre de thread dépend plus de la quantité de RAM que du processeur?

---

Ca va dépendre des 2, plus tu as de threads, plus la RAM nécessaire qui leur ai nécessaire va être importante (minimum 1 page pour la pile soit 4K, mais peut-être plus). Plus tu as de coeurs CPU, plus tu pourras exécuter des processus, et donc leur threads de façon simultanée.

Il est logique qu'une variable comme threads-max en tienne compte, mais comme déjà dit, cela dépend de l'OS, sous Linux, la valeur par défaut peut être modifiée à la volée, sur les autres OS je sais pas.

Ok donc je devrais pouvoir générer quelques dizaines de threads pour un programme avec une bonne machine en faisant bien attention aux mutex.
Merci pour ton éclairage :ccool::ccool:
Faut maintenant que je passe à l'implémentation