[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

[Itamar O]

+1 for consolidated documentation about per-interpreter GIL.

On Tue, Dec 14, 2021 at 9:12 AM Eric Snow 
wrote:

> Hi all,
>
> I'm still hoping to land a per-interpreter GIL for 3.11.  There is
> still a decent amount of work to be done but little of it will require
> solving any big problems:
>
> * pull remaining static globals into _PyRuntimeState and PyInterpreterState
> * minor updates to PEP 554
> * finish up the last couple pieces of the PEP 554 implementation
> * maybe publish a companion PEP about per-interpreter GIL
>
> There are also a few decisions to be made.  I'll open a couple of
> other threads to get feedback on those.  Here I'd like your thoughts
> on the following:
>
> Do we need a PEP about per-interpreter GIL?
>
> I haven't thought there would be much value in such a PEP.  There
> doesn't seem to be any decision that needs to be made.  At best the
> PEP would be an explanation of the project, where:
>

Even if there's no decision to be made, I think an informational PEP
would be valuable. Maybe even a Standards Track PEP? (since it
is technically a new feature)


>
> * the objective has gotten a lot of support (and we're working on
> addressing the concerns of the few objectors)
>
There's value in documenting the concerns and how they are being
addressed, and a PEP sounds like a good place to capture that.


> * most of the required work is worth doing regardless (e.g. improve
> runtime init/fini, eliminate static globals)
> * the performance impact is likely to be a net improvement
>
Also worth documenting that in the PEP (once there are benchmarks results).


> * it is fully backward compatible and the C-API is essentially unaffected
>
Since this is a likely concern, a PEP is a good place to address it.


>
> So the value of a PEP would be in consolidating an explanation of the
> project into a single document.  It seems like a poor fit for a PEP.
>

There is value in consolidating the project rationale, details, objections,
etc.
Is it a poor fit for a PEP? I don't know - is there a better alternative?
I guess it could be covered in the docs or devguide instead,
but I don't see a philosophical issue with using a PEP for this.


>
> (You might wonder, "what about PEP 554?"  I purposefully avoided any
> discussion of the GIL in PEP 554.  It's purpose is to expose
> subinterpreters to Python code.)
>
> However, perhaps I'm too close to it all.  I'd like your thoughts on the
> matter.


> Thanks!
>
> -eric
> ___
> 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/PNLBJBNIQDMG2YYGPBCTGOKOAVXRBJWY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/RK7B5NTBDRPEVKSTAF5TCL4N33RADZ5F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

[Itamar O]

On Wed, Dec 15, 2021 at 6:21 PM Guido van Rossum  wrote:

> On Wed, Dec 15, 2021 at 2:57 PM Guido van Rossum  wrote:
>
>>
>> I don't know how long that would take, but I suspect that a program that
>> just increments the refcount relentlessly would have to run for hours
>> before hitting this range. On a 64-bit machine the same approach would
>> require years to run before a refcount would exceed the maximum allowable
>> imbalance. (These estimates are from Mark Shannon.)
>>
>
> Hm, not quite. I modified a fast builtin to incref its argument, and then
> I called it in a `while True` loop, interrupted, and timed it. This did
> ~24,000,000 INCREFs/second. This would hit 0x_2000_ in about 9 minutes.
> And I wasn't even trying that hard -- I could have written the loop in C.
> (I did comment out an audit call though. :-) The same loop on 64-bit would
> take 1700 years to reach the limit, so we're safe there.
>

Similar 32-bit vs 64-bit overflow estimates were made by Victor Stinner in
the dict version tag PEP 509
https://www.python.org/dev/peps/pep-0509/#integer-overflow

tldr 4sec on 32-bit and 584 years on 64-bit
Granted, the risk there is only for *exactly* `2 ** (Nbits)` increments.


>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/2PQVABDBGJEKRBGVLOQEFY72KZO66W3J/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/QPZMYD3CWSML5IIWODVDZXARAQ3MYRX3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Itamar O]

On Sun, Apr 3, 2022 at 6:32 AM Nick Coghlan  wrote:

