Forum Programmation.shell Shell et Multi Thread

Posté par  .
Étiquettes : aucune
0
16
fév.
2008
bon, je croyais benôitement que de faire
toto | titi

me permettrait d'utiliser l'hyperthreading de ma babasse, les processus toto et titi étant séparés. Mais que nenni! Les deux processus restent affectés au même sore, n'utilisant que 50% de la puissance disponible.

Donc question, y a-t-il un moyen autre que pipe pour lancer deux processus gourmands en CPU, qui s'envoient les données, et qu'ils utilisent deux cores?

  • # erreur dans l'enoncé ?

    Posté par  . Évalué à 2.

    le pipe |
    permet de prendre la sortie de la partie de gauche,
    pour l'envoyer à l'entrée de la partie de droite

    cela ne dit nullement au systeme de mettre le premier process sur le premier processeur, et le 2e sur le 2e processeur.

    la gestion multiprocesseur se fait, soit au niveau du programme lui meme (programme multithread), soit par le scheduler de la machine qui va affecté les taches et process sur les differents processeurs.

    s"il ne voit pas de besoin special à mettre un process sur chaque proc, il n'y a pas de raison qu'il le fasse.

    • [^] # Re: erreur dans l'enoncé ?

      Posté par  . Évalué à 4.

      > s'il ne voit pas de besoin special à mettre un process sur chaque proc, il n'y a pas de raison qu'il le fasse.

      Ben justement, le besoin est là : les deux process occupent plus de 100% d'une UC, donc il pourrait profiter d'un autre CPU.

      Exemple inutile mais gourmand :

      
oggdec | oggenc | oggdec | oggenc

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: erreur dans l'enoncé ?

        Posté par  . Évalué à 0.

        ce serait pas mal de lire la réponse du monsieur qui s'en est donné la peine.

        càd: le pipe n'est pas fait pour ça.

        Alors on oublie le | et on regarde du côté du & ...

        • [^] # Re: erreur dans l'enoncé ?

          Posté par  . Évalué à 3.

          Je pense avoir lu, ce que je voulais souligner c'est que j'ai besoin de piper les données entre les deux process, avec &, comment faire?

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # possibilite

    Posté par  . Évalué à 1.

    salut,
    tu peux tout simplement lancer les "taches" a accomplir en meme temps ce qui imposera la detection par le systeme de X processus et donc ils seront repartis sur l'enssembles des processeurs disponnibles (y compris les cores ou les membres d'un cluster)

    debut de script
    toto &
    titi &
    reste du script
    control de fin de toto
    control de fin de titi
    reste du script
    fin du script

    tu peux meme utiliser nohup toto & mais attention ca rattage le processus au processus 1 et donc si le script plante ou si tu le tues volontairement ca ne tura pas le process toto !!!!

    • [^] # Re: possibilite

      Posté par  . Évalué à 2.

      Le problème est que ce sont des tâches à faire suivre (par pipe ou autre chose)

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Ca fonctionne tout seul

    Posté par  . Évalué à 4.

    Sauf besoin très spécifique, il n'y a rien à régler. L'ordonanceur du noyau s'occupe de mettre les tâches là où il y a du temps processeur disponible.

    Si ton processus 'toto' utilise 80% d'un coeur alors il est probable que ton processus 'titi' qui en utilise 50% sera exécuté sur l'autre coeur.

    Utilise tout simplement 'top' ou 'ps' pour t'en rendre compte.

    Exemple sur un double coeur :

    # cat /dev/urandom | gzip --fast | gzip --best > /dev/null

    "ps u" me donne :
    90.8% CPU cat /dev/urandom
    11.3% CPU gzip --fast
    11.7% gzip --best

    Donc ça utilise plus d'un coeur.
    L'ordonanceur ne garanti pas qu'un processus s'exécute toujours sur le même coeur. Et d'ailleurs on s'en moque franchement. Ce qui est important c'est que les processus ne soient pas bloqués par manque de temps processeur alors qu'il y en aurait de disponible.

    • [^] # Re: Ca fonctionne tout seul

      Posté par  . Évalué à 1.

      Sans oublier qu'il parle d'hypertreading et non de multicore dans son post. Il ne faut pas s'attendre à voir 100% d'utilisation cpu dans ce cas dans top. Dans le meilleur des cas, il utilisera vraiment à 100% son cpu comparer à un cpu monocore normal.

      • [^] # Re: Ca fonctionne tout seul

        Posté par  . Évalué à 2.

        Non, j'obtiens plutôt 130% avec l'HT. C'est à dire que deux oggenc simultanés sont 30% plus rapides avec l'HT.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Ca fonctionne tout seul

          Posté par  . Évalué à 1.

          Oui, mais tu n'utilise bien qu'au plus que 100% des unités arithmétiques de ton proc. Les 30% que tu gagne sont les 30% que tu perds normalement sur un processeur normal dû aux changements de contexte.

          D'ailleur les calculs lourds paralelles sont le seul moyen de vraiment utilisé l'HT.

    • [^] # Re: Ca fonctionne tout seul

      Posté par  . Évalué à 2.

      Ben j'ai pas réussi à obtenir ça :
      avec oggdec | sox | oggenc je suis coincé à

      80% oggenc
      12% oggdec
      8% sox

      C'est bizarre car si je fais oggenc &; oggdec &; j'obtiens bien 100% sur chaque...

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Ca fonctionne tout seul

        Posté par  . Évalué à 1.

        ben chez moi
        80+12+8 = 100

        donc tu as bien 100% d'usage processeur

        • [^] # Re: Ca fonctionne tout seul

          Posté par  . Évalué à 3.

          Avec 2 coeurs, tu peux arriver à 200% d'usage. En fait, top calcule les pourcentages pour un seul core.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Mea Culpa

    Posté par  . Évalué à 2.

    Bon, j'ai pu tester sur une vraie machine bi-cpu, et j'ai bien 99+8+3 % d'occupation processeur. Donc mea-culpa, j'avais oublié que l'hyper-threading n'était là que pour la pub. oggenc + sox + mpg123 utilisant les mêmes unités de calcul, ils ne bénéficient pas de l'HT.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.