The Future of Python Threading

[Bjoern Schliessmann]

Nick Craig-Wood wrote:
[GIL]
> That is certainly true.  However the point being is that running
> on 2 CPUs at once at 95% efficiency is much better than running on
> only 1 at 99%...

How do you define this percent efficiency?
 
>>> The truth is that the future (and present reality) of almost
>>> every form of computing is multi-core,
>> 
>>  Is it? 8)
> 
> Intel, AMD and Sun would have you believe that yes!

Strange, in my programs, I don't need any "real" concurrency (they
are network servers and scripts). Or do you mean "the future of
computing hardware is multi-core"? That indeed may be true.

>>  The question is: If it really was, how much of useful
>>  performance gain would you get?
> 
> The linux kernel has been through these growing pains already... 
> SMP support was initially done with the Big Kernel Lock (BKL)
> which is exactly equivalent to the GIL.

So, how much performance gain would you get? Again, managing
fine-grained locking can be much more work than one simple lock.

> The linux kernel has moved onwards to finer and finer grained
> locking.

How do you compare a byte code interpreter to a monolithic OS
kernel?

> I'd like to see a python build as it is at the moment and a
> python-mt build which has the GIL broken down into a lock on each
> object. python-mt would certainly be slower for non threaded
> tasks, but it would certainly be quicker for threaded tasks on
> multiple CPU computers.

>From where do you take this certainty? For example, if the program
in question involves mostly IO access, there will be virtually no
gain. Multithreading is not Performance.
 
> The user could then choose which python to run.
> 
> This would of course make C extensions more complicated...

Also, C extensions can release the GIL for long-running
computations.

Regards,


Björn

-- 
BOFH excuse #391:

We already sent around a notice about that.