Build for MXNet branch master has broken. Please view the build at
https://builds.apache.org/job/incubator-mxnet/job/master/207/
I use MXNet in production for a while, where I trained the model in Python and
deploy it in Java env by calling a Scala object. I think that’s enough in my
use case.
class MXNetPredictor (prefix: String, epoch: Int, batchSize: Int) {
val model = FeedForward.load(prefix, epoch)
/**
*
We are closing this vote because there is a bug causing 20-30% performance
degradation.
We will address this issue and send out RC2 for another vote.
> On Aug 14, 2017, at 7:25 PM, Meghna Baijal wrote:
>
> This is the vote to release Apache MXNet (incubating)
Hi, Joern,
when you say "Java API " it's sharing scala impl or not?
Best,
Nan
On Wed, Aug 16, 2017 at 12:46 PM, Joern Kottmann wrote:
> Seems like we are all agree about the idea to add a Java API.
>
> Maybe it is just me, but it wouldn't at all make sense for me (OpenNLP
Seems like we are all agree about the idea to add a Java API.
Maybe it is just me, but it wouldn't at all make sense for me (OpenNLP
use case) to use the Java API when it requires a Scala dependency,
because at that point I would be better of just using the Scala API,
and ensure that the things I
Build for MXNet branch master has broken. Please view the build at
https://builds.apache.org/job/incubator-mxnet/job/master/203/
+1 for Sandeep's suggestion
On Wed, Aug 16, 2017 at 11:21 AM, YiZhi Liu wrote:
> Agree with Sandeep, while I guess the performance won't change. But
> yes, benchmark talks.
>
> Moreover, in Scala package we use macros to generate operators
> automatically, which will
Agree with Sandeep, while I guess the performance won't change. But
yes, benchmark talks.
Moreover, in Scala package we use macros to generate operators
automatically, which will require more efforts if we switch to pure
Java.
2017-08-17 2:12 GMT+08:00 sandeep krishnamurthy
The fastest way to get Java binding is through building Java native
wrappers on Scala package.
Disadvantages would be:
* *Bloated library size: *May not be suitable for users planning to use
Java APIs in Android of such smaller systems.
* *Performance:* Performance may not be as good as
+1 for using Swig or JavaCPP to generate a low-level API and then
high-level Scala and Java API's can converge to use that layer. Scala
diverging towards scripting and Java towards some other API (i.e.
Deeplearning4j, which I have never used). Using a generated interface
layer makes it much more
I don't think there will be problems under "11", did the user see concrete
errors?
Best,
Nan
On Wed, Aug 16, 2017 at 9:30 AM, YiZhi Liu wrote:
> Hi Nan,
>
> Users have 2.11, but with a different minor version, will it cause
> conflicts?
>
> 2017-08-17 0:19 GMT+08:00 Nan
Hi Nan,
Users have 2.11, but with a different minor version, will it cause conflicts?
2017-08-17 0:19 GMT+08:00 Nan Zhu :
> Hi, Yizhi,
>
> You mean users have 2.10 env while we assemble 2.11 in it?
>
> Best,
>
> Nan
>
> On Wed, Aug 16, 2017 at 9:08 AM, YiZhi Liu
Hi, Yizhi,
You mean users have 2.10 env while we assemble 2.11 in it?
Best,
Nan
On Wed, Aug 16, 2017 at 9:08 AM, YiZhi Liu wrote:
> Hi Joern,
>
> The point is that, the front is not a simple wrapper of c_api.h, as
> you mentioned, which can be easily achieved by JavaCPP.
Hi, Jorn
Thanks for providing the info
My opinion is that,
1. MxNet current relies on Scala 2.11 (having some problems due to the
spark package...I am fixing it), which is a stable release for most of
packages...my personal experience hasn't involved a package which only
provides 2.10 version
Hi Joern,
The point is that, the front is not a simple wrapper of c_api.h, as
you mentioned, which can be easily achieved by JavaCPP.
I have noticed the potential conflicts between the assembled scala
library and the one in users' environment. Can we remove the scala
library from the assembly
My two cents here:
Start with something simple and share foundation with scala, focus on
the API and usability. Once the java API get stabilized, we can then
discuss if such issue arise. I feel maven is quite automatic in terms of
handling scala deps and that won't create an issue except for
I agree with Yizhi
My major concern is the duplicate implementations, which are usually one of
the major sources of bugs, especially with two languages which are
naturally interactive (OK, Calling Scala from Java might need some more
efforts). It is just like we provide C++ & C APIs of MxNet in
Really glad to see this discussion. Sandeep has been giving this some thought
as well.
Regards,
Dom
> On Aug 16, 2017, at 8:19 AM, YiZhi Liu wrote:
>
> Hi,
>
> If we build the Java API from the very beginning, i.e. the JNI part,
> we have to rewrite the codes for
Hi,
If we build the Java API from the very beginning, i.e. the JNI part,
we have to rewrite the codes for training, predict, inferShape, etc.
It would be too heavy to maintain a totally new front language.
As far as I see, I don't think Scala library dependency would be a big
problem in most
Hello,
the approach which is taken by Spark is described here [1].
As far as I see this has the great disadvantage that the Java API
would force Scala as a dependency onto the java users.
For a library it is always a great advantage if it doesn't have many
dependencies, or zero dependencies. In
Hi Joern,
I suggest to build Java API as a wrapper of Scala API, re-use most of
the procedures. Referring to the Java API in Apache Spark.
2017-08-16 18:21 GMT+08:00 Joern Kottmann :
> Hello all,
>
> I would like to propose the addition of a Java API to MXNet.
>
> There has
Hello all,
I would like to propose the addition of a Java API to MXNet.
There has been some previous work done for the Scala API, and it makes
sense to at least share the JNI layer between the two.
The Java API probably should be aligned with the Python API (and
others which exist already)
22 matches
Mail list logo