mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lupesko, Hagay" <lupe...@gmail.com>
Subject Re: The Exchange Layer Support of MXNet
Date Fri, 20 Oct 2017 08:05:47 GMT
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
View raw message