> On Fri, 1 Apr 2022, 6:47 pm Victor Stinner,  wrote:
>
>> On Wed, Mar 30, 2022 at 5:42 PM Guido van Rossum 
>> wrote:
>>
>> I'm not convinced that advertising an API as being Unstable (in the
>> documentation?) is going to solve any kind of problem. People love to
>> use private APIs, and they do it simply because it's technically
>> possible :-) At the end of the day, we have to help them updating
>> their code, otherwise we (at least my Red Hat team) cannot update
>> Python.
>>
>> I designed the internal C API to be more annoying to be used (need to
>> define a macro, need more specific #include) in the hope that people
>> will think twice before using it :-)
>>
>
>
> The changes you've made have been excellent, and the existing 3 categories
> (stable public ABI, stable public API, unstable internal API) cover the
> vast majority of cases.
>
> The final case that isn't quite covered yet is to offer a "semi-stable"
> API category for use cases that are intrinsically coupled to implementation
> details that may change between feature releases, but should remain stable
> within a release series.
>
> The concrete motivating example for the new category is the extra APIs you
> need in order to provide an alternative eval loop implementation.
>
> The internal API category doesn't properly cover that case, as the APIs
> there are free to change even in maintenance releases, and setting
> Py_BUILD_CORE exposes a lot more than what an alternative eval loop would
> need.
>
> Regular public functions may work in some cases, but aren't necessarily
> practical in others (such as exposing the internal frame details for use in
> alternative eval loops).
>
> From an implementation PoV, my own suggestion would be to define a new API
> tier with an opt-in macro rather than relying solely on documentation or
> naming conventions.
>
> For example, define "Py_SEMI_STABLE_API" to opt in, with the headers under
> "Include/cpython/semi_stable/" (I don't like "unstable" as potential
> terminology here, since the internal API is already unstable - we're
> splitting the difference between that and the long term stability of the
> full public API)
>
> Cheers,
> Nick.
>

+1 for an official "semi stable API tier".
It's already the case that essentially anything in Python can change,
it's just a question of how quickly and with how much friction.
Public APIs need to go through a multi-version deprecation cycle
(https://peps.python.org/pep-0387/#making-incompatible-changes).
Private internal APIs can (theoretically) change without notice between
patch releases.
There's a missing tier for APIs that can change without notice between
feature releases,
but are guaranteed(*) to be backwards compatible within a feature release,
and the PEP 523 frame evaluation API is an excellent example for this need
(maybe any newly added API should always go through this stage for a few
releases?).

Even though the docs (
https://docs.python.org/3.10/c-api/intro.html#include-files) explicitly
call out that _Py-prefixed APIs are internal and should not be used by
extensions,
this isn't the case in practice, so introducing the 3-tier concept could be
an opportunity
to clean up this situation a bit.
What exactly should be the naming conventions per tier, and the names of
the tiers,
is bikeshedding that should happen after there's agreement about the tiers
concept :-)

(*) "guaranteed" with exceptions of course (e.g. security or other critical
issue)


>
>
>
>> Victor
>> ___
>> 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/YCHLFQ5KW6XF5C5CFWF4MRTZEXVBZBMA/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/ZBNJTAXS6TWQY7QH5H5XZS4CP64ZQAUU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/DQ5AUS3UBQGJV6YLQ4CJ5F5M7RWFC7DY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Lazy Imports [was: Declarative imports]

[Itamar O]

Breaking out the discussion about lazy imports.
It seems somewhat OT in the declarative imports thread.

On Mon, Apr 11, 2022 at 10:50 AM Barry Warsaw  wrote:

> Thanks Carl,
>
> > On Apr 9, 2022, at 08:25, Carl Meyer  wrote:
> >
> > Our experience in practice, though, has been that universally lazy
> > imports is somewhat easier to adopt than Strict Modules, and has had a
> > much bigger overall impact on reducing startup time for big CLIs (and
> > a big web server too; as you note it's not as serious an issue for a
> > web server in production, but restart time still does make a
> > difference to dev speed / experience.)
>
> Excellent point about the impact of restarts and development time.  That’s
> been an issue for us a bit, but not an overwhelming motivation to rewrite
> in other languages[1].
>

Lazy imports had been very significant to both CLI startup time, as
well as service reload time during local development - we have
more details in the docs [1], and a related blog post coming up soon.


>
> > Removing slow stuff happening
> > at import time helps, but it'll never match the speed of not doing the
> > import at all! We've seen startup time improvements up to 70% in
> > real-world CLIs just by making imports lazy. We've also opened an
> > issue to discuss the possibility of upstreaming this. [2]
> >
> > [1] https://github.com/facebookincubator/cinder/#strict-modules
> > [2] https://bugs.python.org/issue46963
>
> Post-GH-issues-migration link for the issue:
> https://github.com/python/cpython/issues/91119
>
> I’ve put some questions and comments there, but I’m also really curious
> about the technical details for your lazy imports.  Have you gotten as far
> as thinking about a PR or PEP?
>

Yes and Yes (at least for the "thinking about" part).
Germán Méndez Bravo (Kronuz) will be drafting a PEP,
and is leading work internally to port this from 3.8 (first
to 3.10, then to the cpython main branch).
We are planning to get started on this during PyCon sprints,
it would be nice to connect in-person with anyone who's
interested in this and happens to be in the sprints too!


>
> -Barry
>
> [1] Not that there aren’t other reasons folks give for rewriting, such as
> multicore performance, ecosystem alignment (e.g. SREs being more
> comfortable in Go), etc.
>

Itamar.

[1]
https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/lazy_imports.rst#lazy-imports
___
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/NIXH574H64DXEXNZK6NDOGNZKQQPUDYM/
Code of Conduct: http://python.org/psf/codeofconduct/