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@python.org https://mail.python.org/mailman/listinfo/numpy-discussion