[Numpy-discussion] Proposal to accept NEP 49: Data allocation strategies

[Sebastian Berg]

On Mon, 2021-05-10 at 10:01 +0100, Eric Wieser wrote:
> > The Python version of this does have a `void *ctx`, but I am not
> > sure if
> the use for this is actually valuable for the NumPy use-cases.
> 
> Do you mean "the CPython version"? If so, can you link a reference?

Yes, sorry, had been a while since I had looked it up:

https://docs.python.org/3/c-api/memory.html#c.PyMemAllocatorEx

That all looks like it can be customized in theory. But I am not sure
that it is practical, except for hooking and calling the previous one.
(But we also have tracemalloc anyway?)  I have to say it feels a bit
like exposing things publicly, that are really mainly used internally,
but not sure...  Presumably Python uses the `ctx` for something though.


> 
> >  While I like the `PyObject *` idea, I am also not sure that it
> > helps
> much.  If we want allocation specific state, the user should
> overallocate
> and save it before the actual allocation.
> 
> I was talking about allocator- not allocation- specific state. I
> agree that
> the correct place to store the latter is by overallocating, but it
> doesn't
> make much sense to me to duplicate state about the allocator itself
> in each
> allocation.
> 

Right, I don't really know a use-case right now.  But I am fine with
saying: lets pass in some state anyway, to future-proof.  Although if
we ensure that the API can be extended, even that is probably not
really necessary, unless we have a faint idea how it would be used?

(I guess the C++ similarity may be a reason, but I am not familiar with
that.)
  

> > But if we don't mind the churn it creates, the only serious idea I
> > would
> have right now is using a `FromSpec` API. We could allow get/set
> functions
> on it though
> 
> We don't even need to go as far as a flexible `FromSpec` API. Simply
> having
> a function to allocate (and free) the opaque struct and a handful of
> getters ought to be enough to let us change the allocator to be
> stateful in
> future.
> On the other hand, this is probably about as much work as just making
> it a
> PyObject in the first place.

Yeah, if we don't expect things to grow often/much, we can just use
what we have now and either add `NULL` argument at the end and/or just
make a new function when we need it.

The important part would be returning a new struct.  I think even
opaque is not necessary!
If we return the new struct, we can extend it freely and return NULL to
indicate an error (thus being able to deprecate if we have to).

Right now we don't even have getters in the proposal IIRC, so that part
probably just doesn't matter either.  (If we want to allow to fall back
to the previous allocator this would have to be expanded.)


I agree that `PyObject *` is probably just as well if you want the
struct to be free'able since then you suddenly need reference counting
or similar!
But right now the proposal says this is static, and I honestly don't
see much reason for it to be freeable?  The current use-cases `cupy` or
`pnumpy` don't not seem to need it.

If we return a new struct (I do not care if opaque or not), all of that
can still be expanded.  Should we just do that?
Or can we think of any downside to that or use-case where this is
clearly too limiting right now?

Cheers,

Sebastian


> 
> Eric
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion