gmarkall commented on PR #34972: URL: https://github.com/apache/arrow/pull/34972#issuecomment-1507003526
> @gmarkall @stuartarchibald Not sure you want to read the entire discussion here, but I or @kkraus14 can provide a quick summary if needed :-) I've read the entire discussion and I believe I've understood it - please do let me know if I appear to be going off-course in the following though :slightly_smiling_face: > Hmm, since the primary example of a producer-supplied CUDA stream is the [CUDA Array Interface](https://numba.readthedocs.io/en/stable/cuda/cuda_array_interface.html#streams), perhaps it would be nice to have the Numba devs' feedback on consumer-supplied vs. producer-supplied. The stream and synchronization parts of the CAI specification aren't really originated solely in Numba / from Numba developers, but evolved though the discussion mostly on https://github.com/numba/numba/pull/5162 - there was input from quite a few people on that PR and the issues referred to therein (I won't ping them all here) so I'd say the design that landed there was much more of a community agreement than a Numba-derived specification / feature. Like @kkraus14, I haven't really seen it used in practice, except in Numba which I suppose provides a reference example for a "safe by default" implementation. I think the specification arose from how we expected people would want to use it rather than based on experience prior to the definition. Then, following the agreement and updating of the specification, I think most that had been involved in the discussions found no high-priority need for this particular feature (e.g. changing priorities / directions) so I think this particular set of design decisions hasn't really been tested out as much as it might appear. I also think it would also have been more difficult to have the consumer supply the stream for CAI, because it is just a property containing a dict - this might have steered thinking away from even giving consideration to the idea of consumer-supplied streams because some more radical change to the interface would have been needed to support it. Given the above, I think I wouldn't assume too much about the amount of experience that drove the choices made for the CAI, and would suggest tending towards what seems the most reasonable choice for Arrow, rather than what might provide the most common ground with the CAI. (As a side note - Numba doesn't support DLPack because it didn't seem very important to support it - anyone wanting to use DLPack with Numba device arrays could just convert to CuPy using CAI then to DLPack from there.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
