I am curious how this can effect python 3.X adoption. programmers like myself who are stuck @ 2.7 and are planning to migrate are in 2 minds now.
Either rewrite to python 3.X and still suffer the issues of GIL.
Use Grumpy and migrate to golang altogether. But all your CPython extensions might fail (not sure though ...)
Migration to golang has become a lot easier now. Even if you plan to rewrite in python3.6 you still cannot get rid of GIL. But taking this route, you might fundamentally get rid of python altogether.
Keep in mind that there is a project underway to remove the GIL (which Guido mentioned recently). It turns out that the GIL is relatively easy to remove. Work is underway to provide the performance optimizations along with the removal.
I'd much rather stick with python3, to which this project is pinned and therefore gain access to the full python ecosystem - c extensions included, than run down another rat hole which excludes c extensions and other benefits of the python language.
The first step towards developing a Gilectomy was to demonstrate that the removal of the GIL does in fact permit the app or script to take advantage of multiple cores and therefore scale.
Having demonstrated that, the next steps within the design process are to exact performance improvements.
They are not at any stage whereby one can claim a useful production ready product. Thats to be expected. The take away is that the python3 language is far from being obsoleted by implementations such as these.
I'm not for getting into a static vs dynamic runtime performance comparisons here. If a dynamic runtime implementation of python comes along that scales well across multiple cores then we've got a winner.
I am curious how this can effect python 3.X adoption. programmers like myself who are stuck @ 2.7 and are planning to migrate are in 2 minds now.
Migration to golang has become a lot easier now. Even if you plan to rewrite in python3.6 you still cannot get rid of GIL. But taking this route, you might fundamentally get rid of python altogether.
Bandung 1 points · Jan 2017
Keep in mind that there is a project underway to remove the GIL (which Guido mentioned recently). It turns out that the GIL is relatively easy to remove. Work is underway to provide the performance optimizations along with the removal.
I'd much rather stick with python3, to which this project is pinned and therefore gain access to the full python ecosystem - c extensions included, than run down another rat hole which excludes c extensions and other benefits of the python language.
ramrar 2 points · Jan 2017
Are you referring to Giltectomy project ? Last time I checked, Gilectomy did a poor job scaling to multi-core .
Bandung 1 points · Jan 2017
The first step towards developing a Gilectomy was to demonstrate that the removal of the GIL does in fact permit the app or script to take advantage of multiple cores and therefore scale.
Having demonstrated that, the next steps within the design process are to exact performance improvements.
They are not at any stage whereby one can claim a useful production ready product. Thats to be expected. The take away is that the python3 language is far from being obsoleted by implementations such as these.
I'm not for getting into a static vs dynamic runtime performance comparisons here. If a dynamic runtime implementation of python comes along that scales well across multiple cores then we've got a winner.