samskalicky commented on pull request #18904:
URL: https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-674954144


   > What sort of binary compatibility guarantees does MXNet make for this 
interface? If the safe option is always to compile at the same time, I don't 
see much difference from including it in the build?
   
   This interface makes no binary compatibility guarantees. You would need to 
compile and link your operators agains the version of MXNet you intend to load 
your library into. Further, you would need to build it in the same environment 
as MXNet (gcc, glibc, etc).
   
   The main benefits of between external operators over built-in operators are:
   1. They do not need to be part of the MXNet codebase (no PR, no community 
approval, etc). This also lets you more rapidly innovate on your custom 
operators since you dont need it to be part of a formal MXNet release or go 
through the PR process. Bug fixes on your custom operators can happen in 
parallel outside of the MXNet community. 
   2. You can distribute your custom ops separately from MXNet. For example, if 
you already have another Python package that you distribute (ie. as a wheel) 
you can package your operators within that package and dynamically load them 
into MXNet.
   
   Of course, you can still always build and distribute your own fork of MXNet 
with your custom operators in it. 
   
   This style of external operator is similar to how other DL frameworks 
support custom operators. So if you're familiar with writing custom operators 
for TF, PT, etc this is exactly the same. 


----------------------------------------------------------------
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]


Reply via email to