[Python-Dev] Making python C-API thread safe (try 2)
Pettersen, Bjorn S
BjornPettersen at fairisaac.com
Wed Sep 17 15:32:13 EDT 2003
More information about the Python-list mailing list
Wed Sep 17 15:32:13 EDT 2003
- Previous message (by thread): [Python-Dev] Making python C-API thread safe (try 2)
- Next message (by thread): [Python-Dev] Making python C-API thread safe (try 2)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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
- Previous message (by thread): [Python-Dev] Making python C-API thread safe (try 2)
- Next message (by thread): [Python-Dev] Making python C-API thread safe (try 2)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list