Partage
  • Partager sur Facebook
  • Partager sur Twitter

Le multiprocessing en C++

Sujet résolu
13 août 2013 à 3:02:34

Bonjour, j'ai quelque difficulté à trouver de l'information sur le multiprocessing en c++. J'ai fait plusieurs recherches sur le sujet et ne trouve pas beaucoup d'info... J'ai essayer la librairie Boost, mais je n'arrive pas à bien la configurer avec VS2010 express.
N'y à t-il pas des moyens à la porter de tous le monde pour faire ce genre de chose ?

Ceci était ma première option, ma seconde est que j'arrive à bien maitriser le multiprocessing en Python (3.x) et comptais faire des fonctions C++ et les appeler dans chaque processus python, en gros une méthode contourné, mais je bloque encore une fois! Le tutoriel sur le SDZ proposant l’appelle de fonction C++ par python n'est plus à jour pour python 3 et encore ici aussi je n'arrive pas à bien configuré VS2010...Donc connaissez-vous des tuto plus d'actualité pour faire ceci?

Cela dit, je me tourne vers le multiprocessing, car j'ai beaucoup de calcul à effectuer. Sachant que je vais tout de même etre limité par le nombre de coeur que mon processeur possède (i7-3770 8 coeurs logiques) j'ai essayer de me tourner vers CUDA (j'ai une gtx 670). Le gros défaut c'est que je ne trouve pas un bon tuto simple, et un autre problème c'est que je ne peux pas travailler avec des strings (et leurs méthode) et bien d'autres objets utile dans mes calculs, peutêtre que je me trombe quand je dis ceci, mais je n'y arrive pas !

Voilà un peu mon problème, je suis prit devant un mur pour toutes mes options :(

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 8:12:49

Des strings dans du gros calcul ? c'est quoi comme traitement ?
  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 13:37:41

Plusieurs options...

C++ 11 => thread

Sinon => pthread

Les deux sont relativement facile a utiliser... La difficulté avec les thread n'est pas de les lancer, mais d’éviter qu'il n’accèdent a des ressources partagées en meme temps ou ne se bloque les uns les autres... Et pour ca, seul toi peut faire quelque-chose

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 13:52:58

Sinon, même si c'est très moche ce que tu veux faire, pour coupler Python et C++ la solution qui semble faire consensus en ce moment est Cython qui, en gros, est du Python auquel on ajoute des mots clés pour s'interfacer avec du C/C++ et qu'on compile ensuite en natif. Et ce fichier reste compatible avec Python, comme un module classique C'est fait pour faire la glue entre du Python et du C/C++ mais en écrivant des truc dans un simili-Python. Il est de plus en plus utilisé aussi par la communauté pour accélérer certains traitements Python car avec peu de modifs tu peux transformer un module Python interprété en un module compilé qui suffit largement bien souvent.

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 19:03:51

Lord Casque Noir a écrit:

Des strings dans du gros calcul ? c'est quoi comme traitement ?

J'ai énormément de recherche à effectuer, de "déplacement" dans la string et quelque autre opération... J'utilise aussi quelque containeur comme des map(et pair inévitablement), deque et un ou deux autres il me semble. Je me suis seulement attarder au string pour le moment, car il sagit du plus gros problème.. Mais je ne crois pas que je peux aller dans la direction de CUDA pour ceci malheureusement....

Elried a écrit:

Plusieurs options...

C++ 11 => thread

Sinon => pthread

Les deux sont relativement facile a utiliser... La difficulté avec les thread n'est pas de les lancer, mais d’éviter qu'il n’accèdent a des ressources partagées en meme temps ou ne se bloque les uns les autres... Et pour ca, seul toi peut faire quelque-chose

J'ai bien préciser Multiprocess et non du Multithread, je ne veux pas faire des threads, mais des process, car ceci ne changerais pas les performances.

kristofjé a écrit:

Sinon, même si c'est très moche ce que tu veux faire, pour coupler Python et C++ ...


Oui effectivement c'est moche, mais c'était la seul solution que j'avais trouver :p ... Je vais rechercher pour Cython merci.





  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 19:11:00

WoofWoofDude a écrit:

J'ai bien préciser Multiprocess et non du Multithread, je ne veux pas faire des threads, mais des process, car ceci ne changerais pas les performances.

Oups... Mea culpa... Dans ce cas fork et pipe devrait t'etre utilie si tu reste en C++ (bon ok c'est du C mais bon, me semble que ca reste valide). Par contre,  je vois pas en quoi des process changeraient les perf et les threads non... Tu pourrais m'expliquer?

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 19:14:41

J'ai bien préciser Multiprocess et non du Multithread, je ne veux pas faire des threads, mais des process, car ceci ne changerais pas les performances.

Pourquoi les thread ne changeraient pas tes perfs ? Ce serait le cas pourtant.

Si tu fais référence à ton expérience sur Python, sache que c'est un cas particulier. Un problème interne à Python, le global interpreter lock (GIL pour les intimes) fait qu'un script avec plusieurs thread se retrouve obligatoirement coincé sur le même coeur d'un processeur. D'où la non augmentation de perf. Mais dans les langages compilés les thread vont se retrouver chargés sur chacun des noyaux, les perfs seront meilleurs.

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 19:26:17

kristofjé a écrit:

Si tu fais référence à ton expérience sur Python, sache que c'est un cas particulier. Un problème interne à Python, le global interpreter lock (GIL pour les intimes) fait qu'un script avec plusieurs thread se retrouve obligatoirement coincé sur le même coeur d'un processeur. D'où la non augmentation de perf. Mais dans les langages compilés les thread vont se retrouver chargés sur chacun des noyaux, les perfs seront meilleurs.

Ah.... C'était pour cette raison! Bon dans ce cas, je vais peut-être aller vers les threads ne me complicant pas la tête à aprendre comment utiliser Cython, ce sera donc probablement moins compliquer... Je suis sur VS 2010, est-il possible de faire du c++ 11 comme dit plus haut ? Probablement, dans ce cas comment ? (est-ce fais par défaut ?) Et lorsque Elried à dit "C++ 11 => thread" il s'agit probablement d'une librairie externe ?

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 19:43:21

non justement ça a été ajouté à la lib standard... Apres je ne sais pas pour VS2010

  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 19:48:22

En plus je suis sous version express, donc encore moins de chance que ça marche... JE vais peut-etre aller vers VS 2012, c'est simplement que à l'école les ordinateur son sous VS 2010 donc ça mon gonflais de ne pas avoir une bonne compatibilité...

Pourrais tu me donner un bon tuto sur le module thread ?
  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 20:58:12

Une autre question, j'ai environ 500 thread à exécuter... j'imagine que mon proc va galéré un peu ... Est-ce que je suis mieux de n'effectuer que 8 thread à la fois vu que je possède que 8 coeur logique ?
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
13 août 2013 à 23:00:30

C'est l'ordonanceur de ton OS qui va prendre le relais.
Il y a un point critique à ne pas dépasser qui se situe grosso-modo à 2 fois le nombre de thread disponible physiquement. Au delà, les perf dégringolent. Ce n'est donc pas une bonne idée de manière générale.
Si ce n'est que de l'envoie de message, c'est peut être moins gênant mais je doute que ce soit le cas.
  • Partager sur Facebook
  • Partager sur Twitter
13 août 2013 à 23:45:24

non, il s'agit de calcul assez lourd, je crois que je vais limiter le nombre à 8 et faire quelques test progressif...

Par contre je n'arrive pas à faire de .join() sur mes threads, une exception se lève:

Unhandled exception at at 0x74E64B32 in Projet1.exe: Microsoft C++ exception: std::system_error at memory location 0x00ECF7C8.

Que j'essaye avec 2-3 ou 8 thread, il me sort cette exception après quelque .join() (genre le 3 ou 4iem) et c'est sur la ligne des thread.join()... Est-ce que c'est parce qu'il y aurait une collision en accédante à une variable ? Car je stock les résultat des calculs de chaque thread dans une Map pour qu'il se classe par eux même (Map<th_id, data>) et donc chaque thread à cette map et lui envoi ses infos..

Edit:

Mon problème venais d'ici --'
for(int i_th=0; i<NUMBER_TH; i++)
la variable i est déja utiliser dans une autre boucle, ce que générais 2 problème :p ... dsl

-
Edité par WoofWoofDude 13 août 2013 à 23:58:23

  • Partager sur Facebook
  • Partager sur Twitter
14 août 2013 à 3:19:40

salut

> N'y à t-il pas des moyens à la porter de tous le monde pour faire ce genre de chose ?

Non. Il y a des "choses" pour faciliter la vie (OpenMP, C++ thread, Boost thread...), mais ça choisira pas les structures de données ou les algos pour toi, ne pourras pas détecter les race conditions pour toi, etc.

> Le gros défaut c'est que je ne trouve pas un bon tuto simple

il n'y a pas de tuto "simple" là dessus. Tu as déjà les problèmes de concurrence du multithreading + des problèmes spécifiques au GPU. Tu peux faire des string en cuda (c'est des tableaux de char, rien de compliqué), mais il n'y a rien de prévu dans le langage. Il faudra recoder les fonctions str, mais c'est pas complexe. Par contre, le problème (je suppose) est que tu as un gros volume de chaînes dans lesquelles tu fais tes recherches. Et donc le transfert des données va moisir tes performances, c'est probable que la version CPU soit plus rapide

