dev call 20230413

Dev Call: 13 April 2023

Present

Du Toit, Florian, Tim, Lysandros, Antonio, Simon, Petr

Agenda

Still working on the release 0.9.

• Merged PRs:

  • Support vectorcall protocol

• PRs in progress:

  • Extend HPy call API

• Numpy/HPy

  • still open:

    HPy HPySeqIter_New(HPyContext *ctx, HPy seq);
    

  • Florian is looking into NumPy/HPy performance of the game-of-life example and NumPy's benchmarks.

  • Some preliminary numbers on numpy-gol.py:

    Machine: 2,6 GHz 6-Core Intel Core i7, 32 GB 2667 MHz DDR4 (MacOS 12.6.3)

    Payload: NumPy array 180x180 dtype=int64

    NumPy (C API)	NumPy/HPy (CPython ABI)	NumPy/HPy (Hybrid ABI)
    728 us +- 5 us	992 us +- 20 us	1240 us +- 150 us

Numpy/HPy

• Concerning the preliminary numbers of the numpy-gol.py example: NumPy/HPy (CPython ABI) is roughly 35 % slower than vanilla NumPy. Even if this doesn't look very good at a first glance, one needs to keep in mind that the GraalPy team focused on making migration progress instead of carefully thinking about the performance implications of every change. The migration project was and still is much more an extensive proof-of-concept to learn what APIs we need and if there are fundamental problems.
• Florian asks: how to proceed with Numpy/HPy ? There are several options:
  1. Initiate upstreaming of heap type migration
  2. Make all tests pass
  3. Look into performance (goal: less than 5% slower compared to vanilla NumPy)
• We agreed on going for the first option and start upstreaming of heap type migration. This should also give us a better basis for performance comparisons since heap types may also have an impact.
  • Antonio asked Petr, if heap types are the preferred way to define types.
  • Petr says: yes. Unfortunately, the current C API tutorial still uses static types and it is on the agenda to change that.
• ACTION ITEM for Simon: porting the CPython C API tutorial
• Simon suggests to write (micro) benchmarks to get an idea how fast single operations are in comparison to the C API. Florian points out that NumPy's benchmark suite is doing that already for (at least) NumPy operations. But it still makes sense to add more (micro) benchmarks in HPy itself for something like HPy_GetItem_i (e.g. comparing to PyTuple_GET_ITEM).
• Florian: should we have API like PySeqIter_New ?
  • Petr pointed out that there are plans to introduce some kind of protocol to access sequences (see this thread)
  • It seems that we should not provide the old iter API since there is a good chance that even CPython will replace it by something similar to HPy protocols (which we plan to do anyway).