Ils ont sacrifié le support du multithread entre autre pour "que le code reste maintenable"...
CPython a été écrit il y a 20 ans, à l'époque les ordinateurs ayant plusieurs CPU/coeurs étaient très rare. La gestion de la concurrence a été implementée à base d'un verrou global, ce qui simplifie beaucoup l'écriture de code.
Changer la manière dont CPython gère la concurrence demande à peu près de réécrire tout le code (environ 478.000 lignes de code C). Je ne sais pas si remplacer un verrou global par de plus petits verrous seraient moins coûteux en temps de dev (que de toute réécrire). Et puis des tentatives précédentes avaient montré que les performances étaient moins bonnes avec de petits verrous (sur une application n'utilisant pas de thread).
Armin travaille sur encore une autre approche utilisant de la mémoire transactionnelle. Il travaille sur PyPy mais a dit qu'il serait envisageable de faire ça sur CPython. Exemple d'articles :
[^] # Re: multithread
Posté par Victor STINNER (site web personnel) . En réponse au journal L'interpréteur de Python 3.4 sera plus interactif. Évalué à 6.
Le multithread est peut être compliqué à prendre en compte, mais absolument nécessaire pour un language qui se dit moderne.
Le GIL n'empêche pas d'avoir plusieurs threads s'exécutant simultanément :
http://www.haypocalc.com/wiki/Python#GIL
Ils ont sacrifié le support du multithread entre autre pour "que le code reste maintenable"...
CPython a été écrit il y a 20 ans, à l'époque les ordinateurs ayant plusieurs CPU/coeurs étaient très rare. La gestion de la concurrence a été implementée à base d'un verrou global, ce qui simplifie beaucoup l'écriture de code.
Changer la manière dont CPython gère la concurrence demande à peu près de réécrire tout le code (environ 478.000 lignes de code C). Je ne sais pas si remplacer un verrou global par de plus petits verrous seraient moins coûteux en temps de dev (que de toute réécrire). Et puis des tentatives précédentes avaient montré que les performances étaient moins bonnes avec de petits verrous (sur une application n'utilisant pas de thread).
Trent Nelson a proposé une approche différente :
http://python-notes.boredomandlaziness.org/en/latest/conferences/pyconus2013/20130313-language-summit.html#parallelizing-the-python-interpreter
Armin travaille sur encore une autre approche utilisant de la mémoire transactionnelle. Il travaille sur PyPy mais a dit qu'il serait envisageable de faire ça sur CPython. Exemple d'articles :
http://morepypy.blogspot.fr/2013/08/update-on-stm.html
http://morepypy.blogspot.fr/2013/06/stm-on-drawing-board.html
...