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 pense qu'ils ont bien fait de ne pas permettre le fork et obliger le spawn sous windows. Dans la version 3 le spawn sera le choix par défaut ! Cela va faire tomber beaucoup de code !
C'est sûr que si il y avait une implémentation native kernel windows du fork, ça serait plutôt cool.
Donc oui, utiliser un système multi-processus est plus « facile » à implémenter car tu bénéficies de l'isolation de l'espace mémoire entre les processus. En termes de performance, tout dépend vraiment de comment tu utilises ta machine. Quand on sait que ~70% des programmes lancés sur les nœuds de calcul de supercalculateurs sont mono-processus, mono-thread (et que donc ils n'utilisent pas 90% de la machine en termes de puissance de calcul), avoir une vraie conception multi-processus est déjà mieux que la moyenne, et de loin. :-)
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é !
[^] # Re: L'annonce
Posté par freejeff . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 0.
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 pense qu'ils ont bien fait de ne pas permettre le fork et obliger le spawn sous windows. Dans la version 3 le spawn sera le choix par défaut ! Cela va faire tomber beaucoup de code !
C'est sûr que si il y avait une implémentation native kernel windows du fork, ça serait plutôt cool.
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é !