Status of Python threading support (GIL removal)?

11 views
Skip to first unread message

Jure Erznožnik

unread,
Jun 19, 2009, 5:52:55 AM6/19/09
to
See here for introduction:
http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91

Digging through my problem, I discovered Python isn't exactly thread
safe and to solve the issue, there's this Global Interpreter Lock
(GIL) in place.
Effectively, this causes the interpreter to utilize one core when
threading is not used and .95 of a core when threading is utilized.

Is there any work in progess on core Python modules that will
permanently resolve this issue?
Is there any other way to work around the issue aside from forking new
processes or using something else?

Ben Charrow

unread,
Jun 19, 2009, 9:53:08 AM6/19/09
to Jure Erznožnik, pytho...@python.org

There is a group of people working on an alternative implementation to Python
that, among other things, will not have a GIL:
http://code.google.com/p/unladen-swallow/

There was even a successful attempt to remove the GIL from CPython, but it
caused single threaded python code to be much slower. See more here:
http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock

Cheers,
Ben

Martin von Loewis

unread,
Jun 19, 2009, 10:16:31 AM6/19/09
to
> Digging through my problem, I discovered Python isn't exactly thread
> safe and to solve the issue, there's this Global Interpreter Lock
> (GIL) in place.

It's the opposite: Python is exactly thread safe precisely because it
has the GIL in place.

> Is there any other way to work around the issue aside from forking new
> processes or using something else?

If you know that your (C) code is thread safe on its own, you can
release the GIL around long-running algorithms, thus using as many
CPUs as you have available, in a single process.

Regards,
Martin

Martin von Loewis

unread,
Jun 19, 2009, 10:16:18 AM6/19/09
to Jure Erznožnik
> Digging through my problem, I discovered Python isn't exactly thread
> safe and to solve the issue, there's this Global Interpreter Lock
> (GIL) in place.

It's the opposite: Python is exactly thread safe precisely because it


has the GIL in place.

> Is there any other way to work around the issue aside from forking new


> processes or using something else?

If you know that your (C) code is thread safe on its own, you can

OdarR

unread,
Jun 19, 2009, 10:40:05 AM6/19/09
to
On 19 juin, 11:52, Jure Erznožnik <jure.erznoz...@gmail.com> wrote:
> See here for introduction:http://groups.google.si/group/comp.lang.python/browse_thread/thread/3...

>
> Digging through my problem, I discovered Python isn't exactly thread
> safe and to solve the issue, there's this Global Interpreter Lock
> (GIL) in place.
> Effectively, this causes the interpreter to utilize one core when
> threading is not used and .95 of a core when threading is utilized.
>
> Is there any work in progess on core Python modules that will
> permanently resolve this issue?
> Is there any other way to work around the issue aside from forking new
> processes or using something else?

hi,

please read this carefully,
<http://www.ibm.com/developerworks/aix/library/au-multiprocessing/
index.html?ca=dgr-lnxw07Python-
Multi&S_TACT=105AGX59&S_CMP=grsitelnxw07>

there is a solution for Python on multi-core : multiprocessing api.
Really nice.
<http://docs.python.org/library/functions.html>
Keep real threads for common tasks like network stuff for example.

I recently complained too :-)
<http://groups.google.com/group/comp.lang.python/browse_frm/thread/
dbe0836d9602f322#>


Olivier

Stefan Behnel

unread,
Jun 19, 2009, 11:54:32 AM6/19/09
to
Jure Erznožnik wrote:
> See here for introduction:
> http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91
>
> Digging through my problem, I discovered Python isn't exactly thread
> safe and to solve the issue, there's this Global Interpreter Lock
> (GIL) in place.
> Effectively, this causes the interpreter to utilize one core when
> threading is not used and .95 of a core when threading is utilized.

You might want to read about "The Problem with Threads":

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

and then decide to switch to an appropriate concurrency model for your use
case.

Stefan

Terry Reedy

unread,
Jun 19, 2009, 12:15:02 PM6/19/09
to pytho...@python.org
Jure Erznožnik wrote:
> See here for introduction:
> http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91
>
> Digging through my problem, I discovered Python isn't exactly thread
> safe and to solve the issue, there's this Global Interpreter Lock
> (GIL) in place.
> Effectively, this causes the interpreter to utilize one core when
> threading is not used and .95 of a core when threading is utilized.

Python does not have (or not have) GIL.
It is an implementation issue.
CPython uses it, to good effect.

> Is there any work in progess on core Python modules that will
> permanently resolve this issue?
> Is there any other way to work around the issue aside from forking new
> processes or using something else?

Use one of the other implementations.
Jython, IronPython, Pypy, ???

OdarR

unread,
Jun 19, 2009, 12:50:43 PM6/19/09
to
On 19 juin, 16:16, Martin von Loewis <martin.vonloe...@hpi.uni-:

> If you know that your (C) code is thread safe on its own, you can
> release the GIL around long-running algorithms, thus using as many
> CPUs as you have available, in a single process.

what do you mean ?

Cpython can't benefit from multi-core without multiple processes.

Olivier

sk...@pobox.com

unread,
Jun 19, 2009, 1:13:12 PM6/19/09
to OdarR, pytho...@python.org

>> If you know that your (C) code is thread safe on its own, you can
>> release the GIL around long-running algorithms, thus using as many
>> CPUs as you have available, in a single process.

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
you have two threads, one of which winds up executing some bit of C code
which doesn't mess with the Python run-time at all (say, a matrix multiply).
Before launching into the matrix multiply, the extension module releases the
GIL then performs the multiply. With the GIL released another thread can
acquire it. Once the multiply finishes the first thread needs to reacquire
the GIL before executing any calls into the Python runtime or returning.

