Bof ... ça sent plus le troll qu'autre chose. Les solutions qui sont de passer par cygwin, l'api posix de windows me semblent tout sauf simple. [...]
Relis mieux le lien que j'ai posté : on parle de l'implémentation de Cygwin parce qu'il s'agit d'une des implémentations notables qui reproduit une API POSIX, et en particulier fork. Mais le post explique qu'une partie de la lenteur du fork de Cygwin vient du fait qu'ils utilisaient certains appels systèmes purement pour des raisons de compatibilité avec des OS datant du siècle dernier.
Ensuite, il existait SFU (Services For UNIX) mais qui, à ma connaissance étaient plutôt mal vus par ses utilisateurs (souvent issus du monde Linux/UNIX) car pas forcément performants ou stables (mais qui fournissait une API POSIX: Windows NT implémente une partie de l'API POSIX depuis un moment, et SFU était une bibliothèque écrite par MS qui essayait de compléter ce qui manquait). La solution de MS a été d'introduire SUA, un ensemble d'outils en ligne de commande que MS a directement porté depuis leur source UNIX, et qui utilise l'API standard de Windows (notamment : on peut utiliser Perl, les outils de ligne de commande classique GNU, etc., en ligne de commande).
Donc non, il ne s'agit pas d'un troll. Il existe bel et bien des méthodes pour ré-implémenter les appels POSIX manquants, mais comme il s'agit d'un OS différent, alors il y a un coût à cela—en particulier, la « vieille » méthode qu'utilisait Cygwin pendant longtemps pour effectuer un fork impliquait d'allouer de nouvelles pages mémoires pour effectuer des copies explicites du processus parent, ce qui avait pour conséquence de ne pas profiter du COW (dont parle barmic dans sa réponse à mon commentaire).
[processus vs. threads] Par exemple chez nous on envisage d'avoir des services qui tournent sur des PC dédiés et que l'on appelle dans python sur d'autres PC grâce à ZeroRPC. Cela n'est pas si compliqué à faire lorsque l'on s'est mis dans les contraintes du multi-process, c'est bien plus difficile si l'on part du multi-thread (enfin je pense, on ne l'a pas encore fait ...).
En règle générale, lorsqu'on conçoit un logiciel pour être multithreadé, il faut s'imposer des contraintes dès le départ, notamment sur les API qu'on développe. Dès le début on essaie d'expliquer aux nouveaux étudiants en programmation que les variables globales sont à éviter, mais c'est généralement pour des raisons liées au génie logiciel. Dans le cas de programmes multithreadés, c'est aussi une contrainte liée aux risques de conflits d'accès concurrent aux variables, qui peut engendrer des plantages (meilleur cas), comportements imprévisibles (cas déjà beaucoup plus gênant), ou même se comporter « normalement » et sembler calculer tout correctement, sauf que l'accès concurrent (non protégé) mène ensuite à un calcul faux qui n'est pas détecté tout de suite (pire cas : rien ne permet de savoir que quelque chose ne va pas car les jeux de tests ne sont pas assez poussés pour le détecter).
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. :-)
s'il faut dupliquer les flux de données important pour émuler la mémoire partagé, cela perd vraiment de l'intérêt. Mais généralement quand tu en es là, tu peux tout à fait partir sur un module cython et relacher le GIL, cela me semble bien moins compliqué que de passer toute sa base de code de python vers Go.
Ben pas forcément : dans leur cas, ils n'utilisent plus de modules écrits en C et qui utilisent l'interface Python adéquate, car ils ne peuvent pas gérer les ressources utilisées, mais en retour, ils génèrent du code Go directement en gardant le source Python, ce qui permet aux programmeurs de maintenir un programme avec un langage de haut niveau malgré tout plus simple à utiliser que Go directement. Tout dépend de l'objectif du projet donc. :-) Et surtout, s'ils ont déjà tout un tas de bibliothèques déjà écrites pour Go et qui satisfont leurs besoins, alors l'intérêt des modules C devient « mécaniquement » moins grand.
[^] # Re: L'annonce
Posté par lasher . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 5.
Relis mieux le lien que j'ai posté : on parle de l'implémentation de Cygwin parce qu'il s'agit d'une des implémentations notables qui reproduit une API POSIX, et en particulier
fork. Mais le post explique qu'une partie de la lenteur duforkde Cygwin vient du fait qu'ils utilisaient certains appels systèmes purement pour des raisons de compatibilité avec des OS datant du siècle dernier.Ensuite, il existait SFU (Services For UNIX) mais qui, à ma connaissance étaient plutôt mal vus par ses utilisateurs (souvent issus du monde Linux/UNIX) car pas forcément performants ou stables (mais qui fournissait une API POSIX: Windows NT implémente une partie de l'API POSIX depuis un moment, et SFU était une bibliothèque écrite par MS qui essayait de compléter ce qui manquait). La solution de MS a été d'introduire SUA, un ensemble d'outils en ligne de commande que MS a directement porté depuis leur source UNIX, et qui utilise l'API standard de Windows (notamment : on peut utiliser Perl, les outils de ligne de commande classique GNU, etc., en ligne de commande).
Donc non, il ne s'agit pas d'un troll. Il existe bel et bien des méthodes pour ré-implémenter les appels POSIX manquants, mais comme il s'agit d'un OS différent, alors il y a un coût à cela—en particulier, la « vieille » méthode qu'utilisait Cygwin pendant longtemps pour effectuer un fork impliquait d'allouer de nouvelles pages mémoires pour effectuer des copies explicites du processus parent, ce qui avait pour conséquence de ne pas profiter du COW (dont parle barmic dans sa réponse à mon commentaire).
En règle générale, lorsqu'on conçoit un logiciel pour être multithreadé, il faut s'imposer des contraintes dès le départ, notamment sur les API qu'on développe. Dès le début on essaie d'expliquer aux nouveaux étudiants en programmation que les variables globales sont à éviter, mais c'est généralement pour des raisons liées au génie logiciel. Dans le cas de programmes multithreadés, c'est aussi une contrainte liée aux risques de conflits d'accès concurrent aux variables, qui peut engendrer des plantages (meilleur cas), comportements imprévisibles (cas déjà beaucoup plus gênant), ou même se comporter « normalement » et sembler calculer tout correctement, sauf que l'accès concurrent (non protégé) mène ensuite à un calcul faux qui n'est pas détecté tout de suite (pire cas : rien ne permet de savoir que quelque chose ne va pas car les jeux de tests ne sont pas assez poussés pour le détecter).
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. :-)
Ben pas forcément : dans leur cas, ils n'utilisent plus de modules écrits en C et qui utilisent l'interface Python adéquate, car ils ne peuvent pas gérer les ressources utilisées, mais en retour, ils génèrent du code Go directement en gardant le source Python, ce qui permet aux programmeurs de maintenir un programme avec un langage de haut niveau malgré tout plus simple à utiliser que Go directement. Tout dépend de l'objectif du projet donc. :-) Et surtout, s'ils ont déjà tout un tas de bibliothèques déjà écrites pour Go et qui satisfont leurs besoins, alors l'intérêt des modules C devient « mécaniquement » moins grand.