Status of Python threading support (GIL removal)?

[Christian Heimes]

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?revision=72882&view=markup

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.

Christian