Je travaille sur un programme à forte intensité de communication avec un groupe de personnes. Je ne suis pas particulièrement doué pour déboguer des programmes distribués, mais je suis fortement soupçonné d'envoyer trop de messages à la fois à un processus. J'ai réimplémenté le modèle d'acteur dans mpi4py. Chaque processus a une "boîte aux lettres" d'emplois et quand ils finissent avec leur boîte aux lettres, ils décident de passer en mode CHECK_FOR_UPDATES, où ils voient s'il y a de nouveaux messages qu'ils peuvent recevoir.mpi4py recv bouchon de données?
J'ai eu des problèmes avec le programme sur lequel un groupe d'étudiants et moi travaillons. Lorsque la charge devenait trop importante, elle commençait à tomber en panne, mais nous ne pouvions pas déterminer l'origine du problème car nous étions tous très mal en train de déboguer. J'ai demandé à certaines personnes de mon école s'il avait des idées et suggéré que, comme nous réimplémentons le système des acteurs, nous devrions envisager d'utiliser Akka. Un étudiant a déclaré cette année qu'il pourrait encore y avoir un problème, qu'un acteur pourrait être inondé de messages et s'écraser. I asked about it here. Le modèle de flux ne semble pas être ce que nous voulons (voir mon commentaire pour plus de détails) et j'ai depuis lors regardé le programme mpi4py comme je n'avais pas expliqué ce problème auparavant.
Dans l'implémentation C ou Fortran simple, il semble qu'il existe un count parameter for MPI_Recv. J'ai remarqué que comm.recv n'a aucun paramètre count et soupçonne que lorsqu'un processus passe en mode CHECK_FOR_UPDATES, il consomme juste une tonne de messages d'une variété de sources et de matrices. (Techniquement, je ne sais pas avec certitude, mais nous soupçonnons que cela pourrait être le cas.) Yat-il un moyen de plafonner la quantité de données comm.recv accepte?
(Note:. Je veux éviter d'utiliser comm.Recv variante car elle limite l'utilisateur à utiliser numpy tableaux)