mouerf...
d'aprés ce que je comprends c'est un peu chiant à gérer les threads : faut séparer les taches et synchroniser ce qui doit l'être, en faisant attention que 2 process touchent pas aux mêmes valeurs... bref... pataugeage intense pour moi la ...
en plus, du coup, dépité, j'ai réécris mon programme en c++ et ben celui en python est bien plus rapide... si si ...
avec python j'utilise les lib Image, ImageDraw, ImageColor et en cpp la lib magick++
zarbi² quoi...

si ya pas d'autres idées dans la salle, je vais simplement en rester à jouer avec mon petit python monocœur moi je crois...

Dernière modification par rep (2008-06-25 16:52:42)

oui mais c'est juste pour choisir, ou limiter (si on a plein de procs), sur quel(s) processeur(s) lancer le programme, mais pas pour répartir une tache 'monothread' sur deux cœurs...

Bonjour tout le monde!!

Je vais essayer d'être concis...

On peut utiliser le module threading de python pour créer des threads python (eux même wrappés dans des threads natifs). Malheureusement, pour faciliter la programmation, l'ami Guido a préféré mettre en place un mutex global (le GIL) garantissant l'atomicité de chacune des instructions. Ce GIL empèche les threads de s'exécuter de manière simultanée (sur deux proc/core distincts) car il doit être verrouillé pour chaque instruction python. Si vous voulez vraiment avoir du code qui tourne en parallèle, il va falloir vous passer du partage de la mémoire (utiliser plusieurs processus ou utiliser la fonction clone de linux).

Personellement, je vais vers du code en D piloté par python. De cette manière, j'ai un code multi-threadé rapide d'un coté et un langage de script puissant pour lier mes différents modules.

Dernière modification par drjnut (2008-06-26 11:24:45)

Travaillant avec Zope au taf et ayant commencé un framework réseau "à la" twisted en python, je me suis pas mal de fois posé la question du multiproc.
Pour ce qui est de zope, on lance simplement une instance (zeoclient) par proc et une base de donnée (zeoserver). Ce qui prends le plus de temps est effectué sur les zeoclients. Il ne partagent pas de mémoire et sont donc libre de tourner sur leur proc sans avoir à attendre un lock. Le zeoserver lui fédère les accès base de données et gère les conflits.
Pour ce qui est de mon framework, j'ai commencé à implémenter une couche C/D qui me permet de lancer plusieurs interpréteurs python qui partagent leur table de descripteur de fichier, mais pas la mémoire et ont donc des GILs distincts.
Je pense qu'avant tout, il faut réfléchir à la manière dont on peut répartir le calcul en minimisant les interactions et éviter de lancer trop de thread pour améliorer le débit de traitement.

J'espère que cette prose aidera quelqu'un ;-)

rep a écrit:

hé salut drjnut, content de te voir par ici!

Je l'ai appellé à la rescousse, je sais qu'il taquine du python ...

humpf j'ai toujours pas trouvé comment multithreader mon code....
j'ai sous la main "python précis et concis" qui est très bien mais trop trop concis
donc effectivement je vais peut être me laisser tenter par un de ces ouvrages imprimés, et vendus en magazin, destinés à dévaster la forêt amazoniene...

par contre j'y ai ajouté une petite interface graphique en tkinter dont je suis assez content... (c moche mais fonctionnel)

Dernière modification par rep (2008-07-10 10:36:30)