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 <cjolivie...@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 <tqc...@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 <cjolivie...@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 <tqc...@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 < > cjolivie...@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 <lupe...@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" <workc...@gmail.com on behalf > of > > > > > > tqc...@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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