--
Skip Montanaro - sk...@pobox.com - http://www.smontanaro.net/
when i wake up with a heart rate below 40, i head right for the espresso
machine. -- chaos @ forums.usms.org

OdarR

unread,
Jun 19, 2009, 2:08:31 PM6/19/09
to
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.

Ever seen this recent video/presentation ? :
http://blip.tv/file/2232410
http://www.dabeaz.com/python/GIL.pdf

> you have two threads, one of which winds up executing some bit of C code
> which doesn't mess with the Python run-time at all (say, a matrix multiply).

I don't know how to do that with common Python operations...
Only one thread will be really running at a time in memory (meanwhile
other thread are waiting).
Are you refering to a specialized code ?

> Before launching into the matrix multiply, the extension module releases the
> GIL then performs the multiply.  With the GIL released another thread can
> acquire it.  Once the multiply finishes the first thread needs to reacquire
> the GIL before executing any calls into the Python runtime or returning.

I don't see such improvement in the Python library, or maybe you can
indicate us some meaningfull example...?

I currently only use CPython, with PIL, Reportlab...etc.
I don't see improvement on a Core2duo CPU and Python. How to proceed
(following what you wrote) ?

A contrario, I saw *real* improvement on parallel computing with the
Py 2.6 multiprocessing module.

Olivier

Christian Heimes

unread,
Jun 19, 2009, 3:05:51 PM6/19/09
to pytho...@python.org
OdarR wrote:
> I don't see such improvement in the Python library, or maybe you can
> indicate us some meaningfull example...?
>
> I currently only use CPython, with PIL, Reportlab...etc.
> I don't see improvement on a Core2duo CPU and Python. How to proceed
> (following what you wrote) ?

I've seen a single Python process using the full capacity of up to 8
CPUs. The application is making heavy use of lxml for large XSL
transformations, a database adapter and my own image processing library
based upon FreeImage.

Of course both lxml and my library are written with the GIL in mind.
They release the GIL around every call to C libraries that don't touch
Python objects. PIL releases the lock around ops as well (although it
took me a while to figure it out because PIL uses its own API instead of
the standard macros). reportlab has some optional C libraries that
increase the speed, too. Are you using them?

By the way threads are evil
(http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) and
not *the* answer to concurrency.

Christian

Carl Banks

unread,
Jun 19, 2009, 3:08:55 PM6/19/09
to
On Jun 19, 6:53 am, Ben Charrow <bchar...@csail.mit.edu> wrote:

> Jure Erznožnik wrote:
> > See here for introduction:
> >http://groups.google.si/group/comp.lang.python/browse_thread/thread/3...

>
> > Digging through my problem, I discovered Python isn't exactly thread
> > safe and to solve the issue, there's this Global Interpreter Lock
> > (GIL) in place.
> > Effectively, this causes the interpreter to utilize one core when
> > threading is not used and .95 of a core when threading is utilized.
>
> > Is there any work in progess on core Python modules that will
> > permanently resolve this issue?
> > Is there any other way to work around the issue aside from forking new
> > processes or using something else?
>
> There is a group of people working on an alternative implementation to Python
> that, among other things, will not have a GIL:http://code.google.com/p/unladen-swallow/


That's not a foregone conclusion. Well it's not a foregone conclusion
that unladen-swallow will succeed at all, but even if it does they
only say they intend to remove the GIL, not that they necessarily
will.

The GIL actually "solves" two problems: the overhead of synchronizing
reference counts, and the difficulty of writing threaded extensions.
The unladen-swallow team only address the first problem in their
plans. So, even if they do remove the GIL, I doubt GvR will allow it
to be merged back into CPython unless makes extensions are just as
easy to write. That is something I have serious doubts they can pull
off.

Which means a GIL-less unladen-swallow is likely to end being another
fork like IronPython and Jython. Those projects already have no GIL.


Carl Banks

Carl Banks

unread,
Jun 19, 2009, 3:41:50 PM6/19/09
to
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

Jure Erznožnik

unread,
Jun 19, 2009, 5:13:50 PM6/19/09
to
Thanks guys, for all the replies.
They were some very interesting reading / watching.

Seems to me, the Unladen-Swallow might in time produce code which will
have this problem lessened a bit. Their roadmap suggests at least
modifying the GIL principles if not fully removing it. On top of this,
they seem to have a pretty aggressive schedule with good results
expected by Q3 this year. I'm hoping that their patches will be
accepted to cPython codebase in a timely manner. I definitely liket
the speed improvements they showed for Q1 modifications. Though those
improvements don't help my case yet...

The presentation from mr. Beasley was hilarious :D
I find it curious to learn that just simple replacement from events to
actual mutexes already lessens the problem a lot. This should already
be implemented in the cPython codebase IMHO.

As for multiprocessing alternatives, I'll have to look into them. I
haven't yet done multiprocessing code and don't really know what will
happen when I try. I believe that threads would be much more
appropriate for my project, but it's definitely worth a shot. Since my
project is supposed to be cross platform, I'm not really looking
forward to learning cross platform for C++. All my C++ experience is
DOS + Windows derivatives till now :(

OdarR

unread,
Jun 19, 2009, 5:45:02 PM6/19/09
to
On 19 juin, 21:05, Christian Heimes <li...@cheimes.de> wrote:
> I've seen a single Python process using the full capacity of up to 8
> CPUs. The application is making heavy use of lxml for large XSL
> transformations, a database adapter and my own image processing library
> based upon FreeImage.

interesting...

> Of course both lxml and my library are written with the GIL in mind.
> They release the GIL around every call to C libraries that don't touch
> Python objects. PIL releases the lock around ops as well (although it
> took me a while to figure it out because PIL uses its own API instead of
> the standard macros). reportlab has some optional C libraries that
> increase the speed, too. Are you using them?

I don't. Or maybe I did, but I have no clue what to test.
Do you have a real example, some code snippet to can prove/show
activity on multiple core ?
I accept your explanation, but I also like experiencing :)

