OdarR schrieb: > On 19 juin, 21:41, Carl Banks <pavlovevide...@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 -- http://mail.python.org/mailman/listinfo/python-list
