mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tianqi Chen <tqc...@cs.washington.edu>
Subject Re: The Exchange Layer Support of MXNet
Date Fri, 20 Oct 2017 15:08:56 GMT
I do not have a preference in terms of specifically having to do this in
particular language, and merely mean python would be an easier path. Most
other languages users can still get onnx model to mxnet's format(with a
script) and load it from there.

Tianqi

On Fri, Oct 20, 2017 at 8:06 AM, Chris Olivier <cjolivier01@gmail.com>
wrote:

> How would this impact use by other languages such as Scala, Perl, C++, etc?
>
> On Fri, Oct 20, 2017 at 8:01 AM, Tianqi Chen <tqchen@cs.washington.edu>
> wrote:
>
> > Given the instability nature of the current status of onnx, and the ease
> of
> > development, python would be favorable as the initial choice
> >
> > On Fri, Oct 20, 2017 at 8:00 AM, Chris Olivier <cjolivier01@gmail.com>
> > wrote:
> >
> > > Also, what language is the expectation here?  Is the ONNX serialization
> > to
> > > be developed in the C++ layer or python?  Seems like what I saw before
> > was
> > > python.
> > >
> > > On Fri, Oct 20, 2017 at 1:05 AM, Lupesko, Hagay <lupesko@gmail.com>
> > wrote:
> > >
> > > > Tianqi,
> > > >
> > > > “I would want the code to be in the repo as long as we reach the
> > > > consensus.”
> > > > +1
> > > >
> > > > “The reason why I am seeing this decision so seriously is that it
> will
> > > > affect how we can influence the design of the exchange format we act
> > on”
> > > > IMO, the most important first thing to do in order to influence the
> > > design
> > > > of ONNX is to support it, and the actual implementation detail
> matters
> > > less.
> > > >
> > > > “I am in favor of (2) because technically it gives us a clean future
> > > > compatibility, offers compilation”
> > > > What do you mean by “future compatibility”?
> > > > What do you mean by “offers compilation”? And since MXNet Sym is
> built
> > on
> > > > top of NNVM, why will we not have all of that if we go down the route
> > of
> > > > implementing the conversion on top of MXNet Sym?
> > > >
> > > > Hagay
> > > >
> > > > On 10/19/17, 20:43, "Tianqi Chen" <workcrow@gmail.com on behalf of
> > > > tqchen@cs.washington.edu> wrote:
> > > >
> > > >     I will start forking the previous discussion and it has gone awry
> > > and I
> > > >     hope to start a pure technical discussion thread.
> > > >
> > > >     I said in another email that we could do a vote to settle this
> > issue.
> > > > I now
> > > >     think that I was wrong and would like to apology for my rush
> > proposal
> > > > on
> > > >     this.
> > > >
> > > >     I hope to reopen this email thread to gain consensus on what we
> > want.
> > > > There
> > > >     has been express of concerns that the code should reside on
> > > ApacheMXNet
> > > >     repo. I think that discussion is already over and at least I
> would
> > > > want the
> > > >     code to be in the repo as long as we reach the consensus.
> > > >
> > > >     The leftover point is how should we do it. There are two ways of
> > > doing
> > > > this
> > > >
> > > >     1) Doing it on top of existing Symbol API.
> > > >     2) Moving most of the exchange layer on standardized core
> operator
> > > set,
> > > >     namely mxnet/gluon spec.
> > > >
> > > >     Both approaches are feasible. There is some advocation on which
> way
> > > > might
> > > >     be simpler, but the additional effort of engineering won't be
> that
> > > > much.
> > > >     The reason why I am seeing this decision so seriously is that it
> > will
> > > >     affect how we can influence the design of the exchange format we
> > act
> > > > on, and
> > > >     how easily it is to integrate future features that are made
> > > available.
> > > >
> > > >     I am in favor of (2) because technically it gives us a clean
> future
> > > >     compatibility, offers compilation and articulates clearly what
> > > >     ApacheMXNet's stance on core operators.
> > > >     These things could bring more impact to the community in general.
> > > >
> > > >     Tianqi
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message