Skip to content

dev call 20220303

Stepan Sindelar edited this page Mar 3, 2022 · 6 revisions

Dev Call: 3 March 2022

Present

Antonio, Simon, Ronan, Matti, Tim, Mohaned, Stepan, Florian

Agenda

HPyGlobal

  • Possible implementation: every global is basically just a per-interpreter token, e.g., an index into an array. Each interpreter would have its own instance of this array.
  • Allocation needs to be done per process (across all interpreters)
  • Possible "fast" mode: does not allow sub-interpreters and multiple interpreters in the same process but directly store the object's pointer in the global.
  • We would have some context functions to use the global
  • Open issue: how to do allocation of globals (e.g. generating a unique array index per process) if multiple interpreters are present. In this case, we would probably need to make it part of the HPy ABI (e.g. a counter variable).
  • Each interpreter then needs to initialize every global during module initialization.

Numpy Progress

  • Stepan started to migrate dtype
  • Main problem: HPy does not support meta types and CPython does also not support it for heap types.
  • There is a CPython issue for meta type support for heap types (10y old). It was recently brought up again.
  • We could ask if Victor could help us with this. Chances should be good since we now have concrete use cases.
  • Possible alternative solution: HPyType_FromSpec could also create a static type (but it will leak the struct)
  • For upstream changes, we would need backport to 3.8
  • Further problem: pure inheriting from built-in types * We need to align the artificial struct that contains PyObject/the builtin struct + the HPy struct, this is now done using "union hack", but that is not going to scale for all builtins(?), alternative: there is some POSIX API for getting memory alignment

Misc

  • Should HPy_Close silently ignore HPy_NULL ? To make a decision: we should change all Py_DECREF to Py_XDECREF and see what the impact is.
  • Kiwi, MPL perf was something like 25% worse than with C API. We need to investigate that anyway.
  • HPyContext.h_builtins: don't remove HPy_Repr and co; Florian will create an appropriate GH issue for that
  • Create issue for adding HPy_Eval
  • CPython 3.10 compatibility: we should address that. Moving most HPy flags to HPyType_Extra_t sounds good. But we still need a way to identify HPy types. We could ask CPython to reserve a type flag for us. An alternative would be to use e.g. a special tp_dealloc function.
  • HPyErr_FromFormat: continue discussion on the issue.
Clone this wiki locally