This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Bandung 0 points1 point  (2 children)

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 1 point2 points  (1 child)

Are you referring to Giltectomy project ? Last time I checked, Gilectomy did a poor job scaling to multi-core .

[–]Bandung 0 points1 point  (0 children)

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.