ronny has quit [Ping timeout: 248 seconds]
jboi has quit [Ping timeout: 240 seconds]
jevinskie[m] has quit [Ping timeout: 260 seconds]
jboi has joined #hpy
ronny has joined #hpy
jevinskie[m] has joined #hpy
<antocuni> Mark Shannon talked about the "Faster CPython team": https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit_2.html
<antocuni> this sentence is a bit worrying:
<antocuni> "The optimisation work that has been done in CPython 3.11 has largely ignored the question of extension modules, but Shannon now wants to open up the possibility of exposing low-level function APIs to the virtual machine, reducing the overhead time of communicating between Python code and C code."
<antocuni> I've sent an email to Mark to ask for more info
<steve_s> low-level function APIs to the virtual machine == sealing the door for further improvements of the virtual machine :( when will we ever learn, when will we ever learn
<antocuni> let's see what is it before making conclusions
<Hodgestar> antocuni: I was also a bit worried by some of the statements in the "Faster CPython" report. E.g. they also seem to be knowingly breaking Sam's nogil work. I've seen that pattern in coporate coding quite a bit -- one team moves quickly achieving their goals but ignoring "external" breakages, the moving team succeeds and merges lots of changes and other maybe more important work can't get merged. But I'm more worried by past experiences than by any
<Hodgestar> concrete knowledge.
<Hodgestar> antocuni: I guess that there will be pressure to expose new low-level things in the C API because CPython is a big consumer of the C API and also wants to make numpy, etc faster. I'm glad you reached out to Mark -- it's not necessarily a bad thing to add things to the C API, but it is a bad idea to add more bad things to the C API. Maybe HPy will not really care though -- we already support a lot of bad things. :)
<antocuni> another interesting talk about immortal objects: https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit_11.html
<antocuni> and this is another case in which refcounting is a hindrance, good selling point for HPy
<Hodgestar> Indeed.
<antocuni> well, depending on what are these low level APIs to the virtual machine, they might be impossible to implement on graalpython and pypy
<Hodgestar> I thought that maybe immortal objects would be useful to HPy somehow (e.g. not having to dup some specific common objects might make the code written using HPy simpler at times).
<antocuni> wait, immortal objects != immortal handles
<antocuni> my point is that immortal objects are straightforward in a pure hpy world
<Hodgestar> antocuni: Agreed. But if an object is immortal, would one need an ordinary handle?
<antocuni> yes, why not?
<Hodgestar> Because HPy_Dup(ctx, ctx->None) is annoying? :)
<antocuni> "not having to close a handle" sounds like a nice shortcut for the user, but something which doesn't bring any benefit to the VM
<Hodgestar> Maybe having to remember two classes of objects is annoying too though.
<antocuni> agreed about dup(None), we should just introduce HPy_RETURN_NONE :)
<antocuni> also, your idea doesn't really work because it would be tied to the handle, not to the object
<antocuni> like, I receive a handle; how do I know whether I need to close it or not?
<antocuni> does it depends on the type of the object it points to?
<antocuni> does it depend on the C type of the handle itself?
<antocuni> suddenly, HPy_Dup(ctx, ctx->None) looks less annoying than that :)
<steve_s> Internally, graal python ignores dup/close for the context constants and may as well for more well known handles. CPython with its immortal objects can do the same. I think the interface should be generic and those opts left out to the VM. The only sad thing is that in such case we still incur the overhead of dispatching to ctx_Close, which then concludes that it does not have to do anything