[Python-ideas] Extending language syntax

Nick Coghlan ncoghlan at gmail.com
Tue Nov 12 11:23:17 CET 2013


On 12 Nov 2013 20:03, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>
> On Nov 11, 2013, at 21:27, Chris Angelico <rosuav at gmail.com> wrote:
>
> > On Tue, Nov 12, 2013 at 4:03 PM, Gregory Salvan <apieum at gmail.com>
wrote:
> >> I suggested generating value object by freezing object states and to
have
> >> object identities defined on their values instead of their memory
> >> allocation.
> >
> > I can see some potential in this if there were a way to say "This will
> > never change, don't refcount it or GC-check it"; that might improve
> > performance across a fork (or across threads), but it'd take a lot of
> > language support. Effectively, you would be forfeiting the usual GC
> > memory saving "this isn't needed, get rid of it" and fixing it in
> > memory someplace. The question would be: Is the saving of not writing
> > to that memory (updating refcounts, or marking for a mark/sweep GC, or
> > whatever the equivalent is for each Python implementation) worth the
> > complexity of checking every object to see if it's a frozen one?
>
> Is there any implementation (like one of the PyPy sub projects) that uses
refcounting, with interlocked increments if two interpreter threads are
live but plain adds otherwise? In such an implementation, I think the cost
of checking a second flag to avoid the interlocked increment would, at
least on many platforms (including x86, x86_64, and arm9), be comparatively
very cheap, and if used widely could provide big benefits.

PyParallel uses some neat tricks to skip almost all memory management in
worker threads. Currently Windows only though, and one reader's "neat
trick" may be another's "awful hack" :)

Cheers,
Nick.

>
> I believe CPython and standard PyPy just use plain adds under the GIL,
and Jython and IronPython leave all the gc up to the underlying VM, so it
would probably be a lot harder to get enough benefit there without a lot
more effort.
>
> Also, as I said in my previous message, I don't think this "permanent
value" idea is in any way dependent on any of the other stuff suggested,
and in fact would work better without them. (For example, being able to
have multiple separate copies of the permanent object that act as if
they're identical, and can't be distinguished at the Python level.)
>
> >
> > ChrisA
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131112/adf25ee0/attachment.html>


More information about the Python-ideas mailing list