A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2014-June/134772.html below:

[Python-Dev] Should standard library modules optimize for CPython?

[Python-Dev] Should standard library modules optimize for CPython? [Python-Dev] Should standard library modules optimize for CPython?Stefan Behnel stefan_ml at behnel.de
Wed Jun 4 21:14:54 CEST 2014
Sturla Molden, 03.06.2014 22:51:
> Stefan Behnel wrote:
>> So the
>> argument in favour is mostly a pragmatic one. If you can have 2-5x faster
>> code essentially for free, why not just go for it?
> 
> I would be easier if the GIL or Cython's use of it was redesigned. Cython
> just grabs the GIL and holds on to it until it is manually released. The
> standard lib cannot have packages that holds the GIL forever, as a Cython
> compiled module would do. Cython has to start sharing access the GIL like
> the interpreter does.

Granted. This shouldn't be all that difficult to add as a special case when
compiling .py (not .pyx) files. Properly tuning it (i.e. avoiding to inject
the GIL release-acquire cycle in the wrong spots) may take a while, but
that can be improved over time.

(It's not required in .pyx files because users should rather explicitly
write "with nogil: pass" there to manually enable thread switches in safe
and desirable places.)

Stefan


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4