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

Threads & Processus C++ Discussion :

Liste de fichiers


Sujet :

Threads & Processus C++

  1. #1
    Membre averti
    Homme Profil pro
    Inscrit en
    Janvier 2010
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Janvier 2010
    Messages : 58
    Par défaut Liste de fichiers
    Bonjour à tous,

    Je vous explique mon soucis.
    Je travaille actuellement sur un outils de compression/decompression qui peut prendre en paramètres un liste de fichiers (*.bmp, ...).

    L'outil est fonctionnel, cependant dans le cadre d'une amélioration, j'aimerais que chaque processeur traite un fichier différent afin d'avoir un gain de temps à l'exécution. Est-ce possible? Et sur quelle piste dois-je me lancer? Thread, programmation parallère, ...?

    Merci

  2. #2
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 635
    Par défaut
    Salut, et bienvenue sur le forum.

    La question qu'il faudrait peut être se poser, c'est:
    Y a-t-il beaucoup de fichiers, ou sont-ce plutôt les traitements à appliquer à chaque fichier qui prennent du temps
    En effet, si tu as, globalement, peu de fichier à traiter mais que le traitement à effectuer est important, tu aurais sans doute à faire en sorte que les différents processeurs (ou coeurs) collaborent pour traiter un fichier à la fois.

    A l'inverse, si tu as globalement beaucoup de fichiers mais que le traitement de chaque fichier prend peu de temps, il semblera en effet opportun de faire en sorte que chaque processeur (ou coeur) effectue le traitement sur un fichier particulier.

    Le fait est que cela influera fortement sur la manière dont tu envisagera le travail en parallèle
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #3
    Membre averti
    Homme Profil pro
    Inscrit en
    Janvier 2010
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Janvier 2010
    Messages : 58
    Par défaut
    Merci pour ta réponse

    Alors pour expliquer un petit peu mieux, le traitement est assez rapide (< 1 seconde par fichier), mais la liste est assez importante ( > 100 fichiers) sans être monstrueuse. Je pense qu'il est préférable que chaque fichier soit traité par par un seul et unique processeur.

    Je suis totalement débutant sur ce sujet, j'ai essayé de me renseigner sur internet, mais je ne trouve pas grand chose, certainement parce que je ne sais pas trop par où commencer.

  4. #4
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Par défaut
    Une solution en général efficace sur un grand nombre de données demandant peu de calculs, c'est le principe de la pompe.

    En gros : un thread "pompe", sur un des coeurs, ne va faire QUE lire et mettre en buffer les données (le contenu des fichiers pour toi), et les mettre dans une FIFO dédiée.
    Un autre thread (éventuellement deux ou trois si les tests montrent que c'est efficace) ne va s'occuper QUE du traitement, remettre les données traitées dans une autre FIFO que ton thread "pompe" va lire, pour écrire les données traitées vers leur destination finale (des fichiers encore dans ton cas).

    Cela marche parce que le thread "pompe", une fois les données chargées, n'a plus rien à faire : donc, sauvegarder les données ne lui pose pas de problèmes étant donné qu'il est, justement, disponible. En cas de trop grand nombre de données, tu peux avoir à créer un autre thread "pompe" pour l'écriture.

    L'important, c'est de laisser les threads "pompe" sur un cœur dédié, qui ne sera pas utilisé par le(s) thread(s) de traitement.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

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

Discussions similaires

  1. [JSP] liste de fichiers dans une appli web
    Par cyrso dans le forum Servlets/JSP
    Réponses: 4
    Dernier message: 21/01/2005, 17h17
  2. Réponses: 7
    Dernier message: 19/09/2004, 22h01
  3. Liste de fichiers et de répertoires
    Par Freakazoid dans le forum C++
    Réponses: 4
    Dernier message: 09/08/2004, 17h16
  4. liste des fichiers d'un répertoire
    Par am dans le forum C
    Réponses: 3
    Dernier message: 04/08/2003, 17h03
  5. [Kylix] Liste des fichiers d'un répertoire
    Par Houben Jacques dans le forum EDI
    Réponses: 3
    Dernier message: 30/11/2002, 21h14

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