pmp-p has quit [Ping timeout: 255 seconds]
<fangerer> Good Morning! We already started the meeting. Please join if you have time.
<phlebas> antocuni: are you joining?
<mattip> for uploading new "versions" of a pypi package, you can use build numbers
<mattip> so you can have hpy-0.0.4.tar.gz, hpy-1-0.0.4.tar.gz, hpy-2-0.0.4.tar.gz, ...
<antocuni> ouch sorry, I'm online only now
<antocuni> are you still in the call?
<antocuni> I cannot find any reference to PyIdentifier in either the docs or the source code, can you post a link?
<phlebas> antocuni: `Include/cpython/object.h:46: #define _Py_IDENTIFIER(varname) _Py_static_string(PyId_##varname, #varname)`
<antocuni> ah ok, I was grepping for PyIdentifier :). Thanks
<phlebas> antocuni: did you see the numbers for kiwi solver and matplotlib on the hpy call wiki? those are cool, because hpy cpython abi mode is the same speed as the original code, and universal is only minimally slower
<antocuni> no, only the numpy ones I think
<phlebas> i'm running the benchmarks for numpy just now, i'll post the numbers later
<antocuni> ok thanks
<phlebas> antocuni: i mean those graphs i linked here: https://github.com/hpyproject/hpy/wiki/dev-call-20220407
<phlebas> i can send you the pyperf json files, if you want to generate your own graphs or so
pmp-p has joined #hpy
<antocuni> what are the modules which have been ported to HPy so far? numpy, matplotlib, kiwi? Anything else?
<antocuni> also, numpy is only partially ported, right?
<steve_s> we can also publish the psutils port.. I've migrated the linux and macos native modules
<steve_s> ultrajson?
<steve_s> I'd call the numpy port a feasibility study, it is quite far from actual proper port...
<antocuni> right
<antocuni> is matplotlib fully ported?
<antocuni> in my presentation, it would be nice to show a quote from someone who actually did some of the ports
<antocuni> like:
<antocuni> "Porting matplotlib to HPy has been an amazing experience (5 stars)" 😂
<steve_s> iirc apart from parts that use numpy API... Only psutils and kiwi solver can run on pure universal
<steve_s> :D
<antocuni> right, because if we use the legacy APIs, out universal mode is still "fake"
<steve_s> with numpy we load dummy libpython.so in GraalPython to make the linker happy and as long as none of the C API is called it runs in "pure" universal, any call to C API usually crashes the thing
<antocuni> ah I see
<antocuni> this pattern looks useful enough that might be worth to "officialize" it
<antocuni> I imagine a situation like this; a module can use (a) only HPy API or (b) both HPy and legacy API
<antocuni> and when compiling you can target (1) CPython ABI or (2) HPy ABI
<antocuni> in case 2a, you get a pure universal binary
<antocuni> in case 2b, you get a hybrid binary which is specific to a CPython/PyPy/GraalPython version
<antocuni> but we might also want a case 2c, in which you get a pure universal binary that can be loaded by any HPy-compatible interpreter and crashes cleanly at runtime if you actually call a legacy API
<antocuni> although it looks hard to implement
<fangerer> I think it's basically not *hard*. All we need is a dummy-lib that provides all the `Py*` symbols. I think we could generated that from CPython. The hard part is rather that we need a dummy lib for each Python version.
<antocuni> and we need to ensure the "clean crash", which might be hard for some APIs which are not supposed to fail
<antocuni> I would like to say "HPy can be up to X times faster than C-API on GraalPython"
<antocuni> what is a reasonable value for "X"?
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #hpy
<antocuni> here are the slides of my hpy talk; with the following link you can comment, I hope I won't get too much spam :)
<antocuni> please review if you feel like