mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Skalicky <notificati...@github.com>
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. `my_op.so` 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`](https://github.com/apache/incubator-mxnet/blob/2610c10701c2b8155dbf094aaecba37ebbf67d0f/3rdparty/mshadow/mshadow/base.h#L173)
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 `min_ex.cc` 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:
https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-674967821
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message