#hpy on 2022-04-30 — irc logs at libera.irclog.whitequark.org

2021-05-27 19:57 antocuni changed the topic of #hpy to: https://hpyproject.org - https://github.com/hpyproject/hpy - IRC logs: https://libera.irclog.whitequark.org/hpy

01:09 GianlucaRizzo has joined #hpy

01:30 GianlucaRizzo has quit [Remote host closed the connection]

04:00 dalley has quit [Quit: Leaving]

10:46 GianlucaRizzo has joined #hpy

11:18 GianlucaRizzo has quit [Remote host closed the connection]

11:19 GianlucaRizzo has joined #hpy

11:24 GianlucaRizzo has quit [Ping timeout: 276 seconds]

11:45 GianlucaRizzo has joined #hpy

11:45 GianlucaRizzo has quit [Remote host closed the connection]

11:46 GianlucaRizzo has joined #hpy

11:51 GianlucaRizzo has quit [Ping timeout: 256 seconds]

11:56 <antocuni> cfbolz: do you have reasons to think that the JIT would not work out of the box?

11:57 <cfbolz> antocuni: eg can these objects be virtual?

11:58 <cfbolz> or they can never be, because they come from C code always

11:58 <antocuni> that's a good question

11:58 <antocuni> in theory it's possible to create these objects from Python code

11:58 <antocuni> I mean, not just in theory, in practice it will happen all the time

11:58 <antocuni> e.g. if you call numpy.zeros()

11:59 <cfbolz> but some C code needs to run, I assume

11:59 <antocuni> yes

11:59 <antocuni> you need to provide them some real memory

11:59 <cfbolz> pity ;-)

12:00 <antocuni> I think that currently what happens is that W_HPyObject is virtual, but hpy_data is malloc()ed anyway

12:00 <antocuni> cfbolz: we can always interpret and trace the C code :)

12:00 <cfbolz> graalpython does that

12:00 <cfbolz> but well

12:00 <cfbolz> its own mess

12:01 <antocuni> anyway, a varsized W_HPyObject which embeds the "C" memory will still be a win over the current situation

12:01 <cfbolz> antocuni: ok

12:01 <antocuni> even if you can't virtualize it

12:01 <cfbolz> Does reading a field from the varsized part always go via C?

12:02 <antocuni> good question

12:02 <antocuni> from the hpy point of view, you don't know what's inside the memory blob

12:02 <antocuni> so yes

12:02 <cfbolz> Ok

12:03 <cfbolz> (sorry, I'm not up to date on hpy at all)

12:03 <antocuni> ah no wait

12:03 <cfbolz> you need to know where gcrefs are at least

12:03 <antocuni> I think there is already a way to define "fields"

12:03 <antocuni> but I don't remember the name of those

12:04 <antocuni> ah, "members" I think

12:04 <cfbolz> Ok

12:05 <antocuni> yes exactly. You can define a member (as you do in CPython) and say that at offset X there is a int

12:05 <antocuni> so reading/writing that doesn't go through C

12:05 <antocuni> but I suspect it's not very common

12:06 <cfbolz> Ok

12:24 <cfbolz> antocuni: if it ever becomes common, we could like the JIT to be able to eg optimize away reading the same field twice

12:28 <antocuni> right

12:29 <antocuni> or reading after writing

12:34 GianlucaRizzo has joined #hpy

13:03 <cfbolz> yep

13:19 Gianluca_ has joined #hpy

13:19 GianlucaRizzo has quit [Remote host closed the connection]

13:19 Gianluca_ has quit [Remote host closed the connection]

13:19 GianlucaRizzo has joined #hpy

13:27 GianlucaRizzo has quit [Ping timeout: 272 seconds]

13:52 GianlucaRizzo has joined #hpy

14:50 GianlucaRizzo has quit [Remote host closed the connection]

14:54 GianlucaRizzo has joined #hpy

15:00 GianlucaRizzo has quit [Remote host closed the connection]

15:15 GianlucaRizzo has joined #hpy

15:21 GianlucaRizzo has quit [Ping timeout: 256 seconds]

15:29 DuToit has joined #hpy

18:18 GianlucaRizzo has joined #hpy

18:23 GianlucaRizzo has quit [Ping timeout: 246 seconds]

19:30 DuToit has quit [Read error: Connection reset by peer]

19:30 DuToit has joined #hpy

19:44 DuToit has quit [Read error: No route to host]

22:38 GianlucaRizzo has joined #hpy

22:38 GianlucaRizzo has quit [Remote host closed the connection]

23:26 mattip has quit [Ping timeout: 276 seconds]