mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Skalicky <>
Subject Re: [apache/incubator-mxnet] [RFC] MXNet external operators (#18904)
Date Mon, 17 Aug 2020 16:03:39 GMT
> I think this would be much cleaner if it was a separate directory because:
> * Version control is much easier.  Just update mxnet or `rm -rf` it without extra cruft
> * This reflects reality much better.  Somebody else builds mxnet for `pip` without knowing
about my stuff. MXNet ships a docker in which I can build my thing for binary compatibility.
> * MXNet should be usable as a submodule.
> So my ideal instructions look more like
> 1. compile MXNet normally from a clean checkout
> 2. cd into your own project, configure with `-DMXNET=/path/to/mxnet` and compile.  Sample
project provided and part of integration tests.
> 3. `` built by my build system
> 4. dynamically load shared library into MXNet via `mx.library.load()`

Agreed, if only MXNet codebase was better organized. We have headers/includes scattered throughout
the codebase. Not just in *include/mxnet**. For example `mxnet_op.h` in in **src/operator**
and [`include/mshadow/base.h` includes `mkl_blas.h`](
which isnt in the MXNet codebase. Duplicating and reproducing the MXNet cmake flow for building
custom operators is not worth the hassle/maintenance. 

If others have ideas that they wanna give it a whirl, feel free to checkout this branch and
try building `` in the `lib_external_ops` directory. Happy to collaborate on this.

You are receiving this because your review was requested.
Reply to this email directly or view it on GitHub:
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message