Néanmoins l'appoche de python semble avoir été faite dans un soucis de gain de perfs si j'en crois ce qui a été écrit ailleurs dans cette discussion.
Nan de simplicité : faciliter l'utilisation de lib C sans se poser de question quand aux accès concurrent.
Du coup ils se retrouvent face à un piège : s'ils veulent ajouter le support de la concurrence sans casser l'existant, il sont obligé de mettre des locks partout par défaut (là où normalement le programmeur choisi intelligement où il faut les mettre);.. et c'est globalement 2 fois plus lent lors des tests qu'ils ont fait. Conclusion le choix de départ les conduits aujourd'hui dans une impasse : l'intérêt d'avoir plusieurs threads s'exécutant en parallèle devient de plus en plus intéressant (les machines neuves sont toutes multi-core) mais ils ne peuvent pas y passer sans casser la sémantique ou alors une lourde refonte de l'interpréteur avec un impact désastreux sur les perfs...
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Nan de simplicité : faciliter l'utilisation de lib C sans se poser de question quand aux accès concurrent.
Du coup ils se retrouvent face à un piège : s'ils veulent ajouter le support de la concurrence sans casser l'existant, il sont obligé de mettre des locks partout par défaut (là où normalement le programmeur choisi intelligement où il faut les mettre);.. et c'est globalement 2 fois plus lent lors des tests qu'ils ont fait. Conclusion le choix de départ les conduits aujourd'hui dans une impasse : l'intérêt d'avoir plusieurs threads s'exécutant en parallèle devient de plus en plus intéressant (les machines neuves sont toutes multi-core) mais ils ne peuvent pas y passer sans casser la sémantique ou alors une lourde refonte de l'interpréteur avec un impact désastreux sur les perfs...