J'ai développé une appli qui utilise pas mal les threads (module threading).
Chaque thread fait beaucoup de calculs mais pas trop de telle sorte
que les autres applications du système réagissent correctement (les
threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter).
Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher"
les threads du main thread ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Combelle
olivier Ravard wrote:
Bonjour à tous,
J'ai développé une appli qui utilise pas mal les threads (module threading). Chaque thread fait beaucoup de calculs mais pas trop de telle sorte que les autres applications du système réagissent correctement (les threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter). Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher" les threads du main thread ?
Merci pour vos réponses et suggestions.
O.R.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread, et donc plus tu a de thread, plus chaque thread s'execute lentement.
Le truc important à savoir sur les thread, c'est que, si ils ne sont utilisés que pour faire du calcul, ils ne servent à rien (sauf si tu as plusieurs processeurs, et ce n'est pas sur que python le gère). Les thread ne sont utiles que pour optimiser l'utilisation du processeur pour ne pas rester sans rien faire lors d'appels système blocants (comme la lecture de fichier, l'accès au réseau, l'interface graphique). J'aurai une tendance à préférer deux thread, l'un pour faire l'ihm et l'autre pour gérer les calculs. Et tu utilise le module Queue pour passer tes commandes au thread de calcul.
Si tu veux continuer à gérer beaucoup de thread, je te conseilles d'utiliser deux processus différents et les faire communiquer en utilisant des librairies du genre socket ou de popen2.
Du point de vue performance, j'aurai tendance à utiliser des bibliothèques optimisées pour tes calculs (genre array ou http://numpy.sourceforge.net/) et/ou psyco.
Xavier Combelle
olivier Ravard wrote:
Bonjour à tous,
J'ai développé une appli qui utilise pas mal les threads (module
threading).
Chaque thread fait beaucoup de calculs mais pas trop de telle sorte
que les autres applications du système réagissent correctement (les
threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter).
Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher"
les threads du main thread ?
Merci pour vos réponses et suggestions.
O.R.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread,
et donc plus tu a de thread, plus chaque thread s'execute
lentement.
Le truc important à savoir sur les thread, c'est que, si ils
ne sont utilisés que pour faire du calcul, ils ne servent à rien
(sauf si tu as plusieurs processeurs, et ce n'est pas sur que python
le gère). Les thread ne sont utiles que pour optimiser l'utilisation
du processeur pour ne pas rester sans rien faire lors d'appels système
blocants (comme la lecture de fichier, l'accès au réseau, l'interface
graphique). J'aurai une tendance à préférer deux thread, l'un pour faire
l'ihm et l'autre pour gérer les calculs. Et tu utilise le module Queue
pour passer tes commandes au thread de calcul.
Si tu veux continuer à gérer beaucoup de thread,
je te conseilles d'utiliser deux processus différents
et les faire communiquer en utilisant des librairies du genre
socket ou de popen2.
Du point de vue performance, j'aurai tendance à utiliser
des bibliothèques optimisées pour tes calculs (genre array ou
http://numpy.sourceforge.net/) et/ou psyco.
J'ai développé une appli qui utilise pas mal les threads (module threading). Chaque thread fait beaucoup de calculs mais pas trop de telle sorte que les autres applications du système réagissent correctement (les threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter). Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher" les threads du main thread ?
Merci pour vos réponses et suggestions.
O.R.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread, et donc plus tu a de thread, plus chaque thread s'execute lentement.
Le truc important à savoir sur les thread, c'est que, si ils ne sont utilisés que pour faire du calcul, ils ne servent à rien (sauf si tu as plusieurs processeurs, et ce n'est pas sur que python le gère). Les thread ne sont utiles que pour optimiser l'utilisation du processeur pour ne pas rester sans rien faire lors d'appels système blocants (comme la lecture de fichier, l'accès au réseau, l'interface graphique). J'aurai une tendance à préférer deux thread, l'un pour faire l'ihm et l'autre pour gérer les calculs. Et tu utilise le module Queue pour passer tes commandes au thread de calcul.
Si tu veux continuer à gérer beaucoup de thread, je te conseilles d'utiliser deux processus différents et les faire communiquer en utilisant des librairies du genre socket ou de popen2.
Du point de vue performance, j'aurai tendance à utiliser des bibliothèques optimisées pour tes calculs (genre array ou http://numpy.sourceforge.net/) et/ou psyco.
Xavier Combelle
olivier Ravard
Xavier Combelle wrote:
olivier Ravard wrote:
Bonjour à tous,
J'ai développé une appli qui utilise pas mal les threads (module threading). Chaque thread fait beaucoup de calculs mais pas trop de telle sorte que les autres applications du système réagissent correctement (les threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter). Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher" les threads du main thread ?
Merci pour vos réponses et suggestions.
O.R.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread, et donc plus tu a de thread, plus chaque thread s'execute lentement.
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
Le truc important à savoir sur les thread, c'est que, si ils ne sont utilisés que pour faire du calcul, ils ne servent à rien (sauf si tu as plusieurs processeurs, et ce n'est pas sur que python le gère). Les thread ne sont utiles que pour optimiser l'utilisation du processeur pour ne pas rester sans rien faire lors d'appels système blocants (comme la lecture de fichier, l'accès au réseau, l'interface graphique). J'aurai une tendance à préférer deux thread, l'un pour faire l'ihm et l'autre pour gérer les calculs. Et tu utilise le module Queue pour passer tes commandes au thread de calcul.
Si tu veux continuer à gérer beaucoup de thread, je te conseilles d'utiliser deux processus différents et les faire communiquer en utilisant des librairies du genre socket ou de popen2.
Du point de vue performance, j'aurai tendance à utiliser des bibliothèques optimisées pour tes calculs (genre array ou http://numpy.sourceforge.net/) et/ou psyco.
J'utilise déjà.
Xavier Combelle
Xavier Combelle wrote:
olivier Ravard wrote:
Bonjour à tous,
J'ai développé une appli qui utilise pas mal les threads (module
threading).
Chaque thread fait beaucoup de calculs mais pas trop de telle sorte
que les autres applications du système réagissent correctement (les
threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter).
Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher"
les threads du main thread ?
Merci pour vos réponses et suggestions.
O.R.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread,
et donc plus tu a de thread, plus chaque thread s'execute
lentement.
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le
thread de calcul tourne, les appli système réagissent bien alors
que l'IHM réagit très lentement.
Le truc important à savoir sur les thread, c'est que, si ils
ne sont utilisés que pour faire du calcul, ils ne servent à rien
(sauf si tu as plusieurs processeurs, et ce n'est pas sur que python
le gère). Les thread ne sont utiles que pour optimiser l'utilisation
du processeur pour ne pas rester sans rien faire lors d'appels système
blocants (comme la lecture de fichier, l'accès au réseau, l'interface
graphique). J'aurai une tendance à préférer deux thread, l'un pour faire
l'ihm et l'autre pour gérer les calculs. Et tu utilise le module Queue
pour passer tes commandes au thread de calcul.
Si tu veux continuer à gérer beaucoup de thread,
je te conseilles d'utiliser deux processus différents
et les faire communiquer en utilisant des librairies du genre
socket ou de popen2.
Du point de vue performance, j'aurai tendance à utiliser
des bibliothèques optimisées pour tes calculs (genre array ou
http://numpy.sourceforge.net/) et/ou psyco.
J'ai développé une appli qui utilise pas mal les threads (module threading). Chaque thread fait beaucoup de calculs mais pas trop de telle sorte que les autres applications du système réagissent correctement (les threads ne prennent pas toutes les ressources système).
Pourtant, le main thread réagit très lentement (interface Tkinter). Est-ce que quelqu'un a une idée ? Y a-t-il un moyen pour "détacher" les threads du main thread ?
Merci pour vos réponses et suggestions.
O.R.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread, et donc plus tu a de thread, plus chaque thread s'execute lentement.
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
Le truc important à savoir sur les thread, c'est que, si ils ne sont utilisés que pour faire du calcul, ils ne servent à rien (sauf si tu as plusieurs processeurs, et ce n'est pas sur que python le gère). Les thread ne sont utiles que pour optimiser l'utilisation du processeur pour ne pas rester sans rien faire lors d'appels système blocants (comme la lecture de fichier, l'accès au réseau, l'interface graphique). J'aurai une tendance à préférer deux thread, l'un pour faire l'ihm et l'autre pour gérer les calculs. Et tu utilise le module Queue pour passer tes commandes au thread de calcul.
Si tu veux continuer à gérer beaucoup de thread, je te conseilles d'utiliser deux processus différents et les faire communiquer en utilisant des librairies du genre socket ou de popen2.
Du point de vue performance, j'aurai tendance à utiliser des bibliothèques optimisées pour tes calculs (genre array ou http://numpy.sourceforge.net/) et/ou psyco.
J'utilise déjà.
Xavier Combelle
Cofr
...
En fait, la plupart du temps, un seul thread tourne (plus le main thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
...
Peut être que ton thread de calcul est un peu trop gourmand en CPU (va voir l'occupation CPU de ton PC), tu peux limiter l'occupation CPU en faisant respirer l'IHM, par un sleep de temps en temps dans ta boucle de calcul.
...
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le
thread de calcul tourne, les appli système réagissent bien alors
que l'IHM réagit très lentement.
...
Peut être que ton thread de calcul est un peu trop gourmand
en CPU (va voir l'occupation CPU de ton PC), tu peux limiter l'occupation
CPU en faisant respirer l'IHM, par un sleep de temps
en temps dans ta boucle de calcul.
En fait, la plupart du temps, un seul thread tourne (plus le main thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
...
Peut être que ton thread de calcul est un peu trop gourmand en CPU (va voir l'occupation CPU de ton PC), tu peux limiter l'occupation CPU en faisant respirer l'IHM, par un sleep de temps en temps dans ta boucle de calcul.
Xavier Combelle
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread, et donc plus tu a de thread, plus chaque thread s'execute lentement.
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
Ben, c'est à dire que les appli système sont dans des process différents
et pas des thread au sein d'un même processus. (voir par exemple http://www.lifl.fr/~boulet/formation/syst-dist/exposes2003-2004/threads/ pour comprendre la différence entre thread(= LWP) et processus Il y a donc deux politiques d'ordonnecement différentes qui, en plus dépendent de l'implémentation de l'os et de python, voire de l'ihm. Je pense que, dans ton cas, la politique d'ordonnencement des processus convient mieux à ce que tu désire. Je te conseille d'utiliser donc deux processus différents, un pour ton ihm et un pour tes calculs.
Si tu veux continuer à gérer beaucoup de thread, je te conseilles d'utiliser deux processus différents et les faire communiquer en utilisant des librairies du genre socket ou de popen2.
et je pense que socket et popen2 conviennent toujours pour gérer deux processus différent.
En plus, si tu es sur linux, tu peux utiliser nice pour donner plus ou moins de priorité à chacun de tes processus, windows ayant un truc équivalent quand tu fait Ctrl+alt+supr -> gestion des processus.
Xavier.
Ben je dirais que c'est normal.
A priori, il n'y a pas de priorité pour les thread,
et donc plus tu a de thread, plus chaque thread s'execute
lentement.
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le
thread de calcul tourne, les appli système réagissent bien alors
que l'IHM réagit très lentement.
Ben, c'est à dire que les appli système sont dans des process différents
et pas des thread au sein d'un même processus.
(voir par exemple
http://www.lifl.fr/~boulet/formation/syst-dist/exposes2003-2004/threads/
pour comprendre la différence entre thread(= LWP) et processus
Il y a donc deux politiques d'ordonnecement différentes qui, en plus
dépendent de l'implémentation de l'os et de python, voire de l'ihm.
Je pense que, dans ton cas, la politique d'ordonnencement des processus
convient mieux à ce que tu désire. Je te conseille d'utiliser donc deux
processus différents, un pour ton ihm et un pour tes calculs.
Si tu veux continuer à gérer beaucoup de thread,
je te conseilles d'utiliser deux processus différents
et les faire communiquer en utilisant des librairies du genre
socket ou de popen2.
et je pense que socket et popen2 conviennent toujours pour gérer deux
processus différent.
En plus, si tu es sur linux, tu peux utiliser nice pour donner
plus ou moins de priorité à chacun de tes processus, windows ayant un
truc équivalent quand tu fait Ctrl+alt+supr -> gestion des processus.
A priori, il n'y a pas de priorité pour les thread, et donc plus tu a de thread, plus chaque thread s'execute lentement.
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
Ben, c'est à dire que les appli système sont dans des process différents
et pas des thread au sein d'un même processus. (voir par exemple http://www.lifl.fr/~boulet/formation/syst-dist/exposes2003-2004/threads/ pour comprendre la différence entre thread(= LWP) et processus Il y a donc deux politiques d'ordonnecement différentes qui, en plus dépendent de l'implémentation de l'os et de python, voire de l'ihm. Je pense que, dans ton cas, la politique d'ordonnencement des processus convient mieux à ce que tu désire. Je te conseille d'utiliser donc deux processus différents, un pour ton ihm et un pour tes calculs.
Si tu veux continuer à gérer beaucoup de thread, je te conseilles d'utiliser deux processus différents et les faire communiquer en utilisant des librairies du genre socket ou de popen2.
et je pense que socket et popen2 conviennent toujours pour gérer deux processus différent.
En plus, si tu es sur linux, tu peux utiliser nice pour donner plus ou moins de priorité à chacun de tes processus, windows ayant un truc équivalent quand tu fait Ctrl+alt+supr -> gestion des processus.
Xavier.
Xavier Combelle
Cofr wrote:
...
En fait, la plupart du temps, un seul thread tourne (plus le main thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
... Peut être que ton thread de calcul est un peu trop gourmand en CPU (va voir l'occupation CPU de ton PC), tu peux limiter l'occupation CPU en faisant respirer l'IHM, par un sleep de temps en temps dans ta boucle de calcul.
Je penses que c'est une *mauvaise* solution, car personnellement, je
préfère que mes calculs se déroulent le plus rapidement possible. faire un sleep, c'est gacher le temps CPU. C'est pour ca que je présentait la solution avec deux processus. Ceci dit, tout dépend de la valeur relative du temps de développement et celle du temps de machine. Mais comme le coût du développement en python baisse considérablement, on peut utilser le temps gagné pour faire une meilleure conception.
Xavier
PS: quand je dis gacher, c'est vraiment gacher, quand tu fait un sleep et qu'aucun autre processessus a besoin du CPU, l'os lance le programme suivant: while True: pass
le processus ultra utile que windows appelle "processus inactif du système"
Cofr wrote:
...
En fait, la plupart du temps, un seul thread tourne (plus le main
thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le
thread de calcul tourne, les appli système réagissent bien alors
que l'IHM réagit très lentement.
...
Peut être que ton thread de calcul est un peu trop gourmand
en CPU (va voir l'occupation CPU de ton PC), tu peux limiter l'occupation
CPU en faisant respirer l'IHM, par un sleep de temps
en temps dans ta boucle de calcul.
Je penses que c'est une *mauvaise* solution, car personnellement, je
préfère que mes calculs se déroulent le plus rapidement possible.
faire un sleep, c'est gacher le temps CPU.
C'est pour ca que je présentait la solution avec deux processus.
Ceci dit, tout dépend de la valeur relative du temps de développement et
celle du temps de machine.
Mais comme le coût du développement en python baisse considérablement,
on peut utilser le temps gagné pour faire une meilleure conception.
Xavier
PS: quand je dis gacher, c'est vraiment gacher, quand tu fait un sleep
et qu'aucun autre processessus a besoin du CPU, l'os lance le
programme suivant:
while True:
pass
le processus ultra utile que windows appelle "processus inactif du système"
En fait, la plupart du temps, un seul thread tourne (plus le main thread qui gère l'IHM). Ce qui est bizarre, c'est que pendant que le thread de calcul tourne, les appli système réagissent bien alors que l'IHM réagit très lentement.
... Peut être que ton thread de calcul est un peu trop gourmand en CPU (va voir l'occupation CPU de ton PC), tu peux limiter l'occupation CPU en faisant respirer l'IHM, par un sleep de temps en temps dans ta boucle de calcul.
Je penses que c'est une *mauvaise* solution, car personnellement, je
préfère que mes calculs se déroulent le plus rapidement possible. faire un sleep, c'est gacher le temps CPU. C'est pour ca que je présentait la solution avec deux processus. Ceci dit, tout dépend de la valeur relative du temps de développement et celle du temps de machine. Mais comme le coût du développement en python baisse considérablement, on peut utilser le temps gagné pour faire une meilleure conception.
Xavier
PS: quand je dis gacher, c'est vraiment gacher, quand tu fait un sleep et qu'aucun autre processessus a besoin du CPU, l'os lance le programme suivant: while True: pass
le processus ultra utile que windows appelle "processus inactif du système"
