On Wed, Jun 10, 2009 at 9:05 AM, Ronald Oussoren<ronaldoussoren@...> wrote:
> On 10 Jun, 2009, at 7:55, Barry Wark wrote:
>> On Thu, Jun 4, 2009 at 8:48 AM, Jonathan Saggau<saggau@...> 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
>>> 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.
>>> 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