mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: The Exchange Layer Support of MXNet
Date Fri, 20 Oct 2017 15:06:24 GMT
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