tqchen edited a comment on issue #17097: [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead URL: https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-568234198 Thanks for discussions so far, to clarify the techinal questions and discuss tradeoffs further. The following fast-path can be addressed in the TVM FFI: - ```tuple```, ```list``` via translation in python/cython side (see benchmark above) - ```str``` is already fast (seem benchmark above) - ```Context``` can be quite fast if the object is a tvm object, around same mangitude as passing NDArray - ```np.dtype``` can get around by by str conversion, or introduce a type structure, TVM FFI support DLDataType natively - None: natively supported by FFI The following items needs to be discussed - py_slice, Ellipsis Can be supported by adding pyobject support via pybind, however that introduces python C API dependency into the FFI layer(making the function not accessible to other language frontends). Would be interesting to discuss alternatives Of course, all of the above cases can be solved by pybind, or a mix of pybind and TVM FFI. It would certainly be interesting to discuss the possible engineering path. ## Technical Tradeoffs The main techinque trade-off points that influences the decision are as follows: - Do everything in c++ vs some python layer translation: pybind is definitely good for former, tvm ffi requires translation in python(which could be good for docs readability). - How to resolve FFI for other languages(e.g. scala, clojure), tvm FFI directly exposes to these languages, pybind works great for python, but we need to re-expose to other languages(via another FFI) - Compatibility of future compilers, e.g. allow callback into those numpy functions from compiled code. TVM FFI convention directly enables that, while pybind needs some additional works(to create a interpolation layer from tvm ffi into pybind). - Whether we are interested in a mixed approach(e.g. allow passing pyobject to backend for certain cases), note again need to re-expose the same API to other languages in another way that does not uses pyobject, but likely only need to do it for limited cases.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
