Em qua., 12 de mai. de 2021 às 14:45, Mark Shannon <m...@hotpy.org>
escreveu:
> Hi everyone,
>
> I would like to present PEP 659.
>
> This is an informational PEP about a key part of our plan to improve
> CPython performance for 3.11 and beyond.
>
> For those of you aware of the recent releases of Cinder and Pyston,
> PEP 659 might look similar.
> It is similar, but I believe PEP 659 offers better interpreter
> performance and is more suitable to a collaborative, open-source
> development model.
>
> As always, comments and suggestions are welcome.
>
>
Hi Mark,
I think this seems like a nice proposal... I do have some questions related
to the PEP though (from the point of view of implementing a debugger over
it some things are kind of vague to me):
1. When will the specialization happen? (i.e.: is bytecode expected to be
changed while the code is running inside a frame or must it all be done
prior to entering a frame on a subsequent call?)
2. When the adaptive specialization happens, will that be reflected on the
actual bytecode seen externally in the frame or is that all internal? Will
clients be able to make sense of that? -- i.e.: In the debugger right now I
have a need on some occasions to detect the structure of the code from the
bytecode itself (for instance to detect whether some exception would be
handled or unhandled at raise time just given the bytecode).
3. Another example: I'm working right now on a feature to step into a
method. To do that right now my approach is:
- Compute the function call names and bytecode offsets in a given frame.
- When a frame is called (during a frame.f_trace call), check the
parent frame bytecode offset (frame.f_lasti) to detect if the last thing
was the expected call (and if it was, break the execution).
This seems reasonable given the current implementation, where bytecodes are
all fixed and there's a mapping from the frame.f_lasti ... Will that still
work with the specializing adaptive interpreter?
4. Will it still be possible to change the frame.f_code prior to execution
from a callback set in `PyThreadState.interp.eval_frame` (which will change
the code to add a breakpoint to the bytecode and later call
`_PyEval_EvalFrameDefault`)? Note: this is done in the debugger so that
Python can run without any tracing until the breakpoint is hit (tracing is
set afterwards to actually pause the execution as well as doing step
operations).
Best regards,
Fabio
_______________________________________________
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/SP4LXKA2Y3LUCEGDUUX2RB3ZWM2JICKB/
Code of Conduct: http://python.org/psf/codeofconduct/