> By the way threads are evil
> (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) and
> not *the* answer to concurrency.

I don't see threads as evil from my little experience on the subject,
but we need them.
I'm reading what's happening in the java world too, it can be
interesting.

Olivier

Jure Erznožnik

unread,
Jun 19, 2009, 5:49:27 PM6/19/09
to
Sorry, just a few more thoughts:

Does anybody know why GIL can't be made more atomic? I mean, use
different locks for different parts of code?
This way there would be way less blocking and the plugin interface
could remain the same (the interpreter would know what lock it used
for the plugin, so the actual function for releasing / reacquiring the
lock could remain the same)
On second thought, forget this. This is probably exactly the cause of
free-threading reduced performance. Fine-graining the locks increased
the lock count and their implementation is rather slow per se. Strange
that *nix variants don't have InterlockedExchange, probably because
they aren't x86 specific. I find it strange that other architectures
wouldn't have these instructions though... Also, an OS should still be
able to support such a function even if underlying architecture
doesn't have it. After all, a kernel knows what it's currently running
and they are typically not preempted themselves.

Also, a beside question: why does python so like to use events instead
of "true" synchronization objects? Almost every library I looked at
used that. IMHO that's quite irrational. Using objects that are
intended for something else for the job while there are plenty of
"true" options supported in every OS out there.

Still, the free-threading mod could still work just fine if there was
just one more global variable added: current python thread count. A
simple check for value greater than 1 would trigger the
synchronization code, while having just one thread would introduce no
locking at all. Still, I didn't like the performance figures of the
mod (0.6 execution speed, pretty bad core / processor scaling)

I don't know why it's so hard to do simple locking just for writes to
globals. I used to do it massively and it always worked almost with no
penalty at all. It's true that those were all Windows programs, using
critical sections.

OdarR

unread,
Jun 19, 2009, 5:51:04 PM6/19/09
to
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 ?

> (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.)

yes, I also speak about hard computation that could benefit with
multiple cores.


> 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".

"LOL"
I would like to say such thing about my weather...I live in Europe in
a rainy country.

Olivier

Jesse Noller

unread,
Jun 19, 2009, 5:59:26 PM6/19/09
to OdarR, pytho...@python.org

Sorry, you're incorrect. I/O Bound threads do in fact, take advantage
of multiple cores.

Jure Erznožnik

unread,
Jun 19, 2009, 6:06:07 PM6/19/09
to

Olivier,
What Christian is saying is that you can write a C/C++ Python plugin,
release the GIL inside it and then process stuff in threads inside the
plugin.
All this is possible if the progammer doesn't use any Python objects
and it's fairly easy to write such a plugin. Any counting example will
do just fine.

The problem with this solution is that you have to write the code in C
which quite defeats the purpose of using an interpreter in the first
place...
Of course, no pure python code will currently utilize multiple cores
(because of GIL).

I do aggree though that threading is important. Regardless of any
studies showing that threads suck, they are here and they offer
relatively simple concurrency. IMHO they should never have been
crippled like this. Even though GIL solves access violations, it's not
the right approach. It simply kills all threading benefits except for
the situation where you work with multiple I/O blocking threads.
That's just about the only situation where this problem is not
apparent.

We're way past single processor single core computers now. An
important product like Python should support these architectures
properly even if only 1% of applications written in it use threading.

But as Guido himself said; I should not complain but instead try to
contribute to solution. That's the hard part, especially since there's
lots of code that actually need the locking.

Jure Erznožnik

unread,
Jun 19, 2009, 6:10:17 PM6/19/09
to
On Jun 19, 11:59 pm, Jesse Noller <jnol...@gmail.com> wrote:

Incorrect. They take advantage of OS threading support where another
thread can run while one is blocked for I/O.
That is not equal to running on multiple cores (though it actually
does do that, just that cores are all not well utilized - sum(x) <
100% of one core).
You wil get better performance running on single core because of the
way GIL is implemented in all cases.

Paul Boddie

unread,
Jun 19, 2009, 6:18:06 PM6/19/09
to
On 19 Jun, 21:41, Carl Banks <pavlovevide...@gmail.com> wrote:
>
> (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.)

There seems to be a mixing together of these two things when people
talk about "concurrency". Indeed, on the concurrency-sig mailing list
[1] there's already been discussion about whether a particular example
[2] is really a good showcase of concurrency. According to Wikipedia,
concurrency is about "computations [...] executing
simultaneously" [3], not about whether one can handle hundreds of
communications channels sequentially, although this topic is obviously
relevant when dealing with communications between processing contexts.

I agree with the over-rationalisation assessment: it's not convenient
(let alone an advantage) for people to have to switch to C so that
they can release the GIL, nor is it any comfort that CPython's
limitations are "acceptable" for the socket multiplexing server style
of solution when that isn't the kind of solution being developed.
However, there are some reasonable tools out there (and viable
alternative implementations), and I'm optimistic that the situation
will only improve.

Paul

[1] http://mail.python.org/mailman/listinfo/concurrency-sig
[2] http://wiki.python.org/moin/Concurrency/99Bottles
[3] http://en.wikipedia.org/wiki/Concurrency_(computer_science)

Jesse Noller

unread,
Jun 19, 2009, 6:43:39 PM6/19/09
to Jure Erznožnik, pytho...@python.org

No. That's simply incorrect. I (and others) have seen significant
increases in threaded, I/O bound code using multiple cores. It's not
perfect, but it is faster.

Aahz

unread,
Jun 19, 2009, 7:31:59 PM6/19/09
to
In article <d6d695d8-2af6-4713...@n4g2000vba.googlegroups.com>,

=?windows-1252?Q?Jure_Erzno=9Enik?= <jure.er...@gmail.com> wrote:
>
>I do aggree though that threading is important. Regardless of any
>studies showing that threads suck, they are here and they offer
>relatively simple concurrency. IMHO they should never have been
>crippled like this. Even though GIL solves access violations, it's not
>the right approach. It simply kills all threading benefits except for
>the situation where you work with multiple I/O blocking threads.
>That's just about the only situation where this problem is not
>apparent.

NumPy?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

Aahz

unread,
Jun 19, 2009, 7:35:18 PM6/19/09
to
In article <157e0345-74e0-4144...@z7g2000vbh.googlegroups.com>,

Carl Banks <pavlove...@gmail.com> wrote:
>
>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.

Please provide more evidence that Pythonistas are unwilling to
acknowledge the drawbacks of the GIL. I think you're just spreading FUD.
The problem is that discussions about the GIL almost invariably include
false statements about the GIL, and I'm certainly not going to hamper my
writing to always include the caveats about GIL drawbacks while
correcting the wrong information.

Aahz

unread,
Jun 19, 2009, 7:36:32 PM6/19/09
to
In article <f9ff1a89-813b-4367...@h23g2000vbc.googlegroups.com>,
=?windows-1252?Q?Jure_Erzno=9Enik?= <jure.er...@gmail.com> wrote:

>On Jun 19, 11:59=A0pm, Jesse Noller <jnol...@gmail.com> wrote:
>>
>> Sorry, you're incorrect. I/O Bound threads do in fact, take advantage
>> of multiple cores.
>
>Incorrect. They take advantage of OS threading support where another
>thread can run while one is blocked for I/O. That is not equal to
>running on multiple cores (though it actually does do that, just that
>cores are all not well utilized - sum(x) < 100% of one core). You wil
>get better performance running on single core because of the way GIL is
>implemented in all cases.

You should put up or shut up -- I've certainly seen multi-core speedup
with threaded software, so show us your benchmarks!

Christian Heimes

unread,
Jun 19, 2009, 7:42:20 PM6/19/09
to pytho...@python.org
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

Jure Erznožnik

unread,
Jun 19, 2009, 7:49:39 PM6/19/09
to
On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote:
>
> You should put up or shut up -- I've certainly seen multi-core speedup
> with threaded software, so show us your benchmarks!
> --

Sorry, no intent to offend anyone here. Flame wars are not my thing.

I have shown my benchmarks. See first post and click on the link.
That's the reason I started this discussion.

All I'm saying is that you can get threading benefit, but only if the
threading in question is implemented in C plugin.
I have yet to see pure Python code which does take advantage of
multiple cores. From what I read about GIL, this is simply impossible
by design.

But I'm not disputing the fact that cPython as a whole can take
advantage of multiple cores. There certainly are built-in objects that
work as they should.

Ross Ridge

unread,
Jun 19, 2009, 7:46:31 PM6/19/09
to
Jesse Noller <jnol...@gmail.com> wrote:
> Sorry, you're incorrect. I/O Bound threads do in fact, take advantage
> of multiple cores.

<jure.er...@gmail.com> wrote:
>Incorrect. They take advantage of OS threading support where another
>thread can run while one is blocked for I/O. That is not equal to
>running on multiple cores (though it actually does do that, just that
>cores are all not well utilized - sum(x) < 100% of one core). You wil
>get better performance running on single core because of the way GIL is
>implemented in all cases.

Aahz <aa...@pythoncraft.com> wrote:
>You should put up or shut up -- I've certainly seen multi-core speedup
>with threaded software, so show us your benchmarks!

By definition an I/O bound thread isn't CPU bound so won't benefit from
improved CPU resources.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

Christian Heimes

unread,
Jun 19, 2009, 7:52:50 PM6/19/09
to pytho...@python.org
Aahz wrote:
> In article <157e0345-74e0-4144...@z7g2000vbh.googlegroups.com>,
> Carl Banks <pavlove...@gmail.com> wrote:
>> 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.
>
> Please provide more evidence that Pythonistas are unwilling to
> acknowledge the drawbacks of the GIL. I think you're just spreading FUD.
> The problem is that discussions about the GIL almost invariably include
> false statements about the GIL, and I'm certainly not going to hamper my
> writing to always include the caveats about GIL drawbacks while
> correcting the wrong information.

Aahz, my magic pixie dust bag is empty. Do you have some spare dust to
remove the cursed GIL all alone? :p

Christian

Lie Ryan

unread,
Jun 19, 2009, 8:07:27 PM6/19/09
to

I never used threading together with I/O intensively before, but I heard
that I/O operations releases the GIL, and such they're similar to
GIL-releasing C extensions which makes it possible to benefit from
multicore in I/O bound pure python code.

Perhaps we should have more built-in/stdlib operations that can release
GIL safely to release GIL by default? And perhaps some builtin/stdlib
should receive an optional argument that instruct them to release GIL
and by passing this argument, you're making a contract that you wouldn't
do certain things that would disturb the builtin/stdlib's operations;
the specifics of what operations are prohibited would be noted on their
docs.

Jean-Paul Calderone

unread,
Jun 19, 2009, 10:42:57 PM6/19/09
to Lie Ryan, pytho...@python.org
On Sat, 20 Jun 2009 00:07:27 GMT, Lie Ryan <lie....@gmail.com> wrote:
> [snip]

>
>Perhaps we should have more built-in/stdlib operations that can release
>GIL safely to release GIL by default? And perhaps some builtin/stdlib
>should receive an optional argument that instruct them to release GIL
>and by passing this argument, you're making a contract that you wouldn't
>do certain things that would disturb the builtin/stdlib's operations;
>the specifics of what operations are prohibited would be noted on their
>docs.

There would be a lot less useless discussion if people would do a minimal
amount of checking to see if the ideas they're suggesting are at all
feasible.

Why don't you take a look at the CPython source and see if this is actually
possible? If you're not comfortable diving into a C program, then maybe you
could try to become so first, or refrain from making suggestions that rely
on technical details you know nothing about?

Jean-Paul

Piet van Oostrum

unread,
Jun 20, 2009, 4:34:58 AM6/20/09
to
>>>>> Jure Erznoï¿œnik <jure.er...@gmail.com> (JE) wrote:

>JE> Sorry, just a few more thoughts:
>JE> Does anybody know why GIL can't be made more atomic? I mean, use
>JE> different locks for different parts of code?
>JE> This way there would be way less blocking and the plugin interface
>JE> could remain the same (the interpreter would know what lock it used
>JE> for the plugin, so the actual function for releasing / reacquiring the
>JE> lock could remain the same)
>JE> On second thought, forget this. This is probably exactly the cause of
>JE> free-threading reduced performance. Fine-graining the locks increased
>JE> the lock count and their implementation is rather slow per se.

The major obstacles are the refcounts. It would mean that each
refcounted object would need a separate lock including constants like 0,
1, True, None. You would have much more locking and unlocking then with
the GIL. So to get rid of it first the refcounting has to go. But that
is not sufficient.

When the GIL will be removed I suspect that many concurrent programs
will start to fail subtly because they make assumptions about the
atomicity of the operations. In CPython each bytecode is atomic, but
when there is no GIL this is no longer true.

Java has defined this quite rigorously in its memory model (although
there first memory model had subtle bugs): Read and write operations on
32-bit quantities are atomic, others not. This means that on a 64-bit
system, where pointers are 64-bit even assignments on variables of
object types are not atomic and have to be protected with
synchronized. (My info is a few years old, so in the meantime it may
have changed.) In a GIL-less python the same would be true. Of course the
hardware that your program is running on could have atomic read/writes
on 64-bit quantities but if you rely upon that your program may no
longer be portable.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: pi...@vanoostrum.org

Piet van Oostrum

unread,
Jun 20, 2009, 4:45:08 AM6/20/09
to
>>>>> Jure Erznoï¿œnik <jure.er...@gmail.com> (JE) wrote:

>JE> I have shown my benchmarks. See first post and click on the link.
>JE> That's the reason I started this discussion.

>JE> All I'm saying is that you can get threading benefit, but only if the
>JE> threading in question is implemented in C plugin.
>JE> I have yet to see pure Python code which does take advantage of
>JE> multiple cores. From what I read about GIL, this is simply impossible
>JE> by design.

In fact, at least theoretically, your original application could benefit
from multiple cores. Take this scenario:

You have one thread that reads from a file. On each read the GIL is
released until the read has completed. In the meantime the other thread
could do some CPU-intensive work. Now if the read comes entirely from
the O.S. cache it is also CPU-bound. So there a second core comes in
handy. Now usually these reads will not consume so much CPU so it will
probably be hardly noticeable. But if you would have some kind of
CPU-intensive User-space File System, for example with compression
and/or encryption and the data is in memory you might notice it. In this
example all your application code is written in Python.

Piet van Oostrum

unread,
Jun 20, 2009, 4:49:00 AM6/20/09
to
>>>>> Ross Ridge <rri...@csclub.uwaterloo.ca> (RR) wrote:

>RR> By definition an I/O bound thread isn't CPU bound so won't benefit from
>RR> improved CPU resources.

But doing I/O is not the same as being I/O bound. And Python allows
multithreading when a thread does I/O even if that thread is not I/O
bound but CPU bound. See my other posting for an example.

Carl Banks

unread,
Jun 20, 2009, 5:02:34 AM6/20/09
to
On Jun 19, 4:42 pm, Christian Heimes <li...@cheimes.de> wrote:
> 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?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

Carl Banks

unread,
Jun 20, 2009, 5:16:17 AM6/20/09
to
On Jun 19, 4:35 pm, a...@pythoncraft.com (Aahz) wrote:
> In article <157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com>,

> Carl Banks  <pavlovevide...@gmail.com> wrote:
> >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.  
>
> Please provide more evidence that Pythonistas are unwilling to
> acknowledge the drawbacks of the GIL.

I will not, since I was not making an assertion, but an observation
that some Pythonistas ignore (and even outright dismiss) claims that
Python has a drawback by countering with a suggestion that they should
be doing it some other, often more obtuse, way anyway--and expressing
a wish that I could observe this less often.


Carl Banks

Kay Schluehr

unread,
Jun 20, 2009, 5:36:22 AM6/20/09
to
> You might want to read about "The Problem with Threads":
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
>
> and then decide to switch to an appropriate concurrency model for your use
> case.

and to a programming language that supports it.

OdarR

unread,
Jun 20, 2009, 6:24:37 AM6/20/09
to
On 20 juin, 11:02, Carl Banks <pavlovevide...@gmail.com> wrote:
> 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".

merci Carl, you expressed what I would like to tell.

Olivier

sk...@pobox.com

unread,
Jun 20, 2009, 9:36:52 AM6/20/09
to Carl Banks, pytho...@python.org

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

If their code is CPU-bound it's likely that rewriting critical parts in C or
using packages like numpy would improve there performance with or without
multi-threading. For people who aren't used to C there are tools like Pyrex
and Cython which provide a middle road.

Skip

Stefan Behnel

unread,
Jun 20, 2009, 11:28:23 AM6/20/09
to

Maybe, yes. But many different concurrency models are supported by a larger
number of programming languages in one way or another, so the choice of an
appropriate library is often sufficient - and usually a lot easier than
using the 'most appropriate' programming language. Matter of available
skills, mostly. There's usually a lot less code to be written that deals
with concurrency than code that implements what the person paying you makes
money with, so learning a new library may be worth it, while learning a new
language may not.

Stefan

Lie Ryan

unread,
Jun 20, 2009, 1:52:55 PM6/20/09
to pytho...@python.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are 4 types of people's attitude towards discussion on GIL:

Two useless ones:
1. seasoned developers who have run out of ideas and moved to other more
important issues, leaving GIL problems to be solved by the future
generation;
2. newbies who spurts out random ideas, often half-baked, impossible,
unfeasible, or just plain stupid;

and two helpful ones:
3. people who are too tired discussing GIL and just shut their mouth up;
4. people who preached resistance against GIL is futile and converted
people of type 2 into type 3.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko9IfcACgkQqC3FTmXeMUa11wCdFMmvLM6Y3fx8DPcty27XhuVS
eJkAnAup/G/cQkDML0k49a+SlM1ymvCS
=1cRN
-----END PGP SIGNATURE-----

Carl Banks

unread,
Jun 20, 2009, 7:42:51 PM6/20/09
to

Once again you miss the point.

I'm sure you think you're trying to be helpful, but you're coming off
as really presumptuous with this casual dismissal of their concerns.

There are many, many valid reasons why people don't want to stray from
Pure Python. Converting to C, Fortran, Pyrex, etc. has a significant
cost (in both implementation and maintenance): much more than the cost
of parallelizing pure Python code. I guess what really bothers me
about this is how easily people throw out "shut up and use C" for some
things, especially things that quite reasonably appear to be a silly
limitation.

Maybe you don't intend to sound like you're saying "shut up and use
C", but to me, that's how you come off. If you're going to advise
someone to use C, at least try to show some understanding for their
concerns--it would go a long way.


Carl Banks

Jure Erznožnik

unread,
Jun 20, 2009, 9:23:50 PM6/20/09
to
Look, guys, here's the thing:
In the company I work at we decided to rewrite our MRP system in
Python. I was one of the main proponents of it since it's nicely cross
platform and allows for quite rapid application development. The
language and it's built in functions are simply great. The opposition
was quite strong, especially since the owner cheered for it - .net.

So, recently I started writing a part of this new system in Python. A
report generator to be exact. Let's not go into existing offerings,
they are insufficient for our needs.

First I started on a few tests. I wanted to know how the reporting
engine will behave if I do this or that. One of the first tests was,
naturally, threading. The reporting engine itself will have separate,
semi-independent parts that can be threaded well, so I wanted to test
that.

The rest you know if you read the two threads I started on this group.

Now, the core of the new application is designed so that it can be
clustered so it's no problem if we just start multiple instances on
one server, say one for each available core.

The other day, a coworker of mine said something like: what?!? you've
been using Python for two days "already" and you already say it's got
a major fault?
I kinda aggreed with him, especially since this particular coworker
programmed strictly in Python for the last 6 months (and I haven't due
to other current affairs). There was no way my puny testing could
reveal such a major drawback. As it turns out, I was right. I have
programmed enough threading to have tried enough variations which all
reveal the GIL. Which I later confirmed through searching on the web.

My purpose with developing the reporting engine in Python was twofold:
learn Python as I go and create a native solution which will work out-
of-the-box for all systems we decide to support. Making the thing open
source while I'm at it was a side-bonus.

However:
Since the testing revealed this, shall we say "problem", I am tempted
to just use plain old C++ again. Furthermore, I was also not quite
content with the speed of arithmetic processing of the python engine.
I created some simple aggregating objects that only performed two
additions per pass. Calling them 200K times took 4 seconds. This is
another reason why I'm beginning to think C++ might be a better
alternative. I must admit, had the GIL issue not popped up, I'd just
take the threading benefits and forget about it.

But both things together, I'm thinking I need to rethink my strategy
again.
I may at some point decide that learning cross platform programming is
worth a shot and just write a Python plugin for the code I write. The
final effect will be pretty much the same, only faster. Perhaps I will
even manage to get close to Crystal Reports speed, though I highly
doubt that. But in the end, my Python skill will suffer. I still have
an entire application (production support) to develop in it.

Thanks for all the information and please don't flame each other.
I already get the picture that GIL is a hot subject.

Jure Erznožnik

unread,
Jun 20, 2009, 9:27:16 PM6/20/09
to
Add:
Carl, Olivier & co. - You guys know exactly what I wanted.
Others: Going back to C++ isn't what I had in mind when I started
initial testing for my project.

sk...@pobox.com

unread,
Jun 20, 2009, 11:18:53 PM6/20/09
to Carl Banks, pytho...@python.org

Carl> I'm sure you think you're trying to be helpful, but you're coming
Carl> off as really presumptuous with this casual dismissal of their
Carl> concerns.

My apologies, but in most cases there is more than one way to skin a cat.

Trust me, if removing the global interpreter lock was easy, or probably even
it was simply hard, it almost certainly would have been done by now.
Continuing to harp on this particular aspect of the CPython implementation
doesn't help.

Carl> I guess what really bothers me about this is how easily people
Carl> throw out "shut up and use C" for some things, especially things
Carl> that quite reasonably appear to be a silly limitation.

You completely misunderstand I think. People don't throw out "shut up and
use C" out of ignorance. In fact, I don't believe I've ever read a response
which took that tone. The practical matter is that there has so far been no
acceptable patch to CPython which gets rid of the global interpreter lock.
Extremely smart people have tried. More than once. If Guido knew then (20
years ago) what he knows now:

* that the chip manufacturers would have run out of clock speed
improvements for a few years and resorted to multi-core CPUs as a way
to make their computers "faster"

* that garbage collection algorithms would have improved as much as they
have in the past twenty years

I suspect he might well have considered garbage collection instead of
reference counting as a way to reclaim unreferenced memory and we might have
a GIL-less CPython implementation today.

Carl> Maybe you don't intend to sound like you're saying "shut up and
Carl> use C", but to me, that's how you come off. If you're going to
Carl> advise someone to use C, at least try to show some understanding
Carl> for their concerns--it would go a long way.

Then you haven't been listening. This topic comes up over and over and over
again. It's a well-known limitation of the implementation. Poking people
in the eye with it over and over doesn't help. The reasons for the
limitation are explained every time the topic is raised. In the absence of
a GIL-less CPython interpreter you are simply going to have to look
elsewhere for performance improvements I'm afraid. Yes, I'll drag out the
same old saws:

* code hot spots in C or C++

* use tools like Pyrex, Cython, Psyco or Shed Skin

* for array procesing, use numpy, preferably on top of a recent enough
version of Atlas which does transparent multi-threading under the
covers

* use multiple processes

* rewrite your code to use more efficient algorithms

I don't write those out of ignorance for your plight. It's just that if you
want a faster Python program today you're going to have to look elsewhere
for your speedups.

--
Skip Montanaro - sk...@pobox.com - http://www.smontanaro.net/
when i wake up with a heart rate below 40, i head right for the espresso
machine. -- chaos @ forums.usms.org

Kay Schluehr

unread,
Jun 21, 2009, 12:22:18 AM6/21/09
to

This implies that people stay defensive concerning concurrency ( like
me right now ) and do not embrace it like e.g. Erlang does. Sometimes
there is a radical change in the way we design applications and a
language is the appropriate medium to express it succinctly.
Concurrency is one example, writing GUIs and event driven programs in
a declarative style ( Flex, WPF, JavaFX ) is another one. In
particular the latter group shows that new skills are adopted rather
quickly.

I don't see that a concurrency oriented language has really peaked
though yet.

Carl Banks

unread,
Jun 21, 2009, 12:38:16 AM6/21/09
to
On Jun 20, 8:18 pm, s...@pobox.com wrote:
>     Carl> Maybe you don't intend to sound like you're saying "shut up and
>     Carl> use C", but to me, that's how you come off.  If you're going to
>     Carl> advise someone to use C, at least try to show some understanding
>     Carl> for their concerns--it would go a long way.
>
> Then you haven't been listening.  This topic comes up over and over and over
> again.  It's a well-known limitation of the implementation.  Poking people
> in the eye with it over and over doesn't help.  The reasons for the
> limitation are explained every time the topic is raised.  In the absence of
> a GIL-less CPython interpreter you are simply going to have to look
> elsewhere for performance improvements I'm afraid.  Yes, I'll drag out the
> same old saws:
>
>     * code hot spots in C or C++
>
>     * use tools like Pyrex, Cython, Psyco or Shed Skin
>
>     * for array procesing, use numpy, preferably on top of a recent enough
>       version of Atlas which does transparent multi-threading under the
>       covers
>
>     * use multiple processes
>
>     * rewrite your code to use more efficient algorithms
>
> I don't write those out of ignorance for your plight.  It's just that if you
> want a faster Python program today you're going to have to look elsewhere
> for your speedups.

Just for the record, I am not taking issue with the advice itself
(except that you forgot "use Jython/IronPython which have no GIL").
I'm not even saying that Python was wrong for having the GIL.

All I'm saying is that [this is not aimed specifically at you] this
advice can be delivered with more respect for the complainer's
problem, and less fanboy-like knee-jerk defensiveness of Python.


Carl Banks

OdarR

unread,
Jun 21, 2009, 3:32:31 AM6/21/09
to

Do you think multiprocessing can help you seriously ?
Can you benefit from multiple cpu ?

did you try to enhance your code with numpy ?

Olivier
(installed a backported multiprocessing on his 2.5.1 Python, but need
installation of Xcode first)

Jure Erznožnik

unread,
Jun 21, 2009, 4:39:38 AM6/21/09
to
On Jun 21, 9:32 am, OdarR <Olivier.Da...@gmail.com> wrote:
>
> Do you think multiprocessing can help you seriously ?
> Can you benefit from multiple cpu ?
>
> did you try to enhance your code with numpy ?
>
> Olivier
> (installed a backported multiprocessing on his 2.5.1 Python, but need
> installation of Xcode first)

Multithreading / multiprocessing can help me with my problem. As you
know, database reading is typically I/O bound so it helps to put it in
a separate thread. I might not even notice the GIL if I used SQL
access in the first place. As it is, DBFPY is pretty CPU intensive
since it's a pure Python DBF implementation.
To continue: the second major stage (summary calculations) is
completely CPU bound. Using numpy might or might not help with it.
Those are simple calculations, mostly additions. I try not to put the
entire database in arrays to save memory and so I mostly just add
counters where I can. Soe functions simply require arrays, but they
are more rare, so I guess I'm safe with that. You wouldn't believe how
complex some reports can be. Threading + memory saving is a must and
even so, I'll probably have to implement some sort of serialization
later on, so that the stuff can run on more memory constrained
devices.
The third major stage, rendering engine, is again mostly CPU bound,
but at the same time it's I/O bound as well when outputting the
result.

All three major parts are more or less independent from each other and
can run simultaneously, just with a bit of a delay. I can perform
calculations while waiting for the next record and I can also start
rendering immediately after I have all the data for the first group
available.

I may use multiprocessing, but I believe it introduces more
communication overhead than threads and am so reluctant to go there.
Threads were perfect, other stuff wasn't. To make things worse, no
particular extension / fork / branch helps me here. So if I wanted to
just do the stuff in Python, I'd have to move to Jthon or IronPython
and hope cPython eventually improves in this area. I do actually need
cPython since the other two aren't supported on all platforms my
company intends to support.

The main issue I currently have with GIL is that execution time is
worse when I use threading. Had it been the same, I wouldn't worry too
much about it. Waiting for a permenent solution would be much easier
then...

Hendrik van Rooyen

unread,
Jun 21, 2009, 5:47:49 AM6/21/09
to pytho...@python.org
"Kay Schluehr" <k...@fiber-space.de> wrote:

> This implies that people stay defensive concerning concurrency ( like
> me right now ) and do not embrace it like e.g. Erlang does. Sometimes
> there is a radical change in the way we design applications and a
> language is the appropriate medium to express it succinctly.
> Concurrency is one example, writing GUIs and event driven programs in
> a declarative style ( Flex, WPF, JavaFX ) is another one. In
> particular the latter group shows that new skills are adopted rather
> quickly.
>
> I don't see that a concurrency oriented language has really peaked
> though yet.

I think that this is because (like your link has shown) the problem
is really not trivial, and also because the model that can bring
sanity to the party (independent threads/processes that communicate
with queued messages) is seen as inefficient at small scale.

- Hendrik


Stefan Behnel

unread,
Jun 21, 2009, 6:55:00 AM6/21/09
to
Christian Heimes wrote:
> 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 ;)
[...]

> 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.

Well, and there's always Cython to the rescue when you need it.

Stefan

Stefan Behnel

unread,
Jun 21, 2009, 7:20:11 AM6/21/09
to
Jure Erznožnik wrote:
> On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote:
>> You should put up or shut up -- I've certainly seen multi-core speedup
>> with threaded software, so show us your benchmarks!
>> --
>
> Sorry, no intent to offend anyone here. Flame wars are not my thing.
>
> I have shown my benchmarks. See first post and click on the link.
> That's the reason I started this discussion.
>
> All I'm saying is that you can get threading benefit, but only if the
> threading in question is implemented in C plugin.
> I have yet to see pure Python code which does take advantage of
> multiple cores. From what I read about GIL, this is simply impossible
> by design.

Well, CPython is written in C. So running Python code in CPython will
necessarily run C code (whatever "plugin" means in your post above). If
that C code frees the GIL or not depends on the parts of CPython or
external packages that you use. And there are many parts that free the GIL
and will thus benefit (sometimes heavily) from threading and
multiple-cores, and there are also many parts that do not free the GIL and
will therefore not (or likely not) benefit from multiple-cores.

Claiming that "pure Python code does not free the GIL" in the context of
CPython when you define "pure Python code" as code that does not depend on
C code is plain flawed.

Stefan

Jeremy Sanders

unread,
Jun 21, 2009, 7:48:19 AM6/21/09
to
Jesse Noller wrote:

> Sorry, you're incorrect. I/O Bound threads do in fact, take
advantage
> of multiple cores.

I don't know whether anyone else brought this up, but it looks
like Python has problems with even this form of threading

http://www.dabeaz.com/python/GIL.pdf

It's certainly a very interesting read if you're interested in
this subject.

--
Jeremy Sanders
http://www.jeremysanders.net/

Aahz

unread,
Jun 21, 2009, 11:57:13 AM6/21/09
to
In article <90303b55-8686-4d56...@l8g2000vbp.googlegroups.com>,

=?windows-1252?Q?Jure_Erzno=9Enik?= <jure.er...@gmail.com> wrote:
>
>So, recently I started writing a part of this new system in Python. A
>report generator to be exact. Let's not go into existing offerings,
>they are insufficient for our needs.
>
>First I started on a few tests. I wanted to know how the reporting
>engine will behave if I do this or that. One of the first tests was,
>naturally, threading. The reporting engine itself will have separate,
>semi-independent parts that can be threaded well, so I wanted to test
>that.

This is not something that I would expect Python threads to provide a
performance boost for. I would expect that if it were a GUI app, it
would improve responsiveness, properly designed. If performance were a
goal, I would start by profiling it under a single-threaded design and
see where the hotspots were, then either choose one of several options
for improving performance or go multi-process.

Note that I'm generally one of the Python thread boosters (unlike some
people who claim that Python threads are worthless), but I also never
claim that Python threads are good for CPU-intensive operations (which
report generation is), *except* for making GUI applications more
responsive.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

Aahz

unread,
Jun 21, 2009, 11:59:37 AM6/21/09
to
In article <h1l6m3$3fu$1...@gemini.csx.cam.ac.uk>,

Jeremy Sanders <jeremy+com...@jeremysanders.net> wrote:
>Jesse Noller wrote:
>>
>> Sorry, you're incorrect. I/O Bound threads do in fact, take advantage
>> of multiple cores.
>
>I don't know whether anyone else brought this up, but it looks
>like Python has problems with even this form of threading
>
>http://www.dabeaz.com/python/GIL.pdf

Most of us have already seen this. It's a good point, but IME writing
multi-threaded apps for multi-core machines, I think one should be
careful to avoid reading too much into it.

Paul Rubin

unread,
Jun 21, 2009, 1:12:40 PM6/21/09
to
"Hendrik van Rooyen" <ma...@microcorp.co.za> writes:
> I think that this is because (like your link has shown) the problem
> is really not trivial, and also because the model that can bring
> sanity to the party (independent threads/processes that communicate
> with queued messages) is seen as inefficient at small scale.

That style works pretty well in Python and other languages. The main
gripe about it for Python is the subject of this thread, i.e. the GIL.

Hendrik van Rooyen

unread,
Jun 22, 2009, 4:03:13 AM6/22/09
to pytho...@python.org

I have found that if you accept it, and sprinkle a few judicious
time.sleep(short_time)'s around, things work well. Sort of choosing
yourself when the thread gives up its turn.

- Hendrik


Reply all
Reply to author
Forward
0 new messages