Thanks for the feedback. I've responded inline below. -eric
On Sat, Feb 19, 2022 at 8:50 PM Inada Naoki <songofaca...@gmail.com> wrote: > 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. I plan on addressing this in the PEP I am working on for per-interpreter GIL. In the meantime, I doubt the issue will impact any core devs. > 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`. I agree that immortal objects aren't quite as appealing in general without per-interpreter GIL. However, there are actual users that will benefit from it, assuming we can reduce the performance penalty to acceptable levels. For a recent example, see https://mail.python.org/archives/list/python-dev@python.org/message/B77BQQFDSTPY4KA4HMHYXJEV3MOU7W3X/. > On Sat, Feb 19, 2022 at 4:52 PM Eric Snow <ericsnowcurren...@gmail.com> wrote: > > > > Reducing CPU Cache Invalidation > > ------------------------------- > > > > Avoiding Data Races > > ------------------- > > > > Both benefits require a per-interpreter GIL. CPU cache invalidation exists regardless. With the current GIL the effect it is reduced significantly. Per-interpreter GIL is only one situation where data races matter. Any attempt to generally eliminate the GIL must deal with races on the per-object runtime state. > > > > 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. What do you mean by "this kind of change"? The proposed change is relatively small. It certainly isn't nearly as intrusive as many changes we make to internals without a PEP. If you are talking about the performance penalty, we should be able to eliminate it. > > 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. Correct. However, without immortal objects (AKA immutable per-object runtime-state) it goes from "very difficult" to "basically impossible". > > 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. The question is if this matters. If really necessary, the PEP can demonstrate that it doesn't matter in practice. (Also, the magic value on 32-bit would be 2**29.) > > > > 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). I think you understood it correctly. In the case of str objects, they are close enough since a race on any of those values will not cause a different outcome. I will clarify the point in the PEP. > > 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. There is no such thing as user-marked immortal objects. The concept is strictly an internal one, with no public API. > Additionally, if they are marked immortal for avoiding CoW, cleanup cause CoW. Correct. The PEP does not propose to deal with that situation. _______________________________________________ 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/JH2EWLUWOOQ2KKABVK6LD76TBYWPRHLG/ Code of Conduct: http://python.org/psf/codeofconduct/
