[Python-Dev] Removing the GIL (Me, not you!)

[Adam Olsen]

On 9/13/07, Justin Tulloss <jmtulloss at gmail.com> wrote:
>
>
> On 9/13/07, Adam Olsen <rhamph at gmail.com> wrote:
> >
> > Basically though, atomic incref/decref won't work.  Once you've got
> > two threads modifying the same location the costs skyrocket.  Even
> > without being properly atomic you'll get the same slowdown on x86
> > (who's cache coherency is fairly strict.)
>
>
> I'm a bit skeptical of the actual costs of atomic incref. For there to be
> contention, you would need to have to be modifying the same memory location
> at the exact same time. That seems unlikely to ever happen. We can't bank on
> it never happening, but an occasionally expensive operation is ok. After
> all, it's occasional.

That was my initial expectation too.  However, the incref *is* a
modification.  It's not simply an issue of the "exact same time", but
anything that causes the cache entries to bounce back and forth and
delay the rest of the pipeline.  If you have a simple loop like "for i
in range(count): 1.0+n", then the 1.0 literal will get shared between
threads, and the refcount will get hammered.

Is it reasonable to expect that much sharing?  I think it is.
Literals are an obvious example, but there's also configuration data
passed between threads.  Pystone seems to have enough sharing to kill
performance.  And after all, isn't sharing the whole point (even in
the definition) of threads?

-- 
Adam Olsen, aka Rhamphoryncus