hpyproject / hpy

HPy: a better API for Python
https://hpyproject.org
MIT License
1.02k stars 52 forks source link

Smaller HPyContext to prepare it for stack-allocation. #330

Open fangerer opened 2 years ago

fangerer commented 2 years ago

We discussed having a stack-allocated context some time ago but never really made a decision nor summarized everything. I wrote a document about that. Since that seemed to be a too long for an issue description, the document can be found in the Wiki: https://github.com/hpyproject/hpy/wiki/Stack-allocated-HPyContext

antocuni commented 2 years ago

I read the wiki but I'm a bit confused about the terminology. If I understand it correctly, we are talking about two different things:

  1. the layout of HPyContext: here the question is basically whether we want a single or double indirection is this correct?
  2. how to allocate HPyContext: this is the stack vs heap allocation discussion, but again if I understand correctly it's a graalpython specific discussion, isn't it? E.g., for CPython and PyPy the HPyContext will likely continue to be a singleton.

And the link between (1) and (2) is that stack allocation is possible only if sizeof(HPyContext) is small, i.e. only if we use double indirection.

Is my summary correct, or I am missing anything?

fangerer commented 2 years ago

Concerning the link: yes.

You are right. If we change the context layout to what I've suggested, then other runtimes are still free to allocate the context on the heap. I'll try to make that clear in the document ASAP.

antocuni commented 2 years ago

I am not opposed to change the layout of HPyContext, but the first thing to do is to measure the performance penalty and then decide based on that (especially on CPython)

fangerer commented 2 years ago

I absolutely agree. I will design various benchmarks.

hodgestar commented 1 year ago

One way to make the context slightly smaller would be to replace the ctx->h_None and similar handles with a fixed list of constant handles. This would be most awkward on CPython where the handles currently really are pointers.