En plus je suis sous version express, donc encore moins de chance que ça marche...

Express et normal, c'est le même compilateur. Ce qui change, c'est les fonctionnalités de l'IDE

Par contre, pas de threads C++11 dans MSVC 2010

Une autre question, j'ai environ 500 thread à exécuter... j'imagine que mon proc va galéré un peu ... Est-ce que je suis mieux de n'effectuer que 8 thread à la fois vu que je possède que 8 coeur logique ?

Un thread, c'est lourd à créer. Et le proc ne peut en exécuter que deux à la fois par core avec l'hyperthreading, donc 8 dans ton cas (on créer en général +1 pour avoir un de prêt). Si tu en crées 500, tu as auras toujours que 8 qui bossent et 492 qui attendent (et le processeur passera du temps à les créer)

Il faut faire un pool de threads, quand un thread à fini de bosser, il passe à la tache suivante

Par contre je n'arrive pas à faire de .join() sur mes threads, une exception se lève:

J'entend les gros sabots des problèmes arriver... et les perfs vont être moisies

Sans protection de l'accès concurrent, ta map va faire n'importe quoi. Avec protection des accès concurrent, tu vas perdre (probablement) tes perfs

Avant de faire n'importe quoi, à lire : http://www.amazon.fr/dp/1933988770

