You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mxnet.apache.org by GitBox <gi...@apache.org> on 2019/12/26 21:21:17 UTC

[GitHub] [incubator-mxnet] larroy commented on issue #17097: [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead

larroy commented 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-569135511
 
 
   What's the point of having an API if you type erase it? Then you might as
   well have a single function API with a type erased callback name to select
   the function to call. In the end you move the burden away from the API to
   the callers and inside the API to the dispatchers. For going this route of
   uber-clever template tricks to generate code, I think it's better to just
   put in place proper code generation for maintainability. Could you provide
   a bit more details about tradeoffs? Everything has tradeoffs, I don't
   believe any solution which is sold as a panacea, there's no silver bullet.
   
   On Thu, Dec 19, 2019 at 10:21 AM Tianqi Chen <no...@github.com>
   wrote:
   
   > I have another candidate that would highly recommend: adopt TVM's FFI
   > convention.
   >
   > The historical problem of MXNet FFI was the blowing amount of the C API
   > bindings as we add new features. This creates a huge amount of maintenance
   > burden.
   >
   > The real problem was not really about which FFI system to adopt(cython and
   > pybind are fine in that end, except for the cost of compilation), but more
   > of the cost to maintain the FFI. MXNet used to have a fast cython binding,
   > but that was abandoned because we keep add new APIs we cannot keep up both
   > ctypes and cython.
   >
   > When developing TVM we learnt from the lesson and restrict the API to a
   > limited set of runtime APIs that does not change, and have a stable cython,
   > ctypes binding for them. The runtime support a type-erased
   > function(PackedFunc), which can be efficiently called from any of the
   > frontend language, and all the APIs are exposed through the PackedFunc. On
   > the python side an additional wrapping is created for better documentation
   > and call into the PackedFunc. See more in
   > https://docs.tvm.ai/dev/runtime.html The system works great for over a
   > few years now.
   >
   > Of course I understand there has been legacy issues in MXNet that is why I
   > did not bring this proposal up. But given this is a proposal for 2.0, I
   > would encourage everyone to give a serious thought about this possibility.
   >
   > —
   > You are receiving this because you are subscribed to this thread.
   > Reply to this email directly, view it on GitHub
   > <https://github.com/apache/incubator-mxnet/issues/17097?email_source=notifications&email_token=AAHCV2JHKIW6ZV2HVDYDR6DQZO3RLA5CNFSM4J3WHPZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHKPJXA#issuecomment-567604444>,
   > or unsubscribe
   > <https://github.com/notifications/unsubscribe-auth/AAHCV2NICGEG3VMB2JTNHW3QZO3RLANCNFSM4J3WHPZQ>
   > .
   >
   

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services