[GitHub] [incubator-mxnet] saudet edited a comment on issue #17783: [RFC] MXNet 2.0 JVM Language development

[GitBox <gi...@apache.org>]

saudet edited a comment on issue #17783:
URL: https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-663916338


   > @saudet Thanks for your proposal. I have four questions would like to ask you:
   > 
   > 1. If we adopt JavaCpp package, how will that be consumed? Under byteco or apache MXNet? Essentially from our previous discussion, we really don't want another 3rdparty checkin.
   
   We can go either way, but I found that for contemporary projects like Deeplearning4j, MXNet, PyTorch, or TensorFlow that need to develop high-level APIs on top of something like JavaCPP prefer to have control over everything in their own repositories, and use JavaCPP pretty much like we would use cython or pybind11 with setuptools for Python.
   
   I started the JavaCPP Presets because for traditional projects such as OpenCV, FFmpeg, LLVM, etc, high-level APIs for other languages than C/C++ are not being developed as part of those projects. I also realized the Java community needed something like Anaconda...
   
   > 2. Can you also do a benchmark on the MXNet's API's performance and possibly share the reproducible code? We did test the performance on JavaCpp vs JNA vs JNI and didn't see much difference on performance (under 10%).
   > 
   > 
   >     * MXImperativeInvokeEx
   > 
   >     * CachedOpForward
   > 
   > 
   > The above two methods are most frequently used methods in order to do minimum inference request, please try on these two to see how performance goes.
   > 
   
   If you're doing only batch operations, as would be the case for Python bindings, you're not going to see much difference, no. What you need to look at are things like the Indexer package, which allows us to implement fast custom operations in Java like this: http://bytedeco.org/news/2014/12/23/third-release/
   You're not going to be able to do that with JNA or JNI without essentially rewriting that sort of thing.
   
   > 3. We do have some additional technical issue with JavaCpp, is there any plan to fix it? (I will put it into a separate comment since it is really big.
   > 
   > 4. How do you ensure the performance if the build flag is different? Like the mxnet has to build from source (with necessary modification on source code) in order to work along with javacpp
   > 
   > 5. regarding to the dependencies issue, can we go without additional opencv and openblas in the package?
   
   Yes, that's the kind of issues that would be best dealt with by using only JavaCPP as a low-level tool, instead of the presets, which is basically a high-level distribution like Anaconda.


----------------------------------------------------------------
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:
users@infra.apache.org