Re: [Pyobjc-dev] ObjC GC with PyObjC?

[Ronald O. <ron...@ma...>]

On 10 Jun, 2009, at 7:55, Barry Wark wrote:

> On Thu, Jun 4, 2009 at 8:48 AM, Jonathan Saggau<sa...@gm...>  
> wrote:
>> Ronald Oussoren wrote:
>>>
>>> I don't agree. There could be advantages for regular python as well,
>>> IMHO removing CPython's refcounting is a necessary first step for
>>> removing the GIL.  Removing the GIL would definitely be an advantage
>>> for general python code, especially because using multiple  
>>> independent
>>> threads of execution is the only way to seriously improve  
>>> performance
>>> on modern hardware because sadly enough the "wait a year and then my
>>> single-threaded code is twice as fast"-era is over.  
>>> Multiprocessing is
>>> a cool hack, but isn't a real solution; I have a number of programs
>>> that use multiple threads and need shared memory to get fast enough
>>> communications (basicly because large objects get transferred  
>>> between
>>> threads).
>>>
>>> Ronald
>> As a curiosity for those who know the internals of Python better  
>> than I
>> do, is there any reason to believe that most existing python code  
>> would
>> even "care" which flavor of GC it's running under?
>
> As an aside, the Google guys think that they can pull this off without
> affecting even C-language extensions. I just discovered the Unladed
> Swallow project (http://code.google.com/p/unladen-swallow/) appears to
> be their attempt to reimplement the Python VM on top of LLVM. Their
> goals are performance, but they also mention pluggable GC and some
> other very cool tricks. I think it would definitely be worth keeping
> an eye on this project. If it progresses as they claim, it may be a
> much better starting point for any efforts to bring Python and the
> ObjC runtime closer.

I know of Unladen Swallow and tracking their progress.  I've spoken  
with someone on their team at Pycon and they are very confident that  
they can pull of their performance goals, basicly by going through the  
available literature and implementing those ideas. That's easier said  
than done, but Google doesn't have a shortage of PhD's and offices of  
the Unladen Swallow team are close to that of some of the authors of  
research papers that they intend to use.

I'm not so sure about not affecting C extensions, especially not in  
the context of the ObjC garbage collector due to some special  
limitations.

BTW. The bit that excites me even more than the performance work is  
their secondairy goal of getting rid of the GIL. I have a number of  
projects where I have written a custom C extension just to make use of  
additional cores and where I would have been able to use an existing  
extension or even pure python code if Python hadn't had the GIL. (And  
no, multiprocessing wouldn't work in those projects, the communication  
overhead between processes would have been too large).

Ronald
> -B
>
>>
>>
>> Jonathan 'usually lurking' Saggau
>>
>> ------------------------------------------------------------------------------
>> OpenSolaris 2009.06 is a cutting edge operating system for  
>> enterprises
>> looking to deploy the next generation of Solaris that includes the  
>> latest
>> innovations from Sun and the OpenSource community. Download a copy  
>> and
>> enjoy capabilities such as Networking, Storage and Virtualization.
>> Go to: http://p.sf.net/sfu/opensolaris-get
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>