L'article explique que leur traduction Python → Go n'utilise pas de GIL. Ça signifie qu'ils peuvent utiliser de vrais threads et pas de processus. D'un point de vue performance, c'est quelque chose d'extrêmement important, mais en fait je pense que c'est encore plus important d'un point de vue empreinte mémoire : lorsque tu crées de nouveaux processus, tu dupliques tout l'espace mémoire associé (y compris un interpréteur, par exemple...); quand tu crées des threads, l'empreinte mémoire est bien moindre, ce qui a plusieurs implications en termes de nombre de tâches concurrentes que tu peux exécuter à la fois, mais aussi lorsque le système effectue des changements de contexte, les caches sont moins mis à contribution (moins de cache thrashing) ce qui permet d'obtenir une meilleure performance.
Ils disent eux-même que la capacité à utiliser des threads est directement le résultat d'une décision de conception : interdiction d'utiliser les modules écrits en C et exécutés depuis Python. Ils se coupent donc d'une partie de l'écosystème Python pour pouvoir obtenir de bonnes performances depuis Python « pur » (mais bon, en échange, ils peuvent importer les bibliothèques Go, donc ça s'équilibre).
Sinon, concernant ton explication que Windows n'a pas d'appel à fork : c'est vrai, il n'y a pas de fork POSIX (quoique, c'est plus tout à fait vrai depuis un petit moment, vu qu'il existe une implémentation d'une partie de l'API POSIX en Windows « natif » pour Win10 depuis quelques mois déjà). Mais tu penses bien qu'ils ont un moyen de dupliquer l'espace mémoire d'un processus s'il le faut. :-) C'est juste que l'API est plus complexe. Voir ici par exemple.
[^] # Re: L'annonce
Posté par lasher . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 3.
Quelques remarques :
Sinon, concernant ton explication que Windows n'a pas d'appel à
fork: c'est vrai, il n'y a pas deforkPOSIX (quoique, c'est plus tout à fait vrai depuis un petit moment, vu qu'il existe une implémentation d'une partie de l'API POSIX en Windows « natif » pour Win10 depuis quelques mois déjà). Mais tu penses bien qu'ils ont un moyen de dupliquer l'espace mémoire d'un processus s'il le faut. :-) C'est juste que l'API est plus complexe. Voir ici par exemple.