Status of Python threading support (GIL removal)?

[Carl Banks]

On Jun 19, 4:42 pm, Christian Heimes <li... at cheimes.de> wrote:
> OdarR schrieb:
>
> > On 19 juin, 21:41, Carl Banks <pavlovevide... at gmail.com> wrote:
> >> He's saying that if your code involves extensions written in C that
> >> release the GIL, the C thread can run on a different core than the
> >> Python-thread at the same time.  The GIL is only required for Python
> >> code, and C code that uses the Python API.  C code that spends a big
> >> hunk of time not using any Python API (like, as Skip pointed out, a
> >> matrix multiply) can release the GIL and the thread can run on a
> >> different core at the same time.
>
> > I understand the idea, even if I don't see any examples in the
> > standard library.
> > any examples ?
>
> http://svn.python.org/view/python/trunk/Modules/posixmodule.c?revisio...
>
> Search for Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS
>
> > yes, I also speak about hard computation that could benefit with
> > multiple cores.
>
> Hard computations gain more speed from carefully crafted C or Fortran
> code that utilizes features like the L1 and L2 CPU cache, SIMD etc. or
> parallelized algorithms. If you start sharing values between multiple
> cores you have a serious problem.
>
> Oh, and use NumPy for the job ;)
>
> >> I wish people would just say, "This is a limitation of
> >> CPython.  There are reasons why it's there, and it helps some people,
> >> but unfortunately it has drawbacks for others", instead of the typical
> >> "all u hav 2 do is rite it in C LOL".
>
> > "LOL"
> > I would like to say such thing about my weather...I live in Europe in
> > a rainy country.
>
> It *is* a well known limitation of Python. All the nice 'n shiny syntax
> and features are coming with a cost. Python is a powerful language and
> good tool for lots of stuff. But Python is and will never become the
> übertool that solves every problem perfectly. At some point you need a
> different tool to get the raw power of your machine. C (and perhaps
> Fortran) are the weapons of choice for number crunching.

This is the narrowminded attitude that irritates me.

Here's the thing: not everyone complaining about the GIL is trying to
get the "raw power of their machines."  They just want to take
advantage of multiple cores so that their Python program runs
faster.

It would be rude and presumptuous to tell such a person, "Well, GIL
isn't that big of a deal because if you want speed you can always
rewrite it in C to take advantage of multiple cores".


Carl Banks