Oui les méthodes pour ré-implémenter les appels POSIX ou les émuler existent mais la question est est-ce qu'un langage comme python devrait se baser là dessus ?
Je ne vois pas où est le problème. Tout dépend de tes attentes en termes d'overhead. Si tu considères que l'overhead des solutions existantes pour reproduire la fonctionnalité de fork est trop grand, alors non, bien entendu, il ne faut pas. Mais si tu considères que c'est un coût acceptable, alors oui, complètement. C'est comme l'optimisation de code : d'abord tu écris un code qui fonctionne (en pensant un minimum en amont à des solutions optimisables sans tout récrire) et ensuite tu optimises.
Pour finir sur ce sujet : l'utilisation de fork doit être vue plus comme une façon de permettre une premier port de l'interpréteur sous Windows, pas comme une façon d'avoir le truc le plus efficace. Par exemple, si tu voulais porter Python sous un OS comme VMS, tu serais bien embêté, car il n'y a pas de fork non plus, et l'appel système de création de processus ressemble plus à ce que l'ont trouve sous Windows NT / Win32 API que sous UNIX/Linux (ce qui n'est pas très étonnant, quand on considère qu'une partie des gens qui ont codé le noyau original de NT, et donc spécifié son API ont aussi bossé sur VMS).
Oui, ça aussi ça peut être vu comme un troll ! Il existe plein de domaines ou tu peux lancer des tâches indépendantes mais tu as besoin d'en lancer plein, dans ce cas un script bien fait pour lancer un job PBS et c'est parfaitement adapté !
Ben la formulation est peut-être trollifère, mais les stats, elles, sont là. Les sysadmin de plein de centres de calcul ont tout bêtement regardé la charge de leurs clusters, et réalisé que si les programmes en eux-mêmes peuvent être gourmands en mémoire, ils ne sont en grande majorité pas parallélisés du tout. On ne parle pas de lancer 4 programmes en parallèle via un script (et même là, tu n'utilises qu'un quart de ta machine au mieux pour des nœuds de calcul récents).
Je ne dis donc pas qu'il n'y a pas des domaines où lancer plusieurs programmes n'est pas logique, juste que c'est ultra-rare en moyenne sur les clusters/supercalculateurs.
Je te parle d'utiliser un programme mono-processus, mono-thread, et rien d'autre. Il y a peut-être des cas de programmes parallélisés avec MPI mais qui ne font que des communications nœud à nœud et ne cherchent pas à paralléliser dans le nœud (je ne vois pas pourquoi, mais admettons). Ça ne changerait rien au fait que ces processus ne tirent absolument pas partie du parallélisme disponible au niveau du nœud lui-même. Et comme la plupart des jobs soumis dans des calculateurs demandent généralement d'avoir un accès exclusif au nœud de calcul...
[^] # Re: L'annonce
Posté par lasher . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 2.
Je ne vois pas où est le problème. Tout dépend de tes attentes en termes d'overhead. Si tu considères que l'overhead des solutions existantes pour reproduire la fonctionnalité de
forkest trop grand, alors non, bien entendu, il ne faut pas. Mais si tu considères que c'est un coût acceptable, alors oui, complètement. C'est comme l'optimisation de code : d'abord tu écris un code qui fonctionne (en pensant un minimum en amont à des solutions optimisables sans tout récrire) et ensuite tu optimises.Pour finir sur ce sujet : l'utilisation de
forkdoit être vue plus comme une façon de permettre une premier port de l'interpréteur sous Windows, pas comme une façon d'avoir le truc le plus efficace. Par exemple, si tu voulais porter Python sous un OS comme VMS, tu serais bien embêté, car il n'y a pas de fork non plus, et l'appel système de création de processus ressemble plus à ce que l'ont trouve sous Windows NT / Win32 API que sous UNIX/Linux (ce qui n'est pas très étonnant, quand on considère qu'une partie des gens qui ont codé le noyau original de NT, et donc spécifié son API ont aussi bossé sur VMS).Ben la formulation est peut-être trollifère, mais les stats, elles, sont là. Les sysadmin de plein de centres de calcul ont tout bêtement regardé la charge de leurs clusters, et réalisé que si les programmes en eux-mêmes peuvent être gourmands en mémoire, ils ne sont en grande majorité pas parallélisés du tout. On ne parle pas de lancer 4 programmes en parallèle via un script (et même là, tu n'utilises qu'un quart de ta machine au mieux pour des nœuds de calcul récents).
Je ne dis donc pas qu'il n'y a pas des domaines où lancer plusieurs programmes n'est pas logique, juste que c'est ultra-rare en moyenne sur les clusters/supercalculateurs.
Je te parle d'utiliser un programme mono-processus, mono-thread, et rien d'autre. Il y a peut-être des cas de programmes parallélisés avec MPI mais qui ne font que des communications nœud à nœud et ne cherchent pas à paralléliser dans le nœud (je ne vois pas pourquoi, mais admettons). Ça ne changerait rien au fait que ces processus ne tirent absolument pas partie du parallélisme disponible au niveau du nœud lui-même. Et comme la plupart des jobs soumis dans des calculateurs demandent généralement d'avoir un accès exclusif au nœud de calcul...