On Jun 19, 11:08 am, OdarR <olivier.da...@gmail.com> wrote: > On 19 juin, 19:13, s...@pobox.com wrote: > > > Olivier> what do you mean ? > > > Olivier> Cpython can't benefit from multi-core without multiple > > Olivier> processes. > > > It can, precisely as Martin indicated. Only one thread at a time can hold > > the GIL. That doesn't mean that multiple threads can't execute. Suppose > > I don't say multiple threads can't execute....(?). > I say that with the Python library, I don't see (yet) benefit with > multiple threads *on* multiple CPU/core.
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 always found to be a *terribly* weak rationalization. The fact is, few Python developers can take much advantage of this. (Note: I'm not talking about releasing the GIL for I/O operations, it's not the same thing. I'm talking about the ability to run computations on multiple cores at the same time, not to block in 50 threads at the same time. Multiple cores aren't going to help that much in the latter case.) I wish Pythonistas would be more willing to acknowledge the (few) drawbacks of the language (or implementation, in this case) instead of all this rationalization. It's like people here in Los Angeles who complain about overcast days. What, 330 days of sunshine not enough? Jesus. 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". Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
