> 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. -- You are receiving this because your review was requested. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-674954144