-
Edité par gbdivers 14 août 2013 à 3:24:54

  • Partager sur Facebook
  • Partager sur Twitter
14 août 2013 à 3:50:05

J'ai chercher un peu pour openMP, mais c'est trop complexe pour ce que je voulais faire...Je me suis tourner vers CUDA, et en est venu effectivement à la conclusion que je devais tout recoder moi-meme les fonctions pour les string et comme j'utilisais des Map et des Deque... J'ai abandonner le projet :p

Je ne parlais pas vraiment du compilateur, mais des fonctionnalité que Expresse me permet de faire et je suis passé à la version VS 2012 donc plus de soucis, j'utilise le module thread de la STL.

J'ai laisser le nombre à 8 thread effectivement.. Et ma façon de contrôler le nombre de thread est plutôt faite à la "vavite" et ne permet pas d'avoir 1 thread de plus en attente, mais ce n'est pas vraiment nécessaire...

Je n'ai plus l’exception dit plus haut, il s’agissait d'une erreurs de débutant que j'ai expliquer par la suite.. Et tous fonction très bien, ma Map n'a aucun problème et se remplis très bien! :)

Merci, mais je crois que tous est régler !!

  • Partager sur Facebook
  • Partager sur Twitter
26 août 2024 à 17:08:31

bonjour,

il y a TBB (Threading Building Blocks) ou Boost en C++

Cordialement

  • Partager sur Facebook
  • Partager sur Twitter
26 août 2024 à 17:42:44

Bonjour,

Déterrage

Citation des règles générales du forum :

Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.

Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre.
En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.

Au lieu de déterrer un sujet il est préférable :

  • soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
  • soit de créer un nouveau sujet décrivant votre propre contexte
  • ne pas répondre à un déterrage et le signaler à la modération

Liens conseillés

  • Partager sur Facebook
  • Partager sur Twitter