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

Algorithmes et structures de données Discussion :

calcul parallèle et thread


Sujet :

Algorithmes et structures de données

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 14
    Par défaut calcul parallèle et thread
    bonjour

    je dois faire tourner une application assez lourde en temps calcul,
    je souhaiterais la parallèliser, mais je n'ai pas le temps pour l'instant,

    pour l'instant je me demandais comment tirer partie du fait que je dispose d'une machine biprocesseur, lorsque je lance l'application un seul CPU est utilisé, je voulais introduire plusieurs threads dans cette application pour qu'elle utilise les 2 processeurs en même temps

    j'ai fait un programme test assez simple , un programme qui crée des thread et leur fait faire un nombre "n" d'opérations, si je dis que "t" est le nombre de thread, je répartis les "n" opérations sur les t threads, chaque thread a n/t opérations à faire,

    je me disais que le temps calcul devait être plus faible lorsque l'on utilise plus d'1 thread,
    et bien c'est tout le contraire ! si je fais tourner cette application test avec un thread s'occupant des "n" opérations, le temps calcul est plus court que si je fais tourner cette application avec t thread s'occupant de n/t opérations !!!

    tout thread confondu le programme doit pourtant faire le même nombre d'opérations
    la seule chose encourageante est que avec 1 thread j'occupe 99% du processeur, et avec plusieurs thread j'occupe 199% du processeur (bi-proc)

    est-ce que vous y comprenez qqch ?
    est-ce que les thread sont automatiquement répartis sur les différents processeurs pour les bi-proc ?

    PS : mon système est linux, Debian, noyau SMP ...

  2. #2
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Par défaut
    Cette question aurait plus sa place sur le forum linux...

    Regarde du coté de la fonction "pthread_attr_setaffinity()" dans glibc (Native POSIX Threads Library - NPTL)
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 14
    Par défaut
    Citation Envoyé par pseudocode
    Cette question aurait plus sa place sur le forum linux...

    Regarde du coté de la fonction "pthread_attr_setaffinity()" dans glibc (Native POSIX Threads Library - NPTL)
    merci pour votre réponse, mais je ne trouve pas d'explications pour la fonction "pthread_attr_setaffinity()"

    j'ai repris mon programme test, en fait quel que soit le nombre de thread le temps calcul est à peu près le même, comme si les threads étaient effectués à la suite (alors que mon PC est un bi proc)

    par ailleurs j'ai remarqué que tous les threads avaient le même PID, alors qu'il est sensé être différent sur les machines GNU/linux (?)

  4. #4
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    je dirais avant de se lancer dans ce genre de répartition, il faudrait être sûr que ton code NE PEUT PAS être plus optimisé.

    Donc il faut avant tout passer par une phase d'optimisation du CODE.

    Ensuite, il peut être normal que cela soit aussi long (cela dépend du calcul, mais si ton calcul n'est pas parallélisé, tout ce que tu fais c'est éventuellement donner la possibilité de choisir un autre CPU). Et même en étant parallèle, si ce qui est parallélisé réeelement prend en tout peu de temps, et nécessite par exemple autre chose qui se trouve être dispatché sur un autre CPU, que ce soit via MPI ou autre, les temps de synchronisation peuvent annuler les gains...

    Tu peux tenter de poster le code sur le forum approprié, voir si on pourrait l'optimiser d'abord (on peut éventuellement gagner jusquà 2000 ou 8000 %)..

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 14
    Par défaut
    Citation Envoyé par souviron34
    je dirais avant de se lancer dans ce genre de répartition, il faudrait être sûr que ton code NE PEUT PAS être plus optimisé.

    Donc il faut avant tout passer par une phase d'optimisation du CODE.

    Ensuite, il peut être normal que cela soit aussi long (cela dépend du calcul, mais si ton calcul n'est pas parallélisé, tout ce que tu fais c'est éventuellement donner la possibilité de choisir un autre CPU). Et même en étant parallèle, si ce qui est parallélisé réeelement prend en tout peu de temps, et nécessite par exemple autre chose qui se trouve être dispatché sur un autre CPU, que ce soit via MPI ou autre, les temps de synchronisation peuvent annuler les gains...

    Tu peux tenter de poster le code sur le forum approprié, voir si on pourrait l'optimiser d'abord (on peut éventuellement gagner jusquà 2000 ou 8000 %)..
    bonjour

    c'est un programme test très simple qui ne nécessite pas d'optimisation, même si votre remarque est tout à fait valable, volià le code :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    #include <pthread.h>
    #include <stdio.h>
     
    /* Parameters to print_function.  */
     
    struct char_print_parms
    {
      /* The character to print.  */
      double sum;
      /* The number of times to print it.  */
      long count;
    };
     
    /* Prints a number of characters to stderr, as given by PARAMETERS,
       which is a pointer to a struct char_print_parms.  */
     
    void* char_print (void* parameters)
    {
      /* Cast the cookie pointer to the right type.  */
      struct char_print_parms* p = (struct char_print_parms*) parameters;
      int i;
     
      for (i = 1; i < p->count; i++)
          p->sum = p->sum + i;
     
      return NULL;
    }
     
    /* The main program.  */
     
    int main ()
    {
      pthread_t thread1_id;
      pthread_t thread2_id;
     
      struct char_print_parms thread1_args;
      struct char_print_parms thread2_args;
     
      thread1_args.sum = 0.0;
      thread1_args.count = 000000000;
      pthread_create (&thread1_id, NULL, &char_print, &thread1_args);
     
      thread2_args.sum = 0.0;
      thread2_args.count = 200000000;
      pthread_create (&thread2_id, NULL, &char_print, &thread2_args);
     
      pthread_join (thread1_id, NULL);
      pthread_join (thread2_id, NULL);
     
      fprintf(stderr,"%f \n",thread1_args.sum);
      fprintf(stderr,"%f \n",thread2_args.sum);
     
      /* Now we can safely return.  */
      return 0;
    }

  6. #6
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Par défaut
    Citation Envoyé par deb75
    j'ai repris mon programme test, en fait quel que soit le nombre de thread le temps calcul est à peu près le même, comme si les threads étaient effectués à la suite (alors que mon PC est un bi proc)

    par ailleurs j'ai remarqué que tous les threads avaient le même PID, alors qu'il est sensé être différent sur les machines GNU/linux (?)
    non, c'est normal. Les Threads et les Processus sont 2 choses differentes. Pour faire simple, le Processus est un container de code/data et les Threads sont les pointeurs d'execution.

    Au lancement d'un processus, L'OS "attache" ce processus a un des 2 processeurs. Par défaut, tous les threads du processus s'executeront sur ce meme processeur.

    Je me suis peut-etre trompé sur le nom de la function... pthread_setaffinity() ? sched_setaffinity() ? en tout cas, quelquechose avec "affinity"
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 14
    Par défaut
    Citation Envoyé par pseudocode
    non, c'est normal. Les Threads et les Processus sont 2 choses differentes. Pour faire simple, le Processus est un container de code/data et les Threads sont les pointeurs d'execution.

    Au lancement d'un processus, L'OS "attache" ce processus a un des 2 processeurs. Par défaut, tous les threads du processus s'executeront sur ce meme processeur.

    Je me suis peut-etre trompé sur le nom de la function... pthread_setaffinity() ? sched_setaffinity() ? en tout cas, quelquechose avec "affinity"
    si j'ai bien compris, aucune chance donc d'utiliser les deux processeurs physiques disponibles en lançant plusieurs threads, ils s'éxécuteront tous à la suite sur le même proc, pourtant j'avais lu que tout l'intérêt des thread étaitent qu'ils pouvaient être répartis sur plusieurs proc ...

  8. #8
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Par défaut
    Citation Envoyé par deb75
    si j'ai bien compris, aucune chance donc d'utiliser les deux processeurs physiques disponibles en lançant plusieurs threads, ils s'éxécuteront tous à la suite sur le même proc, pourtant j'avais lu que tout l'intérêt des thread étaitent qu'ils pouvaient être répartis sur plusieurs proc ...
    J'ai juste dit que, par défaut, tous les threads s'executent sur le mm processeur.

    Mais tu peux forcer un thread a utiliser un autre processeur avec les fonctions machin_setaffinity().

    Edit: voila, j'ai retrouvé: http://www.ibm.com/developerworks/li...-affinity.html
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 4
    Dernier message: 22/04/2008, 18h29
  2. MPI calcul parallèle
    Par Darktrouble dans le forum Bibliothèques
    Réponses: 1
    Dernier message: 17/04/2008, 14h47
  3. Calcul parallèles et multi taches !
    Par Darktrouble dans le forum Débuter
    Réponses: 1
    Dernier message: 03/03/2008, 15h29
  4. livre gestion de la mémoire + calcul parallèle
    Par salseropom dans le forum C
    Réponses: 6
    Dernier message: 08/01/2007, 17h16
  5. calcul parallèle (débutant)
    Par Mrj dans le forum MFC
    Réponses: 1
    Dernier message: 08/12/2005, 12h06

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