Discussion :

[Seabirds]

Il m'est déjà arrivé en 2j de travail de passer un algo de quelques heures à quelques secondes (genre en remplaçant du O(n5) par du O(n log n)). Mais tout dépend du niveau de codage de la solution actuelle. Mais je pense que ça vaut le coup d'essayer d'optimiser un minimum la solution de base avant de partir vers de la parallèlisation.

Voilà qui me rassure, tout n'est pas forcément perdu Merci de ta réponse !

Dans ton cas, tu effectues plein de simulations autonome, chacune étant ainsi construite:
initialisation de données strictement locale, dans un espace de taille N
initialisation d'une matrice N² de "fonction de transition", en gros des probabilité de transfert (partiel ou non) de contenu entre deux cases de l'espace.

Oui ça c'est le cas général . Là ça rame déjà dans un espace de 1 case sans matrice de transition ni calcul de l'état local (supposé constant) . Je soupçonne un algo d'optimisation combinatoire de bouffer pas mal de temps CPU, mais comme vous disiez : "profile & see" !
Merci encore de vos conseils !

[foetus]

Je ne suis pas pleinement d'accord avec cette histoire de couches.

Ce sont plus des couches logiques

Par exemple pour un bassin de threads :

1. Tu codes un bassin de threads
2. Il faut recoder tes tâches monothreadées en "worker threads"
3. Il faut recoder les appelants ("callers" il me semble) Dans mes développements, j'ai créé des "jobs" qui vont être passés au bassin. Ces jobs doivent être copiables (P.O.D., pas de pointeurs, mais éventuellement des handles) et contenir toutes les informations pour appeler le bon "worker thread"
4. Il faut recoder l'IHM. On peut penser qu'on va passez d'un bouton "launch [big] task" à une liste (dont chaque élément est un appelant)
5. Cela ouvre la porte à d'autres choses: traitements par lots, annulation rapide, ...

[Seabirds]

Re !
Problème dé-résolu !

J'aurais encore une question si vous permettez

Les simulations à paralléliser font intervenir beaucoup de tirages aléatoires.
Si je lance le même programme plusieurs fois au lieu d'utiliser OpenMP, il va utiliser les même nombres aléatoires. Pas cool.
Si le rng utilise une source d'entropie externe, je vais pas pouvoir reproduire exactement les résultats. Pas cool.
Si j'enregistre la seed utilisée dans les résultats, cette seed n'est pas explicitée dans le code, et je sais pas si j'ai raison ou tort mais j'aime pas trop l'idée

Si je parallélise avec OpenMP, je peux expliciter une seed, la filer au rng et le partager entre les processus mais ça a pas l'air d'être l'option la plus efficace côté vitesse d'exécution.
Si j'initialise dans chaque processus un nouveau rng avec une seed fabriquée aléatoirement par un rng externe à la parallélisation, il paraît que ça peut créer des corrélations dans mes simulations
Si je tape "concurent random number generation" sur nos moteurs de recherches adorés je tombe sur des articles comme celui-là https://www.researchgate.net/publica...sing_RngStream mais je suis un peu loin de mes compétences et ne sais pas si c'est overkill ?

Comment vous y prendriez vous pour paralléliser des tirages aléatoires massifs si on veut de la reproducibilité ?
Bien à vous !

[Bousk]

Si je lance le même programme plusieurs fois au lieu d'utiliser OpenMP, il va utiliser les même nombres aléatoires. Pas cool.
Si le rng utilise une source d'entropie externe, je vais pas pouvoir reproduire exactement les résultats. Pas cool.

Tu te plains de générer les mêmes nobmres puis que tu ne peux pas reproduire les mêmes résultats
Si tu lances le programme, qu'est-ce qui t'empêche de passer une seed en paramètre au programme ?
Même si tu paralèlises, rien n'empêche de partir d'une même seed, pour générer une seed pour chaque thread. Si tu utilises le même générateur entre les threads tu reproduiras jamais tes résultats.

[ternel]

Je n'ai pas mieux à proposer.
Il est à noter que nombre de jeux disposant d'un générateur de cartes aléatoires proposent de fournir la seed.

[Seabirds]

Merci de vos réponses !

Même si tu paralèlises, rien n'empêche de partir d'une même seed, pour générer une seed pour chaque thread

Effectivement c'était une des idées que j'avais, mais j'avais cru comprendre que cette manière de faire pouvait provoquer des corrélations malvenues entre simulations de différents threads. Mais ok je vais partir là dessus, ça me semble le plus facile à mettre en oeuvre, on verra plus tard si on me chatouille sur ce point là.

Si tu lances le programme, qu'est-ce qui t'empêche de passer une seed en paramètre au programme ?

La flemme de devoir l'enregistrer quelque part pour me souvenir que telle simulation avait été lancée avec telle graine ?