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:17:38 GMT
I am not implementing it, but I prefer C++ for this reason.  But then
again, I am biased towards C++ in general :)
Are there reasons to not do it in C++?  Maybe there are...

On Fri, Oct 20, 2017 at 8:08 AM, Tianqi Chen <tqchen@cs.washington.edu>
wrote:

> 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