[Python-Dev] frame evaluation API PEP

[Guido van Rossum]

On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon <brett at python.org> wrote:

>
>
> On Sat, 18 Jun 2016 at 21:49 Guido van Rossum <guido at python.org> wrote:
>
>> Hi Brett,
>>
>> I've got a few questions about the specific design. Probably you know the
>> answers, it would be nice to have them in the PEP.
>>
>
> Once you're happy with my answers I'll update the PEP.
>

Soon!


>
>
>>
>> First, why not have a global hook? What does a hook per interpreter give
>> you? Would even finer granularity buy anything?
>>
>
> We initially considered a per-code object hook, but we figured it was
> unnecessary to have that level of control, especially since people like
> Numba have gotten away with not needing it for this long (although I
> suspect that's because they are a decorator so they can just return an
> object that overrides __call__()).
>

So they do it at the function object level?


> We didn't think that a global one was appropriate as different workloads
> may call for different JITs/debuggers/etc. and there is no guarantee that
> you are executing every interpreter with the same workload. Plus we figured
> people might simply import their JIT of choice and as a side-effect set the
> hook, and since imports are a per-interpreter thing that seemed to suggest
> the granularity of interpreters.
>

I like import as the argument here.


>
> IOW it seemed to be more in line with sys.settrace() than some global
> thing for the process.
>
>
>>
>> Next, I'm a bit (but no more than a bit) concerned about the extra 8
>> bytes per code object, especially since for most people this is just waste
>> (assuming most people won't be using Pyjion or Numba). Could it be a
>> compile-time feature (requiring recompilation of CPython but not
>> extensions)?
>>
>
> Probably. It does water down potential usage thanks to needing a special
> build. If the decision is "special build or not", I would simply pull out
> this part of the proposal as I wouldn't want to add a flag that influences
> what is or is not possible for an interpreter.
>

MRAB's response made me think of a possible approach: the co_extra field
could be the very last field of the PyCodeObject struct and only present if
a certain flag is set in co_flags. This is similar to a trick used by X11
(I know, it's long ago :-).

>
>
>> Could you figure out some other way to store per-code-object data? It
>> seems you considered this but decided that the co_extra field was simpler
>> and faster; I'm basically pushing a little harder on this. Of course most
>> of the PEP would disappear without this feature; the extra interpreter
>> field is fine.
>>
>
> Dino and I thought of two potential alternatives, neither of which we have
> taken the time to implement and benchmark. One is to simply have a hash
> table of memory addresses to JIT data that is kept on the JIT side of
> things. Obviously it would be nice to avoid the overhead of a hash table
> lookup on every function call. This also doesn't help minimize memory when
> the code object gets GC'ed.
>

I guess the prospect of the extra hash lookup per call isn't great given
that this is about perf...

>
> The other potential solution we came up with was to use weakrefs. I have
> not looked into the details, but we were thinking that if we registered the
> JIT data object as a weakref on the code object, couldn't we iterate
> through the weakrefs attached to the code object to look for the JIT data
> object, and then get the reference that way? It would let us avoid a more
> expensive hash table lookup if we assume most code objects won't have a
> weakref on it (assuming weakrefs are stored in a list), and it gives us the
> proper cleanup semantics we want by getting the weakref cleanup callback
> execution to make sure we decref the JIT data object appropriately. But as
> I said, I have not looked into the feasibility of this at all to know if
> I'm remembering the weakref implementation details correctly.
>

That would be even slower than the hash table lookup, and unbounded. So
let's not go there.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160619/4848f1dd/attachment.html>