On Wed, Dec 15, 2021 at 10:15 AM Eric Snow wrote:
> Yes, I plan on benchmarking the change as soon as we can run
> pyperformance on main.
I just ran the benchmarks and the PR makes CPython 4% slower. See
https://github.com/python/cpython/pull/19474#issuecomment-1032944709.
-eric
On 17/12/21 6:58 pm, Steven D'Aprano wrote:
Or a Doctor Who episode. Doctor Who and the Immortal Instances of Doom.
Hmmm... and Guido has a time machine... Is it possible he's
secretly a Time Lord?
--
Greg
___
Python-Dev mailing list --
On Sat, 18 Dec 2021 08:40:57 -
"Jim J. Jewett" wrote:
> Why are Immutability and transitive Immortality needed to share an object
> across interpreters?
Immutability is a functional requirement: you don't want one
interpreter to be able to change the state of another one by mistake.
Unlike
Why are Immutability and transitive Immortality needed to share an object
across interpreters?
Are you assuming that a change in one interpreter should not be seen by others?
(Typical case, but not always true.)
Or are you saying that there is a technical problem such that a change --
fwiw we added immortal objects to Pyston and haven't run into any issues
with it. The goal is a bit different: to eliminate common refcount
operations for performance, which we can do a bit more of because we have a
jit. And we don't mind if unaware code ends up changing the refcounts of
immortal
On Fri, Dec 17, 2021 at 11:35:24AM +1300, Greg Ewing wrote:
> On 17/12/21 6:52 am, Eddie Elizondo via Python-Dev wrote:
> >I've just updated the original Immortal Instances PR
>
> Is it just me, or does Immortal Instances sound like a
> video game franchise?
Or a Doctor Who episode. Doctor Who
On 17/12/21 6:52 am, Eddie Elizondo via Python-Dev wrote:
I've just updated the original Immortal Instances PR
Is it just me, or does Immortal Instances sound like a
video game franchise?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
It’s *needed* when multiple interpreters share them.
On Thu, Dec 16, 2021 at 14:03 Jim J. Jewett wrote:
> Guido van Rossum wrote:
> > On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett jimjjew...@gmail.com
> wrote:
> > > Immortal objects shouldn't be reclaimed by garbage collection, but they
> > >
Guido van Rossum wrote:
> On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett jimjjew...@gmail.com wrote:
> > Immortal objects shouldn't be reclaimed by garbage collection, but they
> > still count as potential external roots for non-cyclic liveness.
> So everything referenced by an immortal object
On Thu, Dec 16, 2021 at 3:08 AM Petr Viktorin wrote:
> On 16. 12. 21 11:52, Victor Stinner wrote:
> > On Thu, Dec 16, 2021 at 2:29 AM Nathaniel Smith wrote:
> >> On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner
> wrote:
> >>> I wrote https://bugs.python.org/issue39511 and
> >>>
I've just updated the original Immortal Instances PR with a bunch of tricks
that I used to achieve as much performance parity as possible:
https://github.com/python/cpython/pull/19474 . You can see the details along
with some benchmarks in the PR itself.
This should address a bunch of the
On 16. 12. 21 11:52, Victor Stinner wrote:
On Thu, Dec 16, 2021 at 2:29 AM Nathaniel Smith wrote:
On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner wrote:
I wrote https://bugs.python.org/issue39511 and
https://github.com/python/cpython/pull/18301 to have per-interpreter
None, True and False
On Thu, Dec 16, 2021 at 2:29 AM Nathaniel Smith wrote:
> On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner wrote:
> > I wrote https://bugs.python.org/issue39511 and
> > https://github.com/python/cpython/pull/18301 to have per-interpreter
> > None, True and False singletons. My change is backward
On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett wrote:
> Immortal objects shouldn't be reclaimed by garbage collection, but they
> still count as potential external roots for non-cyclic liveness.
>
So everything referenced by an immortal object should also be made immortal
-- even its type. Hence
How common is it to reload a module in production code?
It seems like "object created at the module level" (excluding __main__) is at
least as good of an heuristic for immortality as "string that meets the
syntactic requirements for an identifier". Perhaps also anything created as
part of
Immortal objects shouldn't be reclaimed by garbage collection, but they still
count as potential external roots for non-cyclic liveness.
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner wrote:
> I wrote https://bugs.python.org/issue39511 and
> https://github.com/python/cpython/pull/18301 to have per-interpreter
> None, True and False singletons. My change is backward compatible on
> the C API: you can still use "Py_None" in your C
On Wed, Dec 15, 2021 at 12:18 PM Chris Angelico wrote:
> Sorry if this is a dumb question, but would it be possible to solve
> that last point with an immortal arena [1] from which immortal objects
> could be allocated? None/True/False could be allocated there, but so
> could anything that is
On Thu, Dec 16, 2021 at 7:03 AM Eric Snow wrote:
>
> On Wed, Dec 15, 2021 at 12:18 PM Chris Angelico wrote:
> > Sorry if this is a dumb question, but would it be possible to solve
> > that last point with an immortal arena [1] from which immortal objects
> > could be allocated? None/True/False
On Thu, Dec 16, 2021 at 6:03 AM Eric Snow wrote:
> * using the ref count isn't the only viable approach; another would be
> checking the pointer itself
>+ put the object in a specific section of static data and compare
> the pointer against the bounds
>+ this avoids loading the actual
On Tue, Dec 14, 2021 at 11:19 AM Eric Snow wrote:
> There is one solution that would help both of the above in a nice way:
> "immortal" objects.
FYI, here are some observations that came up during some discussions
with the "faster-cpython" team today:
* immortal objects should probably only be
On Wed, Dec 15, 2021 at 8:16 AM Skip Montanaro wrote:
> It might be worth (re)reviewing Sam Gross's nogil effort to see how he
> approached this:
Yeah, there is good info in there.
-eric
___
Python-Dev mailing list -- python-dev@python.org
To
On Wed, Dec 15, 2021 at 4:03 AM Victor Stinner wrote:
> The last time I saw a benchmark on immortal object, it was clearly 10%
> slower overall on the pyperformance benchmark suite. That's a major
> slowdown.
Yes, I plan on benchmarking the change as soon as we can run
pyperformance on main.
>
All singletons do, AFAIK. And most static types that I can think of also
do, even the empty tuple.
On Wed, 15 Dec 2021 at 16:49, Eric Snow wrote:
> On Wed, Dec 15, 2021 at 2:50 AM Pablo Galindo Salgado
> wrote:
> > One thing to consider: ideally, inmortal objects should not participate
> in
On Tue, Dec 14, 2021 at 11:19 AM Eric Snow wrote:
> The idea of objects that never get deallocated isn't new and has been
> explored here several times. Not that long ago I tried it out by
> setting the refcount really high. That worked. Around the same time
> Eddie Elizondo at Facebook did
On Wed, Dec 15, 2021 at 2:42 AM Christian Heimes wrote:
> Would it be possible to write the Py_INCREF() and Py_DECREF() macros in
> a way that does not depend on branching? For example we could use the
> highest bit of the ref count as an immutable indicator and do something like
As Antoine
On Wed, Dec 15, 2021 at 2:50 AM Pablo Galindo Salgado
wrote:
> One thing to consider: ideally, inmortal objects should not participate in
> the GC. There is nothing inheritly wrong if they do but we would need to
> update the GC (and therefore add more branching in possible hot paths) to
>
It might be worth (re)reviewing Sam Gross's nogil effort to see how he
approached this:
https://github.com/colesbury/nogil#readme
He goes into plenty of detail in his design document about how he deals
with immortal objects. From that document:
Some objects, such as interned strings, small
On Tue, Dec 14, 2021 at 7:27 PM Eric Snow wrote:
> We have some options:
>
> * live with the full penalty
> * make other changes to reduce the penalty to a more acceptable
> threshold than 5%
> * eliminate the penalty (e.g. claw back 5% elsewhere)
The last time I saw a benchmark on immortal
On Wed, Dec 15, 2021 at 2:21 AM Antoine Pitrou wrote:
>
> On Wed, 15 Dec 2021 10:42:17 +0100
> Christian Heimes wrote:
> > On 14/12/2021 19.19, Eric Snow wrote:
> > > A while back I concluded that neither approach would work for us. The
> > > approach I had taken would have significant cache
On Wed, 15 Dec 2021 10:42:17 +0100
Christian Heimes wrote:
> On 14/12/2021 19.19, Eric Snow wrote:
> > A while back I concluded that neither approach would work for us. The
> > approach I had taken would have significant cache performance
> > penalties in a per-interpreter GIL world. The
One thing to consider: ideally, inmortal objects should not participate in
the GC. There is nothing inheritly wrong if they do but we would need to
update the GC (and therefore add more branching in possible hot paths) to
deal with these as the algorithm requires the refcount to be exact to
On 14/12/2021 19.19, Eric Snow wrote:
A while back I concluded that neither approach would work for us. The
approach I had taken would have significant cache performance
penalties in a per-interpreter GIL world. The approach that modifies
Py_INCREF() has a significant performance penalty due
On Tue, Dec 14, 2021 at 4:09 PM Brett Cannon wrote:
> There's also the concern of memory usage if these immortal objects are never
> collected.
>
> But which objects are immortal? You only listed None, True, and False.
> Otherwise assume/remember I'm management and provide a list and/or link
On Tue, Dec 14, 2021 at 10:23 AM Eric Snow
wrote:
> Most of the work toward interpreter isolation and a per-interpreter
> GIL involves moving static global variables to _PyRuntimeState or
> PyInterpreterState (or module state). Through the effort of quite a
> few people, we've made good
35 matches
Mail list logo
