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 <notificati...@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> > . > -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-569135511
