Re: Feedback request for new Java API
That's not really the conversation I'm wanting to have. I want a discussion about the macros with respect to NDArray so that we can get agreement on our path forward with respect to implementing the NDArray wrapper. The design that was put forth and agreed to was for a a Java wrapper around the Scala API. Adding a bunch of Java friendly methods inside the Scala code would create a mess for users. Maintenance would be essentially the same for both because either way you're going to be updating Java methods when you make Scala changes. Let's please stick with the issue in the original email. Thanks, Andrew On Thu, Sep 27, 2018 at 5:22 PM Qing Lan wrote: > I would like to loop this back a layer. Current, there is a discussion in > the MXNet Scala community on the ways to implement the Java APIs. Currently > there are two thoughts: > > 1. Make Scala Java Friendly (Create Java compatible methods in the Scala > Class. such as NDArray with Java compatible constructor) > 2. Make Java friendly wrappers in Scala (Andrew's explanation below) > > The first approach require minimum input from our side to implement > however bring user a bunch of useless api they may not want to use. It also > makes Scala package heavier. The good thing is these two packages require > minimum maintenance cost. As a tradeoff, if any time in the future we want > to make Java big (make Java as the primary language supported by MXNet), > then the migration from Scala to Java will be harmful. Spark consider this > carefully and decide not to change much on their Scala code base to make it > more Java. > > The second approach will make unique NDArray, Shape, Context and more. The > good thing about this is we can always holds a version control on Java. > Some breaking changes on Scala may not influence much on Java. It did the > best way to decouple the module and good for us to build unique pipeline > for Java. The bad thing with this design is the maintenance cost as we need > to keep two code bases, but it also make Java side easy to change to make > it better compatible with users. > > Thanks, > Qing > > On 9/27/18, 3:25 PM, "Andrew Ayres" wrote: > > Hi, > > Currently, we're working to implement a new Java API and would like > some > feedback from the community on an implementation detail. In short, the > new > Java API will use the existing Scala API (in a manner similar to how > the > current Clojure API works). This basically means that we're making Java > friendly wrappers to call the existing Scala API. > > The feedback we're looking for is on the implementation of NDArray. > Scala's > NDArray has a significant amount of code which is generated via macros > and > we've got two viable paths to move forward: > > 1.) Change the macro to generate Java friendly methods - To do this > we'll > modify the macro so that the generated methods won't have > default/optional > arguments. There may also have to be some changes to parameter types to > make them Java friendly. The big advantage here is that ongoing > maintenance > will easier. The disadvantages are that we'll be changing the existing > Scala NDArray Infer API (it's marked experimental) and Scala users will > lose the ability to use the default and optional arguments. > > 2.) Leave the existing macro in place and add another which generates a > Java friendly version - The biggest issue here is that we'll be > doubling > the number of macros that we've got to maintain. It'll become even more > overhead once we start expanding the Java API with more classes that > use > generated code like this. The advantages are that the existing Scala > NDArray Infer API would remain unchanged for Scala users and that the > new > macro could be optimized to give the best possible experience to the > Java > API. > > Thanks, > Andrew > > >
Feedback request for new Java API
Hi, Currently, we're working to implement a new Java API and would like some feedback from the community on an implementation detail. In short, the new Java API will use the existing Scala API (in a manner similar to how the current Clojure API works). This basically means that we're making Java friendly wrappers to call the existing Scala API. The feedback we're looking for is on the implementation of NDArray. Scala's NDArray has a significant amount of code which is generated via macros and we've got two viable paths to move forward: 1.) Change the macro to generate Java friendly methods - To do this we'll modify the macro so that the generated methods won't have default/optional arguments. There may also have to be some changes to parameter types to make them Java friendly. The big advantage here is that ongoing maintenance will easier. The disadvantages are that we'll be changing the existing Scala NDArray Infer API (it's marked experimental) and Scala users will lose the ability to use the default and optional arguments. 2.) Leave the existing macro in place and add another which generates a Java friendly version - The biggest issue here is that we'll be doubling the number of macros that we've got to maintain. It'll become even more overhead once we start expanding the Java API with more classes that use generated code like this. The advantages are that the existing Scala NDArray Infer API would remain unchanged for Scala users and that the new macro could be optimized to give the best possible experience to the Java API. Thanks, Andrew
Re: New Java Inference API
Hi Kellen, Thanks for the feedback. You bring up an interesting idea about the dependencies. I'll add that to the list of things to look into. As for the threading, my current thinking is that we implement a dispatcher thread like suggested in the Scala threading discussion https://discuss.mxnet.io/t/fixing-thread-safety-issues-in-scala-library/236. I would definitely like to hide such complexities from the user. Andrew On Thu, May 10, 2018 at 3:22 AM, kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Hey Andrew, thanks for the write-up. I think having a Java binding will be > very useful for enterprise users. Doc looks good but two things I'm > curious about: > > How are you planning to handle thread safe inference? It'll be great if > you can hide the complexity of dealing with dispatch threading from users. > > The other thing I think a solid Java API could provide is a limited number > of dependencies. There's some simple things we can do to make this happen > (create a statically linked, portable so) but there's also some complexity > around minimizing dependencies MXNet. For example we'll likely want to > release MKL flavoured binaries, we should have a few versions of CUDA > supported. We could try and have one version that has an absolute minimum > of dependencies (maybe statically linking with openblas). It might be good > to document exactly the packages you're planning to release, and give some > more details about what the dependencies for the packages would be. > > Many thanks for looking into this, I think it'll be a big improvement for > many of our users. > > -Kellen > > On Thu, May 10, 2018, 12:57 AM Andrew Ayres > wrote: > > > Hi all, > > > > There has been a lot of interest expressed in having a Java API for doing > > inference. The general idea is that after training a model using python, > > users would like to be able to load the model for inference inside their > > existing production eco-system. > > > > We've begun exploring a few options for the implementation at < > > https://cwiki.apache.org/confluence/display/MXNET/ > MXNet+Java+Inference+API > > > > > and would appreciate any insights/feedback. > > > > Thanks, > > Andrew > > >
New Java Inference API
Hi all, There has been a lot of interest expressed in having a Java API for doing inference. The general idea is that after training a model using python, users would like to be able to load the model for inference inside their existing production eco-system. We've begun exploring a few options for the implementation at < https://cwiki.apache.org/confluence/display/MXNET/MXNet+Java+Inference+API> and would appreciate any insights/feedback. Thanks, Andrew
