dev call 20210708

Dev Call: 8 July 2021

Present

Florian, Antonio, Ronan, Matti, Simon

Possible HPy sprint in Linz

• Florian suggested organising a sprint in Linz, Austria in September.
• People are broadly in favour, but the world is complicated, so Florian will attempt to look into the details (dates, accommodation, venue) and once we have those we will see who can make it.

HPy 0.0.2

• The HPy version in the 0.0.2 branch is feature complete.
• The default ABI will be changed to universal on implementations other than CPython (so that building HPy extensions builds using the best ABI for the Python interpreter it is being built on by default).
• We would like to avoid having "pip install hpy" attempt to upgrade HPy on PyPy (or GraalPython).
• GraalPython already includes up to date 0.0.2 support and GraalPython 21.2 which will be released later this month (July) will include it.
• PyPy 0.0.2 support is almost complete.

HPy 0.0.3

• There was a discussion of what should be included in HPy 0.0.3.
• As a starting point, HPy 0.0.3 will be based on current master plus future changes.
• This means 0.0.3 will include Windows support.
• The first big new feature will be an implementation of HPyField.
• We're hoping to have 0.0.3 ready before the PyPy release in October.

Smaller HPyContext

• Florian mentioned that GraalPython has been experimenting with having a separate HPyContext per call so that the _private field can contain per-call JNI context.
• This works, but is slow because the HPyContext is currently large and so continually allocating it and copying it on the stack is slow.
• One of HPy's goals was to allow the context to be flexible enough for there to be a different context per-thread or potentially even per call, so it would be nice to support this use case better.
• Florian suggested a smaller context that points to a separate (shared) function table and possibly a separate (shared) table of common handles (e.g. h_None, h_True, etc).
• The advantage of this is that the context could become a lot smaller and the large tables would be shared.
• One downside is an extra layer of indirection is needed (e.g. ctx->api->ctx_Dup and ctx->handles->h_None) which is possibly slower and ctx->handles->h_None is not that nice to type (although possibly ctx->h->None is only slightly horrible).
• We need to just benchmark the indirection by trying it out.

Other recent HPy developments

• Matti is working on a Cython backend.
• Ronan is working on getting the current numpy port working on PyPy and will likely work on numpy more after that.