> We are looking for a robust solution for MXNet Java developers to use
> especially owned and maintained by the Apache MXNet's community. I will be
> more than happy to see if you would like to contribute the source code that
> generate MXNet JavaCpp package to this repo. So we can own the
This is great discussion. Thanks @lanking520 for initiating this. Perhaps we
can define some key metrics here so we can compare the solutions later?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
@saudet Thanks for your reply. Still, I am concerned about the first question:
you mentioned:
> 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
> ## What's missing
>
> javacpp-presets-mxnet doesn't expose APIs form nnvm/c_api.h (some of current
> python/gluon API depends on APIs in nnvm/c_api.h)
I've added that the other day, thanks to @frankfliu for pointing this out:
> @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
## What's inside of javacpp-presets-mxnet
* Native shared libraries:
* libmxnet.so
* libjnimxnet.so
* libmkldnn.0.so
* MXNet scala and java classes
* javacpp-presets-mxnet java API implemenations
* javacpp generated native bindings
* mxnet C_API
* mxnet-predict C_API
##
@saudet Thanks for your proposal. I have three 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.
2. Can you also do a benchmark on
@saudet @szha - I think we be a good path forward (from the Clojure perspective)
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-663085890
@saudet this looks awesome! An 18% improvement in throughput is quite
significant for switching the way of integration for a frontend binding. I
think we should definitely start with this offering. @lanking520 @gigasquid
what do you think?
--
You are receiving this because you are subscribed
Hi, instead of JNA, I would be happy to provide bindings for the C API and
maintain packages based on the JavaCPP Presets here:
https://github.com/bytedeco/javacpp-presets/tree/master/mxnet
JavaCPP adds no overhead, unlike JNA, and is often faster than manually written
JNI. Plus JavaCPP provides
My understanding is that DJL depends on MXNet, so if you want to bring JNA from
DJL into MXNet, it will create circular dependency as a 3rdparty module. In
terms of stability, I was referring to the development of code base rather than
the performance.
--
You are receiving this because you
There is no code for JNA, everything is generated. It ensure the general
standard and minimum layer in C to avoid error and mistakes.
About JNA, you can find more information here:
[jnarator](https://github.com/awslabs/djl/tree/master/mxnet/jnarator). We build
an entire project for the jna
@lanking520 would it create circular dependency? and how stable is the JNA and
what changes are expected? it would be great if you could share a pointer on
the JNA code to help clarify these concerns.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@szha For option 4, I would recommend to consume the JNA layer as a submodule
from DJL. I am not sure if this is recommendation serves as "add a dependency
in mxnet".
There are two key reason that support for that:
1. DJL moves really fast and we can quickly change the JNA layer whenever in
Another data point is that we currently only support OpenJDK 8 but the JVM
languages are broken with OpenJDK 11 which is used on Ubuntu 18.04 for example.
See https://github.com/apache/incubator-mxnet/issues/18153
--
You are receiving this because you commented.
Reply to this email directly or
Another data point is that all of our Scala tests fail randomly with
`src/c_api/c_api_profile.cc:141: Check failed:
!thread_profiling_data.calls_.empty():`, so there seem to be some underlying
issues.
https://github.com/apache/incubator-mxnet/issues/17067
--
You are receiving this because
+1 for option 1 and 2
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-599800518
For the Clojure package. It is a lot easier to interop with Java than with
Scala - so if the the base is Java that every thing is using - it will be
better for Clojure.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Reopened #17783.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#event-3112408479
Closed #17783.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#event-3112408330
> It is going to be closer to a complete rewrite. On the other hand, making a
> new Scala API would be imperative instead of symbolic and I think there are
> going to be a lot of operator changes to better match numpy in 2.0. I don't
> think the migration costs for a Scala 2.0 would be that
It is going to be closer to a complete rewrite. On the other hand, making a new
Scala API would be imperative instead of symbolic and I think there are going
to be a lot of operator changes to better match numpy in 2.0. I don't think the
migration costs for a Scala 2.0 would be that much less
@lanking520 thanks for the clarification above. A further question - How do
envision a current Scala MXNet user migrate their code? Is it going to be
mostly reusable or is it going to be a current rewrite for them?
--
You are receiving this because you are subscribed to this thread.
Reply to
I propose option 1 and 2 since it took us a lot of efforts to bring MXNet to
Scala originally and there are already adopters of Scala API in industries
(some may not have been disclosed yet). But I am open to other options. Not
familiar with DJL though but I assume @frankfliu and @lanking520
I would propose Option 3. and 4. Will add more comments here to explain why
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-595923396
Since MXNet 2.0 development starts. I would like to initiate a discussion for
the future development of JVM languages.
## Proposal
- Start cleaning on the existing APIs to adapt to 2.0
- Start from ground up to rewrite the whole Scala/Java APIs
- Start using DJL (djl.ai) as a frontend for MXnet
26 matches
Mail list logo
