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:45:05 GMT
The major concern is engineering overhead. The exchange formats are not
serialization format like json. So we need to do the conversion back and
force, and there are quite a lot of caveat there. The existing ones like
onnx is also evolving very fast and there is no backward compatibility so
far.

Implementing in python is an easier first step, and eventually, when things
stabilize, it makes sense to bring to C++

Tianqi

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

> 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