mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From YiZhi Liu <eazhi....@gmail.com>
Subject Re: Feedback request for new Java API
Date Sat, 29 Sep 2018 18:59:49 GMT
Moreover, regarding "add 200+ APIs" - this was exactly what we did for
type-safe APIs in Scala, we have NDArray/Symbol.BatchNorm and
NDArray/Symbol.api.BatchNorm - why did we decide to do that? Because
we thought type-safe could provide better user-experience. Given the
example I listed above, I think such user-experience benefits are even
greater than what we got from type-safe.
On Sat, Sep 29, 2018 at 11:41 AM YiZhi Liu <eazhi.liu@gmail.com> wrote:
>
> Naveen, software designing is all about tradeoff, every feature we
> introduce causes more compiling time, more efforts to maintain, etc.
>
> The main difference is.
>
> Option #1: Java users do
> NDArray.BatchNorm(data, gamma, beta, null, null, null, null, null,
> null, null, null, null, null, null);
> (and because every operator has an argument "out", users need to add
> an extra "null" to the function call almost every time.)
>
> Option #2, Java users do
> JavaNDArray.BatchNorm(data).setGamma(gamma).setBeta(beta).invoke();
>
> I don't think any of the reasons you listed is so important as the
> benefit above we got from option #2.
> On Sat, Sep 29, 2018 at 8:24 AM Naveen Swamy <mnnaveen@gmail.com> wrote:
> >
> > Java APIs are not like Clojure - The current proposal is only to build a
> > few thin wrappers for Inference.
> >
> > To better represent the two cases and this discussion in particular, here
> > is an example API
> >
> > 1) def Activation (data : org.apache.mxnet.NDArray, act_type : String, out
> > : Option[NDArray] = None) : org.apache.mxnet.NDArrayFuncReturn
> > or
> > 2) def Activation (data : org.apache.mxnet.NDArray, act_type : String, out
> > : NDArray) : org.apache.mxnet.NDArrayFuncReturn
> >
> > The discussion is should we add(generate) 200+ APIs to make it Java
> > compatible, ie., remove the Option class and the None default value which
> > Java does not understand from Option 1)
> >
> > my suggestion was to remove the Option class and create a implicit for
> > backward compatibility and use null instead of None, Andrew and I disagreed
> > on this, so I suggested to raise a discussion on dev@ to get more opinions
> > and one of us will disagree and commit. Thanks for raising it :)
> >
> > | * def Activation (data : org.apache.mxnet.NDArray, act_type : String, out
> > : NDArray = null) : org.apache.mxnet.NDArrayFuncReturn |
> > --
> >
> > 1) It is not true that Scala users will lose *default/optional* arguments -
> > if we followed the above, they will use null or None, though I do not like
> > using nulls, this is a fine compromise.
> > To keep backward compatibility we can create a implicit to convert
> > Option.None to nulls and Option.Some-> Option.get(), so you are not going
> > to break users who might have been using the APIs that were released in
> > 1.3. The current incompatibility is only this w.r.t. NDArrays.
> >
> > 2) Now about the Scala Macros - they are not simple to read or use, When I
> > and Qing started working on the #Scala Macros to improve the APIs, it took
> > us a good amount of time to get a hang of it. I don't want to add
> > additional code when not necessary.
> >
> > My suggestion and vote is to modify existing Macro(i.e., #1 from the
> > original email with the necessary clarification above) and make it
> > compatible with Java
> > Here are my reasons
> > 1) The NDArray APIs in question are not following functional style of
> > programming, in fact they are just static methods defined on an NDArray
> > object - so Scala users are not losing much by using null in place of None.
> > You can create a implicit to maintain backward compatibility
> > 2) It is adding 220+ APIs(I understand it is generated) for NDArray alone
> > 3) this is adding another 100s of APIs unnecessarily, we are starting with
> > NDArray but we can't stop there, we will have to do this for Symbol,
> > Executor, Iterators, etc., .
> > 3) I don't want to be fixing bugs and maintaining code in 2 places.
> > 4) I want the cryptic code(# scala macros) to a minimum.
> > 5) increased compilation time & bad developer experience - the time to
> > compile has gone up quite a bit since we added the APIs last release on my
> > 3 year old laptop already.. I think adding 400+ APIs unnecessarily would
> > significantly increase build time and bad developer experience
> > 6) I want to keep the core of the framework to be in Scala - because it
> > allows you to write concise code - Yes it has a bit of learning curve, not
> > everyone needs to know. I would rather invest in solidifying the Scala APIs
> > and add more features in Scala(RNN, Support GluonHybridizedBlock...there is
> > quite bit of work ) - do you want to rewrite everything in Scala and Java.
> > 7) Also, the discussion is not creating NDArray class for Java, just
> > generate certain APIs to cater for Java incompatibility.
> >
> > @Andrew: To your response to Qing's comments - you cannot just consider it
> > as just generating NDArray's APIs and instead I suggest to take a wholistic
> > view of all the various implications.
> >
> > @Chris: Yes, Scala has a bit of learning curve - the goal is not having
> > every developer to deal with how these APIs are generated,
> > the problem exists either ways with the above proposal. I might agree if we
> > were to move away completely(with a thorough discussion and valid reasons)
> > and instead use AspectJ or similar to write these APIs, the discussion is
> > about using Scala Macros to generate 2 different types of APIs which are
> > functionally not different and usability wise are very very similar, look
> > at the example.
> > Thanks for your input, I will deposit your 0.02$ in our JIRA bank :)
> >
> > @Carin: It requires more effort to use AspectJ or similar to generate APIs
> > using reflection or at compile time, here we need to generate at compile
> > time so Java users have the API signature on their IDEs.
> >
> > Thanks, Naveen
> >
> > P.S: I am traveling and my responses will be delayed.
> >
> >
> > On Fri, Sep 28, 2018 at 10:25 AM Carin Meier <carinmeier@gmail.com> wrote:
> >
> > > Sorry bad paste on the gist - here is the good one
> > > https://gist.github.com/gigasquid/01cd48f563db4739910592dd9ac9db20
> > >
> > > On Fri, Sep 28, 2018 at 10:24 AM Carin Meier <carinmeier@gmail.com> wrote:
> > >
> > > > +1 on option #2
> > > >
> > > > In the case of minimizing the the overhead for code maintenance, I wanted
> > > > to suggest the option of investigating generating code from the Java
> > > > Reflection for the Java APIs.  I did a quick gist from Clojure of what
> > > the
> > > > generated classes look like from the current Scala Symbol.api for
> > > > FullyConnected here
> > > > https://gist.github.com/gigasquid/01cd48f563db4739910592
> > > >
> > > > I looks like that there is always a base Java class generated will all
> > > the
> > > > arguments. If this is the case, then there is a possibility to generate
a
> > > > Java api based on this Java method automatically with just a conversion
> > > for
> > > > the Scala option and it might be reusable for all the packages.
> > > >
> > > > Not sure if it will work for this use case, but thought I would bring
it
> > > > up in case it's helpful.
> > > >
> > > > - Carin
> > > >
> > > > On Fri, Sep 28, 2018 at 7:05 AM Davydenko, Denis <dden@amazon.com.invalid
> > > >
> > > > wrote:
> > > >
> > > >> +1 on option #2. Having clear Java interface for NDArray, from my
> > > >> perspective, would be a better experience for Java users as it won't
> > > >> require them to deal with Scala code in any capacity. Overhead of
extra
> > > >> code for additional macros is justified, in my mind, as it will be
> > > >> introduced with option #1 either way, just in a different place.
> > > >>
> > > >> --
> > > >> Thanks,
> > > >> Denis
> > > >>
> > > >> On 9/27/18, 6:14 PM, "YiZhi Liu" <eazhi.liu@gmail.com> wrote:
> > > >>
> > > >>     I vote for "2.) Leave the existing macro in place and add another
> > > >>     which generates a Java friendly version"
> > > >>
> > > >>     @Qing @Andrew, could you give some examples, so that people can
> > > better
> > > >>     understand how it provides "best possible experience" to Java
users.
> > > >>
> > > >>     I have no strong preference between having JavaShape & JavaContext
> > > or
> > > >> not.
> > > >>     On Thu, Sep 27, 2018 at 5:56 PM Andrew Ayres <
> > > >> andrew.f.ayres@gmail.com> wrote:
> > > >>     >
> > > >>     > 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 <lanking520@live.com>
> > > >> 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" <andrew.f.ayres@gmail.com>
> > > >> 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
> > > >>     > >
> > > >>     > >
> > > >>     > >
> > > >>
> > > >>
> > > >>
> > > >>     --
> > > >>     Yizhi Liu
> > > >>     DMLC member
> > > >>     Amazon Web Services
> > > >>     Vancouver, Canada
> > > >>
> > > >>
> > > >>
> > >
>
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada



-- 
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada

Mime
View raw message