Je pense que je n'ai pas dû être clair. Le graph montre que le programme transcrit en go va commencer à être plus rapide si on augmente le nombre de cœur et que du coup c'est bien meilleur en go.
Le point est que les gens qui veulent des perfs en python (ce qui est bien l'objet d'un compilateur) ne vont jamais le faire en thread en python à cause du GIL. On va plutôt utiliser l'api multiprocess qui elle n'a pas ce souci. Donc comparer un Code écrit en python avec des threads avec un code d'un autre langage avec des threads révèle bien un défaut de l'implémentation de l'interpreteur C mais pas un blocage pour qui voudrait améliorer les choses car il faut suffit d'utiliser le multiprocess.
Bon dans la vrai vie, ce n'est pas aussi simple. Si le multiprocess sous linux est aussi simple à utiliser que le multithread en python, ce n'est pas vrai en windows car il n'y a pas de mécanisme de fork donc tous les paramétrages des objets sont perdus, on a un interpreteur vierge (spawn). Cela nous a valu bien des problèmes dans le portage de nos codes de linux vers multiplateforme !
La méthode par défaut dans python3 devrait être spawn ce qui rendra plus facile le multi plateforme mais demandera plus de réflexion dans l'architecture du programme ...
Bon après il reste la possibilité de rester en threads, chercher les goulots d'étranglements et de les compiler les bouts de codes avec plein de boucles et conditions avec les différents outils qui existent ...
[^] # Re: L'annonce
Posté par freejeff . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 2.
Je pense que je n'ai pas dû être clair. Le graph montre que le programme transcrit en go va commencer à être plus rapide si on augmente le nombre de cœur et que du coup c'est bien meilleur en go.
Le point est que les gens qui veulent des perfs en python (ce qui est bien l'objet d'un compilateur) ne vont jamais le faire en thread en python à cause du GIL. On va plutôt utiliser l'api multiprocess qui elle n'a pas ce souci. Donc comparer un Code écrit en python avec des threads avec un code d'un autre langage avec des threads révèle bien un défaut de l'implémentation de l'interpreteur C mais pas un blocage pour qui voudrait améliorer les choses car il faut suffit d'utiliser le multiprocess.
Bon dans la vrai vie, ce n'est pas aussi simple. Si le multiprocess sous linux est aussi simple à utiliser que le multithread en python, ce n'est pas vrai en windows car il n'y a pas de mécanisme de fork donc tous les paramétrages des objets sont perdus, on a un interpreteur vierge (spawn). Cela nous a valu bien des problèmes dans le portage de nos codes de linux vers multiplateforme !
La méthode par défaut dans python3 devrait être spawn ce qui rendra plus facile le multi plateforme mais demandera plus de réflexion dans l'architecture du programme ...
Bon après il reste la possibilité de rester en threads, chercher les goulots d'étranglements et de les compiler les bouts de codes avec plein de boucles et conditions avec les différents outils qui existent ...