Complètement d'accord pour dire que COW (et d'autres techniques de recyclage de pages mémoire aussi) permet de réduire une partie du problème. Après tout dépend de la nature de l'application. Si tes processus sont censés partager des données, du point de vue du modèle d'exécution, à moins de passer par des segments de mémoire partagée ou équivalent, tu vas devoir passer par des IPC de type passage de message, socket, ou pipe. À ce moment-là, COW permettra de réduire l'impact de la duplication des données et de l'allocation mémoire (il y a même de bonnes chances pour qu'au moins la partie purement « lecture seule » soit correctement unique à tous les processus dupliqués).
Cependant, par exemple dans des processus parallèles (je pense notamment à des trucs genre calcul utilisant MPI), il y a souvent des échanges de données (par exemple dans des algos itératifs qui se basent sur des représentations à base de graphes, il faut échanger les « cellules fantôme » (ghost cells) ), et en fonction du nombre, ça peut mener à de grosses sur-consommation mémoire si on passe par des processus plutôt que des threads (j'ai des exemples de collègues qui à l'époque avaient réussi à réduire l'empreinte mémoire de plusieurs giga-octets en utilisant une implémentation de MPI maison basée sur les threads plutôt que les processus).
Ensuite, je suis complètement d'accord pour dire que les exemples que je peux donner sont relativement marginaux, car ils s'inscrivent dans le cadre d'applications hautement parallèles avec un grand besoin en performance.
[^] # Re: L'annonce
Posté par lasher . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 2.
Complètement d'accord pour dire que COW (et d'autres techniques de recyclage de pages mémoire aussi) permet de réduire une partie du problème. Après tout dépend de la nature de l'application. Si tes processus sont censés partager des données, du point de vue du modèle d'exécution, à moins de passer par des segments de mémoire partagée ou équivalent, tu vas devoir passer par des IPC de type passage de message, socket, ou pipe. À ce moment-là, COW permettra de réduire l'impact de la duplication des données et de l'allocation mémoire (il y a même de bonnes chances pour qu'au moins la partie purement « lecture seule » soit correctement unique à tous les processus dupliqués).
Cependant, par exemple dans des processus parallèles (je pense notamment à des trucs genre calcul utilisant MPI), il y a souvent des échanges de données (par exemple dans des algos itératifs qui se basent sur des représentations à base de graphes, il faut échanger les « cellules fantôme » (ghost cells) ), et en fonction du nombre, ça peut mener à de grosses sur-consommation mémoire si on passe par des processus plutôt que des threads (j'ai des exemples de collègues qui à l'époque avaient réussi à réduire l'empreinte mémoire de plusieurs giga-octets en utilisant une implémentation de MPI maison basée sur les threads plutôt que les processus).
Ensuite, je suis complètement d'accord pour dire que les exemples que je peux donner sont relativement marginaux, car ils s'inscrivent dans le cadre d'applications hautement parallèles avec un grand besoin en performance.