DMLC [Was: Request for suggestions- Supporting onnx in mxnet]

It wasn't about the two of you specifically, it was that it seemed to me that we have two communities (DMLC and MXNet; communities not committers) having a difference of opinion. This is not a healthy thing. Apologies on the "Something is rotten"; it's an allusion to a quote from Shakespeare's

Re: Request for suggestions- Supporting onnx in mxnet

- We can implement onnx importer directly through gluon API - For the exporter, it is recommended to canonicalize them to gluon's op def, before converting into onnx. Such canonicalization utility is support via nnvm/top. - If we don't want to rely on the code in the nnvm/top(which I recommend at

Re: Request for suggestions- Supporting onnx in mxnet

Tianqi, Can you clarify your proposal to go through mxnet/gluon? - Are you proposing to implement “import ONNX” in Gluon by dynamically building the ONNX graph using Gluon API? - Gluon does not have a “save” API, you can only save weights, not the network. How can we export Gluon model to

Re: Request for suggestions- Supporting onnx in mxnet

Again my recommendation is to go through mxnet/gluon (which in that case core operator set of NNVM) with the following technical reason: - Enjoy future compatibility and compilation pipeline that other frameworks do not have - Articulate Apache MXNet's need of core operators clearly to give

Re: Request for suggestions- Supporting onnx in mxnet

I think "We" refer to "Tianqi and me" on this thread. On Thu, Oct 19, 2017 at 12:53 PM, Suneel Marthi wrote: > I guess the whole discussion here is about - Who is 'We' in your email ? > > 'We thought there is a better way of doing this' > > It may just be misinterpretation

Re: Request for suggestions- Supporting onnx in mxnet

There is overhead for moving repos to Apache. For example, moving MXNet took about a few months. Also, we don't have enough evidence to convince the rest NNVM/TVM contributors that the benefits of moving to Apache are larger than the cost. So unlikely we can "move all DMCL modules right now". On

Re: Request for suggestions- Supporting onnx in mxnet

I guess the whole discussion here is about - Who is 'We' in your email ? 'We thought there is a better way of doing this' It may just be misinterpretation or misunderstanding amongst folks here due to language barrier. On Thu, Oct 19, 2017 at 3:48 PM, Tianqi Chen

Re: Request for suggestions- Supporting onnx in mxnet

Hi Henri, I don't understand why you labeled Tianqi and me as from "non-compatible DMLC community". We are the top-2 contributors for MXNet. Actually, among the participants in this thread, only both of us are listed as the committers . We are

Re: Request for suggestions- Supporting onnx in mxnet

Why don't we just move all of these dmlc modules into the Apache repository right now and have the correct discussions on dev? What's the argument against this? IMHO, I thought that's what was going to be done originally. On Thu, Oct 19, 2017 at 12:14 PM, Tianqi Chen

Re: Request for suggestions- Supporting onnx in mxnet

Hi Hen: It is sad to think DMLC adversarially in this matter. DMLC projects adopt apache way of doing things and we are planning moving more modules into Apache. All the discussion so far happens under the Apache manner and I do think that healthy discussion on critical design issues is

Re: Request for suggestions- Supporting onnx in mxnet

One solution: The MXNet community forks the DMLC code it relies on into the MXNet codebase and moves on without being tied down by the decisions of a non-compatible community. +1 had a similar impression while following this discussion. -s

Re: Request for suggestions- Supporting onnx in mxnet

Here are the detailed points(sorry for resenting it over again) Technical Reasoning: - Model exchange format like CoreML and ONNX are not lossless and complete. They are designed to an contain a core set of the minimum operators to support necessary inference tasks like ResNet, etc. So you

Re: Request for suggestions- Supporting onnx in mxnet

As for where the code should sit, we have seen onnx's support for caffe2 sitting on a separate repo. My suggestion would be put code under nnvm/top and migrate into mxnet eventually when the top components get into MXNet, hopefully by end of next month. I have elaborated my point in the last

Re: Request for suggestions- Supporting onnx in mxnet

I'm speaking under my "MXNet contributor" hat. It will be sad that our new model format and compiler is not supported by our own contributors. It puts us in a bad position to reach out to outside to ask for support. If you really what to do it with the onnx <-> mxnet way, I suggest putting the

Re: Request for suggestions- Supporting onnx in mxnet

Since there seems to be a difficulty to reach a consensus here, and this is a new area, maybe a good compromise would be to contribute this under /contrib as experimental, with whatever way Roshani thinks makes sense. Once there is code in place, and MXNet users and contributors are able to

Re: Request for suggestions- Supporting onnx in mxnet

I want to offer one last thing in terms of technical details. I mentioned two trends in the deep learning systems. There is one last thing that is omitted. How should we build a good deploy end for deep learning models. There is always a paradox to this problem: - On one hand, the deployment end

Re: Request for suggestions- Supporting onnx in mxnet

Hi Chris: There is no intention to move things away from mxnet. The reduction of lines of code by having a better design in general, and usually, you write less redundant code by benefiting from better design. As I may quote: "the best design is not achieved not when there is nothing to add, but

Re: Request for suggestions- Supporting onnx in mxnet

To better answer Hagay's question, I would like to dive down a bit deeper on the relation between MXNet, NNVM and model exchange format like ONNX. There are two major trends in deep learning systems now: - Common serializable formats, like ONNX and CoreML, that defines the model exchange format.

Re: Request for suggestions- Supporting onnx in mxnet

I think the point here is that API stays the same, and the discussion is only about how we should implement it. Tianqi On Wed, Oct 18, 2017 at 6:43 PM, Dom Divakaruni < dominic.divakar...@gmail.com> wrote: > I imagine users would want to interact with MXNet as they normally do to > consume or

Re: Request for suggestions- Supporting onnx in mxnet

I imagine users would want to interact with MXNet as they normally do to consume or export an ONNX format. How would that work with NNVM? Not sure users care about the implementation, as long as it doesn’t add another layer of complexity to the workflow. Regards, Dom > On Oct 18, 2017, at

Re: Request for suggestions- Supporting onnx in mxnet

Hi Hagay, As mentioned on my previous thread, " MXNet has lots of users already using the Symbolic API which hopefully mean that is a mature API that is not likely to have breaking changes or major issues." actually indicate NNVM is stable. Because MXNet uses NNVM's symbolic.h directly, see

Re: Request for suggestions- Supporting onnx in mxnet

We plan to incubate nnvm and it and make it apache eventually. NNVM as it is now adopted apache model, as did MXNet originally. My suggestion is mainly for evolving the Apache MXNet to become healthier and cleaner in the longer term, with fewer number lines of code while supporting more

Re: Request for suggestions- Supporting onnx in mxnet

I cannot get the point. MXNet relies on NNVM. In fact, the Symbol object in MXNet is defined on NNVM. On Wed, Oct 18, 2017 at 6:09 PM, Chris Olivier wrote: > My $0.02: > > NNVM is not currently an Apache module. It’s under dmlc umbrella, whose > direction and governance

Re: Request for suggestions- Supporting onnx in mxnet

My $0.02: NNVM is not currently an Apache module. It’s under dmlc umbrella, whose direction and governance is unclear. For this reason, I am inclined to support new effort being places in Apache MXNet -Chris On Wed, Oct 18, 2017 at 5:19 PM Tianqi Chen wrote: > > >

Re: Request for suggestions- Supporting onnx in mxnet

> > - “More hardware backends to mxnet” – MXNet users get the same benefit of > HW support implementing ONNX import on top of MXNet symbolic, right? > The support of nnvm compiler compilation comes directly from going into nnvm/top. This include supporting interesting operators onnx do not yet

Re: Request for suggestions- Supporting onnx in mxnet

Roshani – this is an exciting initiative, ONNX support on MXNet will enable more users to ramp up on MXNet, which is great. Tianqi – a few questions and thoughts about your note: - “More hardware backends to mxnet” – MXNet users get the same benefit of HW support implementing ONNX import on top

Re: Request for suggestions- Supporting onnx in mxnet

I am strongly recommending going through the nnvm/top. One major reason in here is that the support of nnvm/top layer NOT ONLY mean compatibility of model format with onnx. These are the major benefits: - More hardware backends to mxnet, including opencl, metal, Raspberry Pi, web browser. These

Request for suggestions- Supporting onnx in mxnet

Hi guys, I am working on supporting ONNX pre-trained models in Apache MXNet and would like to seek your opinion on the choice of implementation. I also have created a GitHub issue . Supporting ONNX in MXNet