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

Boost C++ Discussion :

Questions de perfomance avec boost::thread


Sujet :

Boost C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre chevronné Avatar de Rafy
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    415
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 415
    Par défaut Questions de perfomance avec boost::thread
    Je suis en train de developpez un pojet assez gros, et décide maintenant d'essayer de parallèliser certains traitements indépendants. Pour cela j'ai envie d'utiliser la libraire Thread de boost. J'ai donc procèdé à des petits programmes de test pour me mettre en jambe avec cette librairie.

    Durant la vérification des performances de ces programmes, certaines valeurs m'amènent ici. Ces questions portent sur la rapidité d'execution de la librairie boost::thread, et en particuliers sur la création des threads.

    Comme mes taches sont indépendantes, alors j'ai decidé de tester les boost::thread_group et d'un autre côté les boost::thread associés aux boost::barrier.

    Pour charger le processeur j'ai codé une fonction. c'est simplement une boucle for de 0 à 1e6.

    Mon programme de test fonctionne comme un jeu : update -> render -> display. Mon projet se situe uniquement dans l'update.
    Le comportement est identique que j'utilise des boost::thread_group ou des boost::thread et boost::barrier.
    Test 1 : dans l'update j'apelle 10 fois la fonction de charge d'affilé, multithreading désactivé, c'est 10 appels à la suite les uns des autres.
    Test 2 : dans l'update je créé 10 thread qui lancent chacun une fois la fonction de charge, j'ai ainsi la fonction qui tourne en parallèle sur 10 thread, je join avant de continuer l'execution du reste de l'update.

    Ce qui m'amène ici, sont les résultats. Je regarde le nombre de FPS, pour évaluer la vitesse de parcours de la boucle de simulation du jeu.
    Je pocède un AMD Athlon XP 2600+ (donc mono-coeur), les résultats sont étranges, le programme en ST (SingleThread)[Test 1] tourne 3 fois plus vite que l'autre.
    Sur l'ordinateur d'une autre personne Athlon XP 3200+ (je ne suis pas sur, mais on s'en fou), les résultats sont encore plus étrange car le programme ST tourne 5 fois plus vite que le MT.
    Et sur un IntelCentino tout neuf, (dualcore) alors la rapidité d'execution est identique avec le programme MT et ST.

    Mes questions sont donc les suivantes :
    Pourquoi un tel écart entre MT et ST ?
    Pourquoi sur le dualcore j'ai pas des meilleurs performances en MT qu'en ST ?
    Le temps de création des threads semble grand, existe-il une loi empirique du nombre de thread à créer en parallèles, et ou une charge nominale à faire porter sur chaque thread ?

    Merci de vos réponses constructives.

  2. #2
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Plus t'as de threads, moins ça va vite, forcément...
    Les threads te permettent d'augmenter les performances uniquement quand t'as du matériel à exploiter ou que tu peux faire un algorithme exploitant le parallelisme.

  3. #3
    Membre chevronné Avatar de Rafy
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    415
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 415
    Par défaut
    Je suis d'accord avec toi que le MT est plus lent. Mais d'un facteur 5 je trouve ça exagéré pour 10 malheureux threads.
    De plus que l'on voit bien que le multicoeur n'apporte rien...
    Ca doit venir d'autres choses.... Merci quand même.

  4. #4
    Membre émérite
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Par défaut
    mais les resultats se comptent en seconds, en minutes ou en heures ?

    en fait les dual core ont une frequence plus basse et iront moins vite pour faire une tache que les processors type pentium 4.

    cela veut dire que si tes taches sont longues a faire, tu iras plus vite sur les processors standard.

    Maintenant si tu arrives a paralleser une tache pour qu'elle s'execute sur deux cores, tu as des chances d'aller plus vite que les processors normaux, mais bon j'ai des doutes sur les betes de course.

    le dual core apporte surtout beaucoup de souplesse dans l'utilisation normale, cela apporte plus de reactivité du systeme.

    A quelle vitesse ils vont tes cores ?

    a+

  5. #5
    Membre chevronné Avatar de Rafy
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    415
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 415
    Par défaut
    j'ai écris que je regardais le nombre de FPS, comme dans un jeu. Donc les chiffres que je marques sont des fps...
    Ce que je ne comprends pas, en particuliers, c'est pourquoi le proc multicoeurs n'arrive pas à allez plus vite en MT qu'en ST.
    Je ne compare pas entre proc mais chaque proc avec le programme MT et celui en ST.
    Sinon pour info le dualcore tourne à 1.66GHz.

  6. #6
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Par défaut
    Citation Envoyé par epsilon68
    en fait les dual core ont une frequence plus basse et iront moins vite pour faire une tache que les processors type pentium 4.

    Stop, là !
    Les dual core actuels sont largement plus performant que les P4 ! Oui, les pentium dual core sont des P4 sous cadencés, mais les nouveauc, c'est une nouvelle architecture, faut pas se faire bouffer par le marketing que je ne qualifierai pas d'Intel !

    Rafy > as-tu mesuré la vitesse après la création des threads ?

  7. #7
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Qu'est-ce qu'il y a comme besoin de synchronisation entre thread?

Discussions similaires

  1. Problème lors du link avec Boost thread.
    Par Andarus dans le forum Boost
    Réponses: 1
    Dernier message: 16/02/2012, 16h43
  2. Problème de compilation/linkage avec boost::thread
    Par theanthony33 dans le forum Boost
    Réponses: 7
    Dernier message: 26/04/2010, 00h37
  3. Bug avec Boost.Threads
    Par mick009 dans le forum Boost
    Réponses: 6
    Dernier message: 19/04/2009, 16h02
  4. Problème de lib avec Boost::thread
    Par TocTocKiéLà? dans le forum Boost
    Réponses: 5
    Dernier message: 14/08/2007, 01h05
  5. [BOOST] Problème avec les threads
    Par SOAD08 dans le forum Dev-C++
    Réponses: 7
    Dernier message: 08/10/2006, 10h23

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