Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

[robert]

Daniel Dittmar wrote:
> robert wrote:
>> (IPython is only a special "python network terminal" as already said.)
> 
> Sorry, I thought of IronPython, the .NET variant.
> 
>> Does Jython really eliminate the GIL? What happens when different 
> 
> Yes.
> 
>> threads alter/read a dict concurrently - the basic operation in 
>> python, which is usually not protected by locks. Does Jython use a 
>> dict data type (and other collection types) which lock during _each_ 
>> access? in case - that may be very expensive.
> 
> True, though Java synchronization has gotten better and better. Still, 
> Sun introduced non locking hash tables, so it was a problem. It'd be 
> interesting to know which kind of dict is used in Jython for attribute 
> access.

I hate Jave :-) , but to come to concerns of this thread, the speed.
Found not much about.
http://mail.zope.org/pipermail/zpt/2002-March/002884.html
says Jython to be at least 9x slower. Is this still the gap (and constant locking a big factor in this).

IronPython seems to be surprisingly faster than CPython (sometimes): http://www.python.org/pycon/dc2004/papers/9/
But I cannot imagine, that this includes GIL free locking dicts an all ... !?

Is numpy/scipy available for Iron/Jython ?


>> garbage is collected earliest, when the refcount went to 0. If it ever 
>> went to 0, no one will ever use such object again. Thus GC should not 
>> be different at all.
> 
> Since Python 2.?, there's a mark-and-sweep garbage collection in 
> addition to the reference counting scheme. This was put into Python to 
> be able to reclaim object cycles.

still that only walks on objects which have already zero refcount. Cannot imagine any additional problems with the GIL.

robert