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

[Barry W. <bar...@gm...>]

On Wed, Jun 10, 2009 at 9:05 AM, Ronald Oussoren<ron...@ma...> wrote:
>
> 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.

My (limited!) understanding of the Python memory semantics wrt C
extensions made me think this was going to be tough too, but you never
know. As you said, they have some very smart folks there.

>
> 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).

Yes, getting rid of the GIL would be huge.

>
> 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
>>>
>
>