[Python-Dev] Making python C-API thread safe (try 2)

Pettersen, Bjorn S BjornPettersen at fairisaac.com
Wed Sep 17 21:32:13 CEST 2003


> From: Harri Pesonen [mailto:fuerte at sci.fi]
>
> Jeff Epler wrote:
>
> > On Tue, Sep 16, 2003 at 08:22:41PM +0300, Harri Pesonen wrote:
> > >
> > > It is more efficient to have one process and several threads, than
> > > several processes each having one thread.
> >   
> >
> > If it's easier to code "several processes each having one thread",
then
> > I'll sure do it.  I've accepted a 2x-100x speed hit by using Python,
so
> > if it's a 25% difference in efficiency, I won't sign up to wait for
code
> > that doesn't exist yet.
> 
> But wouldn't it be better if Python had real multitasking? Comments
like the
> above mean that you accept Python as it is, fine. But usually people
want to
> make things better when they see that something can be improved. If my
roof is
> leaking, I have two choices: fix it or accept it. If I am able to fix
it, then
> I'll probably do it.
[...]

No, comments like the above realizes that there are certain tradeoffs.
Reference
counting as a primary garbage collection mechanism is fundamentally
incompatible 
with multithreading in an object oriented language -- unless you have
mitigating 
factors like the GIL. The number of locking operations quickly overwhelm
actual 
computation. (I'm aware that you don't want shared data, however I
completely 
fail to see the utility..)

There is some research indicating that generational gc is more efficient
with 
regards to total program run time in heavily mt oo applications, so
that's 
certainly an interesting area to look into -- it would, however, require
a 
fundamentally different language implmentation (one which didn't have
the nice 
finalization guarantees CPython currently has).

When it comes to applicability, I'm assuming you're not heading in this 
direction to do heavy computational work in pure Python(?) If all you
want to do 
is watch your Python programs run maximally paralell, I would suggest
Jython as 
an alternative without a GIL...

-- bjorn





More information about the Python-list mailing list