Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mxnet.incubator.apache.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Fri, 20 Oct 2017 01:05:47 -0700
Subject: Re: The Exchange Layer Support of MXNet
From: "Lupesko, Hagay" <lupesko@gmail.com>
To: <dev@mxnet.incubator.apache.org>
Message-ID: <915ECA45-2CA1-4E34-864B-CFF6ABEDAF33@gmail.com>
Thread-Topic: The Exchange Layer Support of MXNet
References: <CACZfuxYaom62p7EXMVkG41b22RxDvYYvBPJP_gzw5p44x7-KwQ@mail.gmail.com>
In-Reply-To: <CACZfuxYaom62p7EXMVkG41b22RxDvYYvBPJP_gzw5p44x7-KwQ@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable
archived-at: Fri, 20 Oct 2017 08:05:58 -0000

Tianqi,

=E2=80=9CI would want the code to be in the repo as long as we reach the consensu=
s.=E2=80=9D
+1

=E2=80=9CThe reason why I am seeing this decision so seriously is that it will af=
fect how we can influence the design of the exchange format we act on=E2=80=9D
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.

=E2=80=9CI am in favor of (2) because technically it gives us a clean future comp=
atibility, offers compilation=E2=80=9D
What do you mean by =E2=80=9Cfuture compatibility=E2=80=9D?
What do you mean by =E2=80=9Coffers compilation=E2=80=9D? 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@c=
s.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.
   =20
    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 o=
n
    this.
   =20
    I hope to reopen this email thread to gain consensus on what we want. T=
here
    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.
   =20
    The leftover point is how should we do it. There are two ways of doing =
this
   =20
    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.
   =20
    Both approaches are feasible. There is some advocation on which way mig=
ht
    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.
   =20
    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.
   =20
    Tianqi
   =20