Hi Fabio,
On 13/05/2021 7:11 pm, Fabio Zadrozny wrote:
Em qua., 12 de mai. de 2021 às 14:45, Mark Shannon <m...@hotpy.org
<mailto: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?)
The specialization is adaptive, so it can happen at anytime during
execution.
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).
The bytecode, as externally visible, will be unchanged. All
specializations will be internal and should be invisible to all Python
tools.
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?
If you are implementing this in Python, then everything should work as
it does now.
OOI, would inserting a breakpoint at offset 0 in the callee function
work?
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).
Since frame.f_code is read-only in Python, I assume you mean in C.
I can make no guarantees about the layout or meaning of fields in the C
frame struct, I'm afraid.
But I'm sure we can get something to work for you.
Cheers,
Mark.
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/JLD3PDRU6YXPIGXVUDE3JP4EEBI2PWJ7/
Code of Conduct: http://python.org/psf/codeofconduct/
