I suggest being a little more explicit (even blatant) that the particular
details of:
(1) which subset of functionally immortal objects are marked as immortal
(2) how to mark something as immortal
(3) how to recognize something as immortal
(4) which memory-management activities are skipped
On Thu, Feb 17, 2022 at 7:01 AM Eric Snow wrote:
>
> > > Also note that "fork" isn't the only operating system mechanism
> > > that uses copy-on-write semantics.
> >
> > Could you elaborate? mmap, maybe?
> > [snip[
> > So if you know how to get benefit from CoW without fork, I want to know it.
>
On Wed, Feb 16, 2022 at 2:41 PM Terry Reedy wrote:
> > * the naive implementation shows a 4% slowdown
>
> Without understanding all the benefits, this seems a bit too much for
> me. 2% would be much better.
Yeah, we consider 4% to be too much. 2% would be great.
Performance-neutral would be
On Wed, Feb 16, 2022 at 12:14 PM Kevin Modzelewski wrote:
> fwiw Pyston has immortal objects, though with a slightly different goal and
> thus design [1]. I'm not necessarily advocating for our design (it makes most
> sense if there is a JIT involved), but just writing to report our experience
Thanks for the feedback. My responses are inline below.
-eric
On Wed, Feb 16, 2022 at 6:36 AM Petr Viktorin wrote:
> Thank you very much for writing this down! It's very helpful to see a
> concrete proposal, and the current state of this idea.
> I like the change,
That's good to hear. :)
>
On Wed, Feb 16, 2022 at 12:37 AM Inada Naoki wrote:
> +1 for overall idea.
Great!
> > Also note that "fork" isn't the only operating system mechanism
> > that uses copy-on-write semantics.
>
> Could you elaborate? mmap, maybe?
> [snip[
> So if you know how to get benefit from CoW without fork,
On 2/15/2022 7:10 PM, Eric Snow wrote:
* the naive implementation shows a 4% slowdown
Without understanding all the benefits, this seems a bit too much for
me. 2% would be much better.
* we have a number of strategies that should reduce that penalty
I would like to see that before
Thanks!
On Wed, Feb 16, 2022 at 11:19 AM Kevin Modzelewski wrote:
> Importantly, our system allows for the reference count of immortal objects
> to change, as long as it doesn't go below half of the original very-high
> value. So extension code with no concept of immortality will still update
>
fwiw Pyston has immortal objects, though with a slightly different goal and
thus design [1]. I'm not necessarily advocating for our design (it makes
most sense if there is a JIT involved), but just writing to report our
experience of making a change like this and the compatibility effects.
I experimented with this at the EuroPython sprints in Berlin years ago.
I was sitting next to MvL, who had an interesting observation about it.
He suggested(*) all the constants unmarshalled as part of loading a
module should be "immortal", and if we could rejigger how we allocated
them to
Hi folks, PEP 655 (Required[] and NotRequired[] for TypedDict) is still
looking for feedback from core devs.
I've copied the latest PEP text at the bottom of this email to make it
easier to comment on.
Thank you for your time.
Best,
--
David Foster | Seattle, WA, USA
Contributor to Python's
On Tue, 15 Feb 2022, 2:57 am Petr Viktorin, wrote:
> >>
> >> Yes.
> >> On older Python versions, where the public API wasn't yet available,
> >> those backports use private API. If we change the private API in a
> >> point release, the backport will break.
> >
> > Do you have an example of this?
On 16. 02. 22 1:10, Eric Snow wrote:
Eddie and I would appreciate your feedback on this proposal to support
treating some objects as "immortal". The fundamental characteristic
of the approach is that we would provide stronger guarantees about
immutability for some objects.
A few things to
13 matches
Mail list logo
