Hi,
I hope per-interpreter GIL success at some point, and I know this is
needed for per-interpreter GIL.
But I am worrying about per-interpreter GIL may be too complex to
implement and maintain for core developers and extension writers.
As you know, immortal don't mean sharable between interpreters. It is
too difficult to know which object can be shared, and where the
shareable objects are leaked to other interpreters.
So I am not sure that per interpreter GIL is achievable goal.
So I think it's too early to introduce the immortal objects in Python
3.11, unless it *improve* performance without per-interpreter GIL
Instead, we can add a configuration option such as
`--enalbe-experimental-immortal`.
On Sat, Feb 19, 2022 at 4:52 PM Eric Snow wrote:
>
> Reducing CPU Cache Invalidation
> ---
>
> Avoiding Data Races
> ---
>
Both benefits require a per-interpreter GIL.
>
> Avoiding Copy-on-Write
> --
>
> For some applications it makes sense to get the application into
> a desired initial state and then fork the process for each worker.
> This can result in a large performance improvement, especially
> memory usage. Several enterprise Python users (e.g. Instagram,
> YouTube) have taken advantage of this. However, the above
> refcount semantics drastically reduce the benefits and
> has led to some sub-optimal workarounds.
>
As I wrote before, fork is very difficult to use safely. We can not
recommend to use it for many users.
And I don't think reducing the size of patch in Instagram or YouTube
is not good rational for this kind of change.
> Also note that "fork" isn't the only operating system mechanism
> that uses copy-on-write semantics. Anything that uses ``mmap``
> relies on copy-on-write, including sharing data from shared objects
> files between processes.
>
It is very difficult to reduce CoW with mmap(MAP_PRIVATE).
You may need to write hash of bytes and unicode. You may be need to
write `tp_type`.
Immortal objects can "reduce" the memory write. But "at least one
memory write" is enough to trigger the CoW.
> Accidental Immortality
> --
>
> While it isn't impossible, this accidental scenario is so unlikely
> that we need not worry. Even if done deliberately by using
> ``Py_INCREF()`` in a tight loop and each iteration only took 1 CPU
> cycle, it would take 2^61 cycles (on a 64-bit processor). At a fast
> 5 GHz that would still take nearly 500,000,000 seconds (over 5,000 days)!
> If that CPU were 32-bit then it is (technically) more possible though
> still highly unlikely.
>
Technically, `[obj] * (2**(32-4))` is 1GB array on 32bit.
>
> Constraints
> ---
>
> * ensure that otherwise immutable objects can be truly immutable
> * be careful when immortalizing objects that are not otherwise immutable
I am not sure about what this means.
For example, unicode objects are not immutable because they have hash,
utf8 cache and wchar_t cache. (wchar_t cache will be removed in Python
3.12).
>
> Object Cleanup
> --
>
> In order to clean up all immortal objects during runtime finalization,
> we must keep track of them.
>
I don't think we need to clean up all immortal objects.
Of course, we should care immortal by default objects.
But for user-marked immortal objects, it's very difficult to guarantee
__del__ or weakref callback is called safely.
Additionally, if they are marked immortal for avoiding CoW, cleanup cause CoW.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7FCNNQOTIUZTBFZUPYRDSLND6WCVM3JO/
Code of Conduct: http://python.org/psf/codeofconduct/
