[Python-Dev] optimize atomic inc/dec? (was: baby steps for free-threading)

[Greg Stein]

On Wed, 19 Apr 2000, Christopher Petrilli wrote:
> Salz, Rich [SalzR@CertCo.com] wrote:
> > >This definitely slows Python down. If an object is known to be visible to
> > >only one thread, then you can avoid the atomic inc/dec. But that leads to
> > >madness :-)
> > 
> > I would much rather see the language extended to indicate that a particular
> > variable is "shared" across free-threaded interpreters. The hit of taking
> > a mutex on every incref/decref is way bad.
> 
> I wonder if the energy is better spent in a truly highly-optimized
> implementation on the major platforms rather than trying to
> conditional this.  This may mean writing x86 assembler, and a few
> others,

Bill Tutt had a good point -- we can get a bunch of assembler fragments
from the Linux kernel for atomic inc/dec. On specific compiler and
processor architecture combinations, we could drop to assembly to provide
an atomic dec/inc.

For example, when we see we're using GCC on an x86 processor (whether
FreeBSD or Linux), we can define atomic_inc() as an __asm fragment.

> but then again, once written, it shouldn't need much
> modification.  I wonder if the conditional mutexing might be slower
> because of the check and lack of focus on bringing the core
> implementation up to speed.

Won't work anyhow. See previous email.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/