Merci pour ce journal et la librairie qui est vraiment intéressante.
En effet c'est ces détails d'implémentations qui sont complexes et qui font aussi qu'une implémentation naïve est parfois complètement inutile. De mon coté je suis déjà tombé dans les écueils suivant:
le temps de création des processus est trop long (typiquement parce qu'on fork alors que le processus principal à déjà un gros objet en mémoire). Utiliser la bonne méthode de démarrage, dont forkserver peut aider.
la communication entre les processus est plus long que le traitement ! (parcequ'on pickle des gros objets ou plein de petits objets). Là la mémoire partagée aide, mais comme tu disais, il faut gérer manuellement, donc c'est bien plus complexe.
l’implémentation de imap_unordered est en fait greedy (gloutonne) du coté de la production des tâches (le stock de tâches est créé immédiatement et non pas au fur et à mesure de la consommation) ce qui peut conduire à une explosion de la mémoire... le prefetch de SeqTools répond bien à ça.
Coté création/suppression des processus, a tu regardé (plus pour inspiration) ipyparallel ?
# Oui c'est compliqué
Posté par Alex G. . En réponse au journal SeqTools 1.0.0: la programmation concurrente, c'est dur!. Évalué à 5. Dernière modification le 31 décembre 2019 à 09:58.
Merci pour ce journal et la librairie qui est vraiment intéressante.
En effet c'est ces détails d'implémentations qui sont complexes et qui font aussi qu'une implémentation naïve est parfois complètement inutile. De mon coté je suis déjà tombé dans les écueils suivant:
Coté création/suppression des processus, a tu regardé (plus pour inspiration) ipyparallel ?