IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

POSIX C Discussion :

Pourquoi le temps d'exécution s'augmente avec pthread ?


Sujet :

POSIX C

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mars 2011
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2011
    Messages : 20
    Points : 0
    Points
    0
    Par défaut Pourquoi le temps d'exécution s'augmente avec pthread ?
    Bonsoir à tous,

    J'ai une question concernant la programmation pthread.
    J'ai réalisé une programme qui contient un seul thread dans la fonction main().
    J'ai mesuré le temps d'exécution j'ai constaté que ce temps est augmenté de 60 % par rapport au programme original(séquentiel).
    Mais c'est pas logique ce résultat ??

    Merci.

  2. #2
    Membre éprouvé
    Homme Profil pro
    R&D imagerie 3D / prog embarquée
    Inscrit en
    Mars 2007
    Messages
    417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : R&D imagerie 3D / prog embarquée
    Secteur : Santé

    Informations forums :
    Inscription : Mars 2007
    Messages : 417
    Points : 1 247
    Points
    1 247
    Par défaut
    Salut Moktar,

    Si je comprend bien, tu as pris les code qui était exécuté depuis ton main, tu l'as mis dans un thread et c'est tout. Dans ce cas, il est tout à fait logique que ton code s'exécute plus lentement. Il faut être conscient que l'utilisation d'un thread a un cout. Lorsque tu le démarre d'abord. Mais surtout, la machine va régulièrement passer de l'exécution d'un thread a un autre, ce qui implique plusieurs accès mémoire, avec empilement/dépilement sur la stack du contexte de chaque thread et branchement du pointeur ordinal.
    Les threads deviennent intéressants lorsque plusieurs opérations peuvent ou doivent se faire en parallèle. Dans ce cas, et notamment dans un contexte multiprocesseurs, tu auras des gains performances.
    Par exemple, les algorithmes diviser pour régner s'adaptent très bien aux threads. Les problèmes producer/consumer aussi.
    Note que le cout d'exécution de tes threads ne doit pas être supérieur au gain de la parallélisation. Tes problèmes doivent donc avoir une certaine taille.

    Un exo simple et rapide pour voir le gain apporté par un thread est de créer un tableau de booléens aléatoire et de compter les "true". D'un coté, tu fais un algo itératif bête et méchant. D'un autre coté tu fais un algo avec autant de threads que ton CPU a de cores.
    Compare les performances sur un tableau de 2 millions d'éléments et sur un de seulement 4 éléments. Sur le tableau de 2 millions l'algo threadé devrait gagner et sur celui de 4 il devrait perdre.

    A+

  3. #3
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    djuju a raison : les threads coûtent car il faut passer d'un thread à l'autre, il y a le coût de démarrage des threads, etc.

    Il faut aussi être conscient que mesurer le temps d'un petit programme puis le temps d'un autre petit programme n'est pas évident, surtout si petit signifie "faible temps d'exécution". Il y a plein d'autres programmes sans doute plus prioritaire sur ton PC au même moment, qui te dit que ce n'est pas ton OS qui a laissé ton programme threadé sur le carreau pour donner la main à un autre programme qui en avait plus besoin ? Il ne faut pas se baser sur un temps de mesure mais sur un ensemble de mesures et il faut que le temps d'exécution soit suffisamment long pour que les aléas du scheduling de l'OS soit gommé.

    D'un autre coté tu fais un algo avec autant de threads que ton CPU a de cores
    En supposant que ton OS gère correctement le multicoeur, ce qui d'après une discussion au boulot l'autre jour serait rarement le cas. Ce qui disait les collègues en substance est que tu gagneras mais pas forcément autant qu'on pourrait le souhaiter / l'espérer...

  4. #4
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2008
    Messages
    1 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 515
    Points : 2 505
    Points
    2 505
    Par défaut
    Ca n'a rien à voir avec le fait que le système a à passer d'un thread à l'autre. Tu n'as qu'un thread, il n'y a donc pas de scheduling en plus.

    Par contre, le fait de te linker avec la libpthreads va compiler ton code en mode thread-safe, et de nombreuses fonctions de la librairies standard auront en plus à prendre des locks qu'elles ne prennent pas en mode threadé. La différence de perfs vient de là.

  5. #5
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Si tu crées, un thread cela en fait 2 avec le thread du main(), non ?

    Sinon, une application si simple n'est pas franchement impactée par le scheduling, ma phrase se plaçait dans un contexte plus général de multi-threading.

  6. #6
    Membre éprouvé
    Homme Profil pro
    R&D imagerie 3D / prog embarquée
    Inscrit en
    Mars 2007
    Messages
    417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : R&D imagerie 3D / prog embarquée
    Secteur : Santé

    Informations forums :
    Inscription : Mars 2007
    Messages : 417
    Points : 1 247
    Points
    1 247
    Par défaut
    Citation Envoyé par Bktero Voir le message
    En supposant que ton OS gère correctement le multicoeur, ce qui d'après une discussion au boulot l'autre jour serait rarement le cas. Ce qui disait les collègues en substance est que tu gagneras mais pas forcément autant qu'on pourrait le souhaiter / l'espérer...
    Tout à fait. Ce n'est pas parce que tu lance 4 threads sur un quad-core qu'il y en aura 1 par core. Tout d'abord, parce que tu as d'autre process qui tourne sur ta machine, ensuite parce que c'est ton OS qui décide du scheduling de chaque thread pour chaque core. Il y a des mécanismes d'affinité pour affecter un thread à un core précis, il vaut donc mieux le laisser faire.
    Anyway, le but ici n'est que de donner un exemple simple de gain de perf avec les threads. Quand on débute avec les threads, je pense qu'il vaut mieux ne pas trop entrer ces détails.

    Ca n'a rien à voir avec le fait que le système a à passer d'un thread à l'autre. Tu n'as qu'un thread, il n'y a donc pas de scheduling en plus.
    Comme l'a dit Bktero, tu as un main qui lance un thread, puis l'attend, tu as donc 2 threads. Il faudra bien scheduler entre les 2 pour vérifier si la condition d'attente du main (un mutex ou autre objet de synchro) est remplie et donc s'il faut réveiller le main thread.

    Par contre, le fait de te linker avec la libpthreads va compiler ton code en mode thread-safe, et de nombreuses fonctions de la librairies standard auront en plus à prendre des locks qu'elles ne prennent pas en mode threadé. La différence de perfs vient de là.
    Effectivement, c'est tout à fait possible ça vienne de là. Mais, vu qu'on a pas le code, on fait tous des plans sur la comète depuis le début. Je sais bien que ces mesures ne sont pas précises, mais Moktar à 60% de différence entre ces versions de code. Pour avoir 60%, cela me donne l'impression que le temps d'exécution de son thread est très petit et que donc l'overhead vient de l'utilisation des threads. J'ai l'impression que si c'était la synchro du mode htread-safe qui ralentissait le code, l'overhead serait moins important.
    Anyway, que l'overhead vienne du cout des threads, du mode thread-safe ou des 2, tu fais bien de soulever cet aspect, car c'est un point important => Compiler thread-safe a un cout.

  7. #7
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par djuju Voir le message
    Comme l'a dit Bktero, tu as un main qui lance un thread, puis l'attend, tu as donc 2 threads. Il faudra bien scheduler entre les 2 pour vérifier si la condition d'attente du main (un mutex ou autre objet de synchro) est remplie et donc s'il faut réveiller le main thread.
    Non tu n'as pas de scheduling entre le main et le thread tant que le thread ne rend pas la main (pthread_exit) si le thread a été créé en mode attaché (en mode détaché on aura par contre le thread qui s'exécute en parallèle du main qui poursuit son traitement).
    Le premier changement de contexte se ferra donc uniquement lors du pthread_exit.
    C'est le principe de l'utilisation des signaux dans un OS. Sinon on n'utiliserai pas de signaux mais un simple flag qu'on vérifierai à chaque ordonnancement.

    Pour moi ce temps vient de l'aspect thread-safe. Cela rajoute un bon nombre de delta non négligeables sur un bon nombre de fonctions. Et donc ce 60% ne me paraît pas bizarre.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  8. #8
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2008
    Messages
    1 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 515
    Points : 2 505
    Points
    2 505
    Par défaut
    Ah non ça c'est totalement faux par contre. Que le deuxième thread soit créé en mode attaché ou détaché ne change rien au scheduling ; dans tous les cas les deux threads s’exécutent en parallèle. La différence concerne seulement la terminaison du threads.

  9. #9
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par matafan Voir le message
    Par contre, le fait de te linker avec la libpthreads va compiler ton code en mode thread-safe, et de nombreuses fonctions de la librairies standard auront en plus à prendre des locks qu'elles ne prennent pas en mode threadé. La différence de perfs vient de là.
    C'est vrai mais de là à faire 60 % de différence, il y a quand même une certaine distance à franchir. Donc soit l'ensemble analysé est trop restreint pour que les mesures soient pertinentes (s'il fait une boucle sur trois éléments, c'est assurément le coût de création du thread qui sera de loin le plus élevé :-) ), soit il y a des effets de bord comme des barrières de synchro mal placées et/ou injustifiées.

    Donc, sans voir le code, on ne pourra pas tirer de conclusions pertinentes…

  10. #10
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par matafan Voir le message
    Ah non ça c'est totalement faux par contre. Que le deuxième thread soit créé en mode attaché ou détaché ne change rien au scheduling ; dans tous les cas les deux threads s’exécutent en parallèle. La différence concerne seulement la terminaison du threads.
    Si le thread est en mode attaché le main est donc en état d'endormissement.
    Il n'est réveillé que sur réception de certains signaux en provenance de son thread lancé ou d'un process extérieur (chose assez rare sauf si vous l'avez explicitement programmé).
    On peut donc simplifier en disant que le main ne sera absolument pas ordonnancé (il restera endormi) jusqu'à l'envoi du signal par le thread lors du pthread_exit.

    A contrario avec un thread lancé en mode détaché, le main n'est pas endormi et donc poursuit son exécution. On a donc un ordonnancement de cette tâche.

    Et si on veut être pointilleux je devrai vous reprocher le fait d'appeler un main un thread car ce n'est absolument pas la même chose suivant l'OS.
    Sur certains OS le main sera identifié par l'id de process, tandis que sur d'autres OS il sera aussi identifié par un id de thread. Et on retrouve aussi d'autres OS qui fonctionnent par tâche et non par process/thread à l'ordonnancement.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  11. #11
    Nouveau Candidat au Club
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mars 2011
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2011
    Messages : 20
    Points : 0
    Points
    0
    Par défaut
    Bonsoir à tous,

    Merci pour vos réponse.
    Je travaille sur le code d'un codeur H.264, il est très long, ce pourquoi je l'ai pas postulé. Ci-joint une figure qui explique le programme séquentiel et parallèle. Donc c'est que j'ai fait ce de créer un thread "Encode_chroma_MB" qui sera traité en parallèle avec la fonction main(), alors j'ai un processus qui est la fonction main() et un thread.
    Le problème est que le temps d'exécution augmente avec plus de 60%.
    Donc j'ai essayé de faire un teste,calculer seulement le temps d'exécution de thread. J'ai trouvé que le temps augmente même si le corps de thread est vide, c'est dire aucune instructions exécutés dans le thread. C'est bizarre ,non ??
    C'est à dire lorsque je mets pthread_create () dans mon programme cela me coute presque 78 ms !!!!!

    Merci,
    Moktar.
    Images attachées Images attachées  

  12. #12
    Membre éprouvé
    Homme Profil pro
    R&D imagerie 3D / prog embarquée
    Inscrit en
    Mars 2007
    Messages
    417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : R&D imagerie 3D / prog embarquée
    Secteur : Santé

    Informations forums :
    Inscription : Mars 2007
    Messages : 417
    Points : 1 247
    Points
    1 247
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Si le thread est en mode attaché le main est donc en état d'endormissement.
    Il n'est réveillé que sur réception de certains signaux en provenance de son thread lancé ou d'un process extérieur (chose assez rare sauf si vous l'avez explicitement programmé).
    On peut donc simplifier en disant que le main ne sera absolument pas ordonnancé (il restera endormi) jusqu'à l'envoi du signal par le thread lors du pthread_exit.

    A contrario avec un thread lancé en mode détaché, le main n'est pas endormi et donc poursuit son exécution. On a donc un ordonnancement de cette tâche.

    Et si on veut être pointilleux je devrai vous reprocher le fait d'appeler un main un thread car ce n'est absolument pas la même chose suivant l'OS.
    Sur certains OS le main sera identifié par l'id de process, tandis que sur d'autres OS il sera aussi identifié par un id de thread. Et on retrouve aussi d'autres OS qui fonctionnent par tâche et non par process/thread à l'ordonnancement.
    Ca fait un moment que je n'ai plus fait de pthread, mais si mes souvenirs sont bons, il y a le mode dettached et joinable. J’imagine que c'est ce que tu veux dire par mode attaché/détaché. Encore une fois, si mes souvenirs sont bons, la seule différence est qu'en mode joinable, lorsque le thread termine, le contexte du thread n'est pas libéré pour que tu puisse faire ton pthread_join(). Si tu es en mode dettached, le contexte est libéré tout seul, puisqu'il n'y aura pas d'appel à pthread_join().

    Par ailleurs, un thread endormi, que ce soit sur un wait, un lock, un join, un sleep ou autre sera quand même schedulé. Lorsqu'un thread "s’endort", il est sortie de sa queue de priorité sur du scheduler pour être mis dans la queue des threads endormis. Régulièrement, le schéduler va parcourir cette queue pour vérifier si certain ne sont pas signalés ou tombés en timeout. Si c'est le cas, le thread est sorti de la queue "dormante" pour être remis dans sa queue de priorité. Donc, même si l'overhead d'une telle attente est foncièrement inférieur qu'une attente active, il y a quand même scheduling.

  13. #13
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Non tu n'as pas de scheduling entre le main et le thread tant que le thread ne rend pas la main (pthread_exit) si le thread a été créé en mode attaché (en mode détaché on aura par contre le thread qui s'exécute en parallèle du main qui poursuit son traitement).
    Le premier changement de contexte se ferra donc uniquement lors du pthread_exit.
    Je ne suis pas un spécialiste des pthreads en particulier mais en raisonnant d'un point de vue général, il y a quelque chose de faux dans ton raisonnement. Si dans la fonction main(), tu crées un thread, que le main() s'endort puis que le thread s'exécute, il y a une changement de contexte pour entrer dans ce thread. Avec le changement de contexte pour terminer le thread, tu as donc 2 changements de contexte.

    Ensuite, pas de changement de contexte ne signifie pas forcément pas de temps utilisé par le scheduler pour voir s'il y a un changement de contexte à faire et ne pas le faire parce que le thread courant est toujours celui à exécuter.

    Et tout cela en ne raisonnant que sur les 2 threads du programme comme s'ils étaient seuls.

  14. #14
    Nouveau Candidat au Club
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mars 2011
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2011
    Messages : 20
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par Bktero Voir le message
    Je ne suis pas un spécialiste des pthreads en particulier mais en raisonnant d'un point de vue général, il y a quelque chose de faux dans ton raisonnement. Si dans la fonction main(), tu crées un thread, que le main() s'endort puis que le thread s'exécute, il y a une changement de contexte pour entrer dans ce thread. Avec le changement de contexte pour terminer le thread, tu as donc 2 changements de contexte.
    Quand même, 2 changements de contexte ne dépasse pas l'ordre de µs.
    Comme je vous dis, la création d'un thread (sans aucune instruction dedans) coute 78 ms !!

  15. #15
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    329
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Octobre 2004
    Messages : 329
    Points : 608
    Points
    608
    Par défaut
    La création d'un thread ça implique un appel système et du temps pour créer les structures pour l'OS, c'est pas "gratuit".

  16. #16
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par moktar_bouain Voir le message
    Quand même, 2 changements de contexte ne dépasse pas l'ordre de µs.
    Comme je vous dis, la création d'un thread (sans aucune instruction dedans) coute 78 ms !!
    Certes, la surcharge parait importante pour juste deux changements de contexte. Je ne répondais qu'à ce que disait transgohan sur le "un seul changement de contexte"

    Dans un contexte multi-threadé sur PC, il faut quand même être conscient que des 2 threads ne sont pas tous seuls à se battre pour un coeur de CPU. Tu as d'autres threads, c'est au final assez compliqué de suivre le flow d'exécution. Prenons un cas simple : ton programme et 3 autres threads (T1, T2, T3). Je ne vois pas ce qui empêcherait les 2 scénarios suivants (certes schématiques), d'autres intervenants diront ce qu'ils en pensent :
    1. Ton programme possède uniquement un main()
      - T1 s'exécute
      - Ton programme s'exécute et a assez de temps pour terminer son traitement
      - T2 puis T3 s'exécutent
    2. Ton programme possède un main() (Tm) et un autre thread (Ta)
      - Tm s'exécute et lance Ta
      - T1 s'exécute
      - T2 s'exécute
      - Ta s'exécute et fait tout le traitement
      - T3 s'exécute
      - Tm s'exécute et se termine

    Dans ton cas 2, tu n'as pas que le temps de changement entre tes 2 threads mais aussi le temps des éventuels threads qui s'intercalent entre les 2.

    Au passage, comment as-tu fait pour arriver à cette valeur ? C'est une moyenne ? C'est une mesure unique ?

  17. #17
    Nouveau Candidat au Club
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mars 2011
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2011
    Messages : 20
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par Joker-eph Voir le message
    La création d'un thread ça implique un appel système et du temps pour créer les structures pour l'OS, c'est pas "gratuit".
    Oui absolument Joker, j'ai dit pas que ce gratuit mais ça reste de l’ordre de µs

    Dans ton cas 2, tu n'as pas que le temps de changement entre tes 2 threads mais aussi le temps des éventuels threads qui s'intercalent entre les 2.
    J'ai protéger toute la fonction main() par un mutex, pour éviter qu'elle soit interrompu par des autres threads, mais toujours c'est le même résultat.
    Au passage, comment as-tu fait pour arriver à cette valeur ? C'est une moyenne ? C'est une mesure unique ?
    Oui Bktero, c'est une moyenne.
    Merci,
    Moktar.

  18. #18
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par moktar_bouain Voir le message
    J'ai protéger toute la fonction main() par un mutex, pour éviter qu'elle soit interrompu par des autres threads, mais toujours c'est le même résultat.
    Cela n'empêche pas ton programme d'être préempté par d'autres programmes

  19. #19
    Nouveau Candidat au Club
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mars 2011
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2011
    Messages : 20
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par Bktero Voir le message
    Cela n'empêche pas ton programme d'être préempté par d'autres programmes
    T'as une méthode pour faire ça?

  20. #20
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    329
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Octobre 2004
    Messages : 329
    Points : 608
    Points
    608
    Par défaut
    Citation Envoyé par moktar_bouain Voir le message
    Oui absolument Joker, j'ai dit pas que ce gratuit mais ça reste de l’ordre de µs
    Tu as parlé de changement de contexte, j'ai mentionné "création de thread".

    As-tu un exemple minimal qu'on puisse exécuter pour reproduire les 78ms qui paraissent très longues ?

Discussions similaires

  1. Réponses: 19
    Dernier message: 22/05/2014, 17h31
  2. Pourquoi le temps d'exécution si long sur PDI ?
    Par helene0618 dans le forum kettle/PDI
    Réponses: 7
    Dernier message: 11/03/2009, 22h49
  3. problème avec le temps d'exécution
    Par sam83 dans le forum C++Builder
    Réponses: 8
    Dernier message: 18/03/2008, 19h17
  4. Augmentation soudaine du temps d'exécution
    Par RetraitéJF dans le forum Général Java
    Réponses: 6
    Dernier message: 17/01/2007, 18h35

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo