

Presentation on the new Python GIL - voxcogitatio
http://www.dabeaz.com/blog/2010/01/presentation-on-new-python-gil.html

======
fauigerzigerk
I have a slightly weird and probably completely unworkable "idea" that has
nothing to do with this particular GIL improvement but with the broader GIL
issue.

The problem with removing the GIL seems to be garbage collection. I wonder why
it's not possible to introduce a new type of object reference that exempts
referenced objects from being garbage collected.

Then multiple Python interpreters could be started in separate threads, each
with its own unmodified GIL, and the only thing they could access would be
their own thread local data and those special shared objects.

What this amounts to is basically an implementation of a multi process
architecture on top of a multi threaded architecture. The crucial difference
is that the memory shared among the interpreters could hold pointers and thus
proper in memory data structures and not just a BLOB into which everything has
to be serialized as in the case of conventional shared memory.

Of course the shared objects would have to be manually deleted.

One issue I see is that when such a special object is created, all the objects
it creates recursively would also have to be allocated in that pool of special
objects. But I think it should be possible to use some kind of global flag to
special case the allocator.

Well, there is probably a huge number of issues with this kind of trickery and
it's definately not a long term solution. But I'd love to use Python much more
than I do and the GIL issue is what prevents that for me at the moment.

~~~
wmf
I think Erlang and MS Singularity use this technique to some extent.

<http://doi.acm.org/10.1145/1029873.1029875>
<http://doi.acm.org/10.1145/1146809.1146813>
[http://research.microsoft.com/apps/pubs/default.aspx?id=6748...](http://research.microsoft.com/apps/pubs/default.aspx?id=67482)

~~~
thwarted
As does perl. You need to declare variables as shared, there is apparently
some performance hit, but it's mostly localized to the shared variables, so
reasonably manageable. I've actually found it easier to work with than
implicit shared data across all threads because you actually need to think
about the exposed surface area and how you can minimize it.

------
ShabbyDoo
Knowing little of Python, is it the case that the GIL was not initially deemed
a bad scheme because multi-processor x86 machines were a rarity in the
mid-90's (when Python was young)? I presume that Sun desired Java to be
multiprocessor friendly because it had multi-cpu SPARC machines at the time of
Java's design?

And, for those using Python for high-volume production systems, how do you
cope? Do you run one process (say a Zope instance) per core and load balance?

~~~
jart
Keep in mind the GIL is only a problem when you a) use threads and b) perform
CPU-bound operations (unless you need soft real time)

When writing CPU-bound code, there are many libraries like NumPy that can do
your heavy lifting in native code (thus avoiding the GIL)

So it really isn't as bad as it seems. The reason this patch is good, is
because it prevents performance from falling apart if one of your threads
takes up too much CPU.

------
st3fan
"""Does it work? Yes it's better: Sequential 23.5 seconds. Threaded 24.0
seconds."""

How is that better? It is an improvement over earlier versions of Python.
Better would be if the threaded version would actually be twice as fast.

~~~
Luyt
If you really want to speed up your program, you have to parallelize and
distribute the workload over multiple cores. Python has a module in the
standard library for this, it's called 'multiprocessing'. See
<http://docs.python.org/library/multiprocessing.html>

~~~
rbanffy
It won't help if you have to do stuff over a single shared data structure.

~~~
st3fan
Well you can of course. It is just a pain to do it.

~~~
rbanffy
That's a good point. I rarely had to do it and, when I could, I opted to
distribute the data.

Still, Python needs better threading.

------
sagarm
Does anyone know why multiple kernel threads are used at all? If only one
thread can run at a time, why not just use a single kernel thread?

~~~
kingkilr
Because CPython doesn't want to invent it's own scheduler (and various other
things that your operating system already does for you), further multiple
threads can be active at the same time if they're doing any operations that
release the GIL (such as I/O), Python can't know whether your thread will do
any I/O before you create it.

~~~
scott_s
However, the approach explained in this presentation does just that. The
solution looks like a crude process operating systems scheduler.

~~~
kingkilr
It's not really, it's simply threads asking the main thread to drop every 5
ms, and then relying on the OS to schedule them. If Python had it's own
scheduler it would do things like assigning priorities and actually deciding
which thread would take over when the GIL was dropped.

