Hi Gabriele, >> So this makes me wonder if it would make sense for CPython to ensure frame objects are created in a contiguous block of memory (perhaps there could be benefits from the locality of reference, although it's not obvious to me why this would be the case at the moment).
That's already the case for 3.11: we currently allocate frames in a continuous, per thread stack (it includes some of the frame memory and arrays apart from the frames themselves). Check this for more details: https://github.com/python/cpython/pull/27077 Also, don't rely on this on any way or form as this code can and will likely change a lot (even between patch versions if we found bugs). Regards from rainy London, Pablo Galindo Salgado On Mon, 20 Dec 2021, 21:43 Gabriele, <phoenix1...@gmail.com> wrote: > Brandt, Guido, Pablo > > Many thanks for your helpful answers. Indeed I'm asking because I just > finished working on some improvements to Austin and got back to looking > into what was coming in order to add support for 3.11 (plus make use of > some of the changes that I recently contributed, like > PyThreadState.native_thread_id, Py_Version and code.co_qualname). Pablo's > suggestion of waiting until 3.11 becomes more stable is a sensible one, but > in the meantime I wanted to understand where the frame stack management is > heading to at least have an idea of what's in store for Austin :). I'm very > much satisfied by all the details in your replies as they answer all my > questions, for now, so thanks a lot for that. > > A final thought: I have discussed some of the technical details of the > recent improvements to Austin in a blog post ( > https://p403n1x87.github.io/increasing-austin-accuracy-with-a-dobule-heap-trick.html). > My experiments seem to suggest that, the less sparse the frame objects are > in memory, the more accurate tools like Austin can be. So this makes me > wonder if it would make sense for CPython to ensure frame objects are > created in a contiguous block of memory (perhaps there could be benefits > from the locality of reference, although it's not obvious to me why this > would be the case at the moment). > > Best, > Gabriele > > > On Mon, 20 Dec 2021 at 20:16, Pablo Galindo Salgado <pablog...@gmail.com> > wrote: > >> Hi Gabriele, >> >> In addition to what Guido and Brandt have already said, I can help to you >> adapting Austin to 3.11 as I reviewed or authored some of these changes and >> I have already been helping some projects do the relevant changes as well >> as in my own tools. >> >> What you want to do si the following for unwinding: >> >> * Go from _PyRuntime -> PyThreadState -> CFrame -> current_frame >> >> This will lead you to s PyInterpreterFrame that you should use for >> unwinding the entire thread stack. The difference is that cframe->previous >> will skip you several frames as it points to the previous CFrame, but there >> are a one to many relationships between CFrame and interpreter frames >> because several python functions can now reuse the same evaluation loop. >> >> Also, I would recommend waiting until beta freeze to start adapting >> anything as things can still massively change until then for 3.11. >> >> If you have any questions or you need help, feel free to ping me in >> GitHub if you want. >> >> Regards from rainy London, >> Pablo Galindo Salgado >> >> >> >> On Mon, 20 Dec 2021, 18:27 Gabriele, <phoenix1...@gmail.com> wrote: >> >>> Hi there >>> >>> I hope you would indulge me in asking for some details about the new >>> CFrame structure, even in the form of existing literature (e.g. PEP) >>> where the idea behind it is explained. >>> >>> Also, I'd like to a quick question, if I may. There now appear to be >>> two ways of unwinding the frame stack: either iterate over >>> CFrame.previous, or the more traditional PyFrameObject.f_back. I >>> suspect there are reasons why these are perhaps not actually >>> equivalent, and indeed this is mainly what I'd like to read in the >>> literature I've requested above. >>> >>> Cheers, >>> Gabriele >>> >>> -- >>> "Egli è scritto in lingua matematica, e i caratteri son triangoli, >>> cerchi, ed altre figure >>> geometriche, senza i quali mezzi è impossibile a intenderne umanamente >>> parola; >>> senza questi è un aggirarsi vanamente per un oscuro laberinto." >>> >>> -- G. Galilei, Il saggiatore. >>> _______________________________________________ >>> 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/KQOQTLR5IXMJXYZGPDHWR32I2Z53UVBL/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> > > -- > > > *"Egli è scritto in lingua matematica, e i caratteri son triangoli, > cerchi, ed altre figuregeometriche, senza i quali mezzi è impossibile a > intenderne umanamente parola;senza questi è un aggirarsi vanamente per un > oscuro laberinto."* > > *-- *G. Galilei*, Il saggiatore.* > _______________________________________________ > 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/YBAMU2YESAL66DB7CPG6JXJWQMFO2HNN/ > 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/OKXZDQLMZYXHPBXPWMHVJ7ZHWDTJEYXZ/ Code of Conduct: http://python.org/psf/codeofconduct/
