Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 1F55E200D23 for ; Thu, 19 Oct 2017 20:55:54 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 1DCDC1609EE; Thu, 19 Oct 2017 18:55:54 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id DF3261609D7 for ; Thu, 19 Oct 2017 20:55:52 +0200 (CEST) Received: (qmail 61001 invoked by uid 500); 19 Oct 2017 18:55:52 -0000 Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mxnet.incubator.apache.org Delivered-To: mailing list dev@mxnet.incubator.apache.org Received: (qmail 60988 invoked by uid 99); 19 Oct 2017 18:55:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Oct 2017 18:55:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id B27F31A1C0B for ; Thu, 19 Oct 2017 18:55:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.781 X-Spam-Level: * X-Spam-Status: No, score=1.781 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id K7HRvGtZaPzy for ; Thu, 19 Oct 2017 18:55:41 +0000 (UTC) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id CE25460CD3 for ; Thu, 19 Oct 2017 18:55:40 +0000 (UTC) Received: by mail-it0-f54.google.com with SMTP id j140so10923367itj.1 for ; Thu, 19 Oct 2017 11:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=zMFtLzzkDekdqskaLVztFhTKimIqbv5KeEzsQoNBpRo=; b=GW28VOZIum21Gn/tafJfUYDcpxaudIrckH02nP+SgTD1dT7RjFGWB97gSQ9ivQa50d OezEDV/tYVwkQZV3vX66RJH6PmX/6FNtGQBmDGLAFIG715GXmTsxxcU2k0uS65MqB41A I6PcvfilJP4ih47SuKKPENttOGkIFYEPf/Qp5MQpxxJ5d3FfuLNklEotmwQoc/5WnTWk NSK8TNioqCocDGoOyDHxr4MznVDJET6kmz1Bo/n25J67SjosODey74/he3QU6/cA3DMS ilp62HVEzIBQ+fat7y+wAKNtweA7gf65NxjIed4o8Uq+cVSfnNNTMgQWDhoAXKwexSN0 BzBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=zMFtLzzkDekdqskaLVztFhTKimIqbv5KeEzsQoNBpRo=; b=dzr1OuYMPP8pIgKC0ufJIfEVfcxfswHl0TakAZdrkLUdl99tM+xEC0i6X4LN4DS43a eT8h2zQILgznJy0pXcYv/J89CPL8t7KJXKG6vkezNXjgIslc4Y4uuiD2dnVAx7goq9zQ LSHVpmSA7Pk51R81xYFzic35nL4nYhlywigf5tF3zyXD0PIqBY0zeIYGn62dd5UcdWWK Uap/OtvlMla65dm18w09dqpxoxEbJcyRgiSl5/9AzcJa2ltBmKNsvqy6EcyQLojGRKql KhN/nyrzBYrdqsXyBvm3yhAdaIZuuF9OENXiFhpapeeuI/CSKbFnXiBjgGOeeRXLRa4X r8UA== X-Gm-Message-State: AMCzsaWIExDtoaTCvRemjtKaObpC9HA2rbdC74EvtAg6iMH1Q0BfZI9E Dn+1KMUIYrMixaLtrb6srK9rA+kDl9CW26SdjbmJ0A== X-Google-Smtp-Source: ABhQp+RtOLHHXPRfHbMw397/He4IFW87EQTFUJQlz90l4HnMMBjkKOqxO2NUz2DcNGP5l9leozZHrMchmSCde4KHPPA= X-Received: by 10.36.92.193 with SMTP id q184mr3489135itb.83.1508439338955; Thu, 19 Oct 2017 11:55:38 -0700 (PDT) MIME-Version: 1.0 Sender: workcrow@gmail.com Received: by 10.2.96.33 with HTTP; Thu, 19 Oct 2017 11:55:38 -0700 (PDT) In-Reply-To: References: <7EF8380D-7085-4D5D-9D0E-31518E72B9BA@gmail.com> From: Tianqi Chen Date: Thu, 19 Oct 2017 11:55:38 -0700 X-Google-Sender-Auth: xKVh8HS479HFlXpmYoJIKg2i6Ls Message-ID: Subject: Re: Request for suggestions- Supporting onnx in mxnet To: dev@mxnet.incubator.apache.org Content-Type: multipart/alternative; boundary="001a114453e0f6b861055beae624" archived-at: Thu, 19 Oct 2017 18:55:54 -0000 --001a114453e0f6b861055beae624 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 email thread. This (going through nnvm/top) is an important design decision both technically (compilation, more hardware) and strategically (articulate our core set of operators and influence the model exchange format). I am glad to see the discussion happening and surely there is doubt, as with every big step of changes. But with the rapidly changing pace of deep learning systems, this is the direction that we thought is most promising. We can call for a vote if necessary among the committers for the design decision if there is still debate on this issue. Or we can keep the discussion open and start some effort around nnvm/top to see how it goes Tianqi On Thu, Oct 19, 2017 at 11:15 AM, Lupesko, Hagay wrote: > Mu, > > You=E2=80=99re mentioning plans for a new model format and compiler, but = I don=E2=80=99t > recall seeing it shared/discussed on the dev list. Can you share these, s= o > it is more accessible to folks to understand the plan and vision? > > Personally, I think it will be a shame to add ONNX support to MXNet, and > have it implemented outside of MXNet. At the end of the day, it makes > things difficult for MXNet users. > > Hagay > > On 10/19/17, 10:01, "Mu Li" muli.cmu@gmail.com> wrote: > > I'm speaking under my "MXNet contributor" hat. > > It will be sad that our new model format and compiler is not supporte= d > 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 codes under https://github.com/aws. > > Best > Mu > > On Thu, Oct 19, 2017 at 9:51 AM, Lupesko, Hagay > wrote: > > > 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 > > check it out, we can consider future steps. > > > > Does this proposal make sense to folks? > > > > On 10/18/17, 23:01, "Tianqi Chen" > tqchen@cs.washington.edu> wrote: > > > > 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 thin= g > that > > is > > omitted. How should we build a good deploy end for deep learnin= g > > models. > > > > There is always a paradox to this problem: > > > > - On one hand, the deployment end needs to be lightweight and > portable. > > - We want a lot of optimizations (memory layout compute) and > feature > > support, this makes the project big. > > > > All the existing systems suffer from this problem. The solution > is > > simple, > > separates the optimization part from the actual runtime and > compiles > > the > > things down to a bare metal module. And this is the solution > nnvm/top > > compiler pipeline offer, which I believe will become a standard > > practice of > > deployment and where all systems go to > > > > Tianqi > > > > On Wed, Oct 18, 2017 at 10:03 PM, Tianqi Chen < > > tqchen@cs.washington.edu> > > wrote: > > > > > OK, there is some miscommunication in here I guess. We only > need to > > do a > > > "canonization" step in python API that goes a symbol to symbo= l > > translation > > > layer. It can be done in purely in python, and there is no > need for > > going > > > "down" into c++ to do this. > > > > > > For example, the current nnvm.from_mxnet API takes Module or > Gluon > > module > > > and get you back nnvm/top graph in python. > > > > > > All we are asking for is to decomposing it into > > > > > > def mxnet_to_onnx(module): > > > nnvm_graph, params =3D nnvm_from_mxnet(module) > > > onnx =3D nnvm_to_onnx(nnvm_graph, params) > > > return onnx > > > > > > This allows nnvm_from_mxnet to be reused for other purposes, > like > > > compiling API to deployable modules > > > > > > Tianqi > > > > > > On Wed, Oct 18, 2017 at 9:55 PM, Lupesko, Hagay < > lupesko@gmail.com> > > wrote: > > > > > >> Tianqi: > > >> Thanks for detailing the trends. I fully agree that ONNX is > just a > > graph > > >> serialization format =E2=80=93 nothing more, nothing less. I= also > think we > > all > > >> agree that this simple mechanism holds lots of value to DL > users > > since it > > >> allows them to move between frameworks easily (e.g. train wi= th > > MXNet, > > >> deploy on a mobile device with Caffe2, or the other way > around). > > >> As you said, In Memory IR is different than serialization > formats > > such as > > >> ONNX. They are designed to make the runtime execution as > efficient > > as > > >> possible, leveraging software and hardware optimizations. > They are > > indeed > > >> complex, and where the =E2=80=9Cmeat=E2=80=9D is. > > >> (BTW ONNX regards itself as an =E2=80=9CIR=E2=80=9D format, = but not in the > same > > sense as > > >> NNVM). > > >> > > >> At the end of the day, Roshani is aiming to deliver a simple > > >> functionality to MXNet users: (1) take an ONNX file, and loa= d > it > > into MXNet > > >> so you get a graph+weights you can work with (2) Given a > trained > > model, > > >> save it as an ONNX file. Since MXNet users do not interact > with NNVM > > >> directly, but rather interact with MXNet API (MXNet Module), > isn=E2=80=99t > > the > > >> simplest thing to do is just to construct the Module =E2=80= =9Con the > fly=E2=80=9D > > using > > >> MXNet API? Taking the other approach, we will go from the to= p > level > > MXNet > > >> =E2=80=9Cload=E2=80=9D API, go =E2=80=9Cdown=E2=80=9D to NNV= M to construct the graph, go back > up to > > MXNet > > >> to expose it as a Module. This seems to complex and does not > add any > > >> benefit. In whatever way we construct the MXNet Module > object, NNVM > > will > > >> always be the underlying in memory IR that is being executed= , > so > > why not > > >> take the simpler route? > > >> > > >> Hagay > > >> > > >> On 10/18/17, 19:42, "Tianqi Chen" behalf of > > >> tqchen@cs.washington.edu> wrote: > > >> > > >> Hi Chris: > > >> > > >> There is no intention to move things away from mxnet. Th= e > > 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 when > > >> there is nothing to be taken away." > > >> > > >> MXNet has always benefited from this philosophy and > improves > > with the > > >> new > > >> designs and proper modularization. For example, we see > such > > reduction > > >> and > > >> convenience happening when migrating from MXNet's legacy > op to > > the > > >> NNVM's mechanism. The new mechanism now enables things > like > > sparse > > >> aware > > >> support and other stuff which would be much harder to > support. > > >> > > >> The nnvm/tvm stack comes brings the same benefit(if not > more) > > and it > > >> will > > >> only add more features to MXNet itself. Offering more > hardware > > >> backends and > > >> optimization, allowing us to write less code and spent > less > > time to > > >> optimize for each backend by going through TVM > > >> > > >> Tianqi > > >> > > >> On Wed, Oct 18, 2017 at 7:15 PM, Chris Olivier < > > cjolivier01@gmail.com > > >> > > > >> wrote: > > >> > > >> > Reduce code base of mxnet? By increasing scope of the > dmlc > > modules? > > >> Is the > > >> > intent to make mxnet a thin language wrapper around a > group > > of dmlc > > >> > modules? > > >> > > > >> > > > >> > On Wed, Oct 18, 2017 at 6:58 PM Tianqi Chen < > > >> tqchen@cs.washington.edu> > > >> > wrote: > > >> > > > >> > > To better answer Hagay's question, I would like to > dive > > down a > > >> bit deeper > > >> > > on the relation between MXNet, NNVM and model exchan= ge > > 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. > > >> > > - The in-memory graph IR for quick optimization and > JIT. > > NNVM, > > >> > Tensorflow's > > >> > > XLA falls into this category. > > >> > > > > >> > > The exchange formats are great, it only poses a laye= r > of > > >> conversion, > > >> > which > > >> > > is good for exchange. The real meat still comes from > the > > >> compilation and > > >> > > JIT pipeline you have to offer. For that, we will > need an > > >> in-memory IR, > > >> > > because of the cost of constructing, serialize could > be > > high for > > >> the > > >> > > exchange formats like protobuf. And usually, the > exchange > > >> formats are > > >> > > designed in a minimalistic fashion, making it less > easy to > > extend > > >> more > > >> > > information to support in-depth optimization like > automatic > > >> quantization, > > >> > > accelerator support. > > >> > > > > >> > > The current MXNet relies on NNVM for in-memory IR > > manipulation > > >> but does > > >> > not > > >> > > contain a compilation component that compiles to the > > hardware > > >> backends. > > >> > > Doing export to an exchange format and then back int= o > NNVM > > run the > > >> > > compilation poses too much burden that JIT compiler > could > > pay. > > >> Using the > > >> > > same in-memory graph IR as the compilation stack giv= e > much > > more > > >> advantage > > >> > > in terms of this. > > >> > > > > >> > > The newly introduces nnvm/top and compiler offers > in-memory > > graph > > >> > > optimization and compilation and offers more hardwar= e > > backend > > >> directly > > >> > via > > >> > > TVM. We already see promising results in edge > deployments > > with a > > >> much > > >> > lower > > >> > > overhead of runtime. We will further benefit quickly > from > > more > > >> graph > > >> > > optimizations that it has to offer. > > >> > > > > >> > > Building support around this new paradigm offers us > > advantage of > > >> being > > >> > > future compatible and takes full benefit of the > points I > > >> mentioned above > > >> > > > > >> > > Tianqi > > >> > > > > >> > > > > >> > > > > >> > > On Wed, Oct 18, 2017 at 4:57 PM, Lupesko, Hagay < > > >> lupesko@gmail.com> > > >> > wrote: > > >> > > > > >> > > > Roshani =E2=80=93 this is an exciting initiative, = ONNX > support on > > MXNet > > >> will > > >> > > > enable more users to ramp up on MXNet, which is > great. > > >> > > > > > >> > > > Tianqi =E2=80=93 a few questions and thoughts abou= t your > note: > > >> > > > - =E2=80=9CMore hardware backends to mxnet=E2=80= =9D =E2=80=93 MXNet users > get the > > same > > >> benefit > > >> > of > > >> > > > HW support implementing ONNX import on top of MXNe= t > > symbolic, > > >> right? > > >> > > > - =E2=80=9CNNVM Compiler now received contribution= s from > AWS, UW > > and > > >> many other > > >> > > > folks in MXNet community.=E2=80=9D =E2=80=93 agree= d it is ramping > up, but > > when > > >> you look > > >> > > at > > >> > > > the data, it is clear that it is very early on for > NNVM. > > >> Looking at the > > >> > > > repo, it has overall 223 commits, 0 releases. > Compare it > > to > > >> MXNet with > > >> > > 6136 > > >> > > > commits and 32 releases. It seems to be still earl= y > on for > > >> NNVM, and > > >> > for > > >> > > a > > >> > > > more reliable initial implementation building the > import > > on top > > >> of > > >> > MXNet > > >> > > is > > >> > > > easier, faster and safer. 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. > > >> > > > > > >> > > > I=E2=80=99m supportive option 1 proposed by Roshan= i > (building > > serde on > > >> top of > > >> > > > MXNet symbolic), but to do it as an encapsulated > > implementation > > >> detail, > > >> > > so > > >> > > > the implementation can be migrated to NNVM or > another > > >> implementation in > > >> > > the > > >> > > > future, if at that point it seems like the right > thing to > > do. > > >> > > > > > >> > > > Interested in hearing other opinions though=E2=80= =A6 > > >> > > > > > >> > > > Hagay > > >> > > > > > >> > > > On 10/18/17, 14:13, "Tianqi Chen" < > workcrow@gmail.com on > > >> behalf of > > >> > > > tqchen@cs.washington.edu> wrote: > > >> > > > > > >> > > > 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 things are automatically > enabled > > by going > > >> > through > > >> > > > this > > >> > > > layer. In general, we design nnvm/tvm stack to > > resolve the > > >> > challenge > > >> > > of > > >> > > > current mxnet's weakness in terms deploying to > more > > hardware > > >> > > backends. > > >> > > > > > >> > > > - More frontend capabilities, nnvm's gluon > style IR > > ingests > > >> now > > >> > from > > >> > > > CoreML, ONNX and in future keras. Supporting > those > > will > > >> reduce the > > >> > > > amount > > >> > > > of engineering effort needed. > > >> > > > > > >> > > > - Future compatibility. We all agree that the > future > > being > > >> migrated > > >> > > to > > >> > > > gluon's API. NNVM/top tries to look ahead by > directly > > >> adopting the > > >> > > > symbolic > > >> > > > API to be gluon. > > >> > > > > > >> > > > > > >> > > > I would also like to correct some of the > mentioned > > facts > > >> with > > >> > regard > > >> > > to > > >> > > > nnvm/tvm stack > > >> > > > > > >> > > > 1. Nascent project with few contributors > > >> > > > > > >> > > > NNVM Compiler now received contributions from > AWS, UW > > and > > >> many > > >> > other > > >> > > > folks > > >> > > > in MXNet community. NNVM itself is already > being used > > by > > >> MXNet. > > >> > > > MXNet's internal IR is migrating toward gluon, > and its > > >> final form > > >> > > being > > >> > > > nnvm/top > > >> > > > > > >> > > > 3. Does not support all operators that exist > in > > MXNet > > >> Symbolic > > >> > API > > >> > > > > > >> > > > Neither NNVM/top or onnx support all operators > that > > exist > > >> in mxnet > > >> > > > symbolic > > >> > > > API. The end goal here is mainly to make > nnvm/top onnx > > >> compatible, > > >> > > > which is > > >> > > > a more reasonable goal. > > >> > > > > > >> > > > 4. No CI Pipeline and testcases > > >> > > > > > >> > > > NNVM already contains a compiler contains > unittests > > and ci > > >> tested > > >> > > with > > >> > > > integration https://github.com/dmlc/nnvm, > with a CI > > >> pipline that > > >> > is > > >> > > > well > > >> > > > tested on CPU and GPU cases for front-ends. > > >> > > > > > >> > > > Tianqi > > >> > > > > > >> > > > > > >> > > > On Wed, Oct 18, 2017 at 1:41 PM, Roshani > Nagmote < > > >> > > > roshaninagmote2@gmail.com> > > >> > > > wrote: > > >> > > > > > >> > > > > Hi guys, > > >> > > > > > > >> > > > > > > >> > > > > I am working on supporting ONNX < > > >> https://github.com/onnx/onnx> > > >> > > > pre-trained > > >> > > > > models in Apache MXNet and would like to see= k > your > > >> opinion on the > > >> > > > choice of > > >> > > > > implementation. I also have created a GitHub > issue > > >> > > > > > incubator-mxnet/issues/8319>. > > >> > > Supporting > > >> > > > ONNX > > >> > > > > in > > >> > > > > MXNet will enable users to move between > frameworks > > with > > >> their > > >> > > > models, this > > >> > > > > will also enable MXNet project to be a part > of the > > ONNX > > >> open > > >> > > > standard and > > >> > > > > steer the direction of ONNX. > > >> > > > > > > >> > > > > > > >> > > > > For those who don=E2=80=99t know ONNX, ONNX = is an open > > source > > >> format for > > >> > AI > > >> > > > models > > >> > > > > which enables models to be transferred betwe= en > > >> frameworks. Refer > > >> > to > > >> > > > > https://github.com/onnx/onnx for more > details. > > >> > > > > > > >> > > > > > > >> > > > > To implement the import/export functionality > in > > MXNet, I > > >> propose > > >> > to > > >> > > > expose > > >> > > > > a MXNet python module =E2=80=9Cserde=E2=80= =9D(name taken from > > Apache Hive > > >> > project) > > >> > > > with the > > >> > > > > following methods supporting different > formats: > > >> > > > > > > >> > > > > sym, params =3D mxnet.serde.import(other_ > format_file, > > >> > > > other_format=3D=E2=80=98onnx=E2=80=99) > > >> > > > > > > >> > > > > other_format_file =3D > mxnet.serde.export(mxnet_sym, > > >> mxnet_params, > > >> > > > =E2=80=98onnx=E2=80=99) > > >> > > > > > > >> > > > > > > >> > > > > The implementation under the hood can be don= e > in > > two ways: > > >> > > > > > > >> > > > > > > >> > > > > 1) Implement at the MXNet layer by parsing > the ONNX > > >> model(in > > >> > > protobuf > > >> > > > > format) and turn into MXNet Symbolic > operators and > > build > > >> MXNet > > >> > > model > > >> > > > > directly. Similarly, I can convert the MXNet > model > > to > > >> ONNX format > > >> > > at > > >> > > > this > > >> > > > > layer. > > >> > > > > > > >> > > > > > > >> > > > > 2) The DMLC community has released the > nnvm/tvm > > complier > > >> and an > > >> > > > > intermediate representation of the models, > refer: > > >> > > > > http://www.tvmlang.org/2017/ > > 10/06/nnvm/tvm-compiler- > > >> > > > announcement.html > > >> > > > > 10/06/nnvm-compiler- > > >> > announcement.html > > >> > > > > > >> > > > > > > >> > > > > Based on the conversation on the GitHub issu= e > > >> > > > > > incubator-mxnet/issues/8319> I > > >> > opened, > > >> > > Mu > > >> > > > > mentioned that MXNet would use nnvm/tvm as t= he > > backend in > > >> the > > >> > > future. > > >> > > > > > > >> > > > > > > >> > > > > We could hook into this layer to implement t= he > > >> import/export > > >> > > > functionality. > > >> > > > > nnvm/tvm has ONNX 0.1 version import > implemented. > > >> > > > > > > >> > > > > For import, > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > I will need to enhance nnvm/tvm=E2=80=99s= importer > to > > support > > >> ONNX 0.2 > > >> > > > > 2. > > >> > > > > > > >> > > > > Implement nnvm/tvm->mxnet symbolic > operators. > > >> > > > > > > >> > > > > For export: > > >> > > > > > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > mxnet->nnvm/tvm ( nnvm/tvm provides this > > implementation > > >> > already) > > >> > > > > 2. > > >> > > > > > > >> > > > > I will need to Implement nnvm/tvm>onnx. > > >> > > > > > > >> > > > > > > >> > > > > These are the pros and cons I see in the abo= ve > > approaches: > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > Import/export at mxnet layer > > >> > > > > > > >> > > > > Pros: > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > Stable APIs currently used by users. > > >> > > > > 2. > > >> > > > > > > >> > > > > Larger Apache MXNet community of > contributors. > > >> > > > > 3. > > >> > > > > > > >> > > > > CI pipeline to catch bugs. > > >> > > > > 4. > > >> > > > > > > >> > > > > Comparatively less time to implement and > put it > > in the > > >> hands > > >> > of > > >> > > > the > > >> > > > > users. > > >> > > > > > > >> > > > > Cons: > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > In the future we may have to reimplement > at the > > >> nnvm/tvm > > >> > layer, > > >> > > > in case > > >> > > > > MXNet moves to the nnvm/tvm > backend(assuming it > > will > > >> move). > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > Import/export at nnvm/tvm layer > > >> > > > > > > >> > > > > Pros: > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > Less engineering work in case mxnet moves > to > > nnvm/tvm > > >> > > > > 2. > > >> > > > > > > >> > > > > nnvm/tvm would become a hub to convert to > > different > > >> formats. > > >> > > > > 3. > > >> > > > > > > >> > > > > nnvm operators are more in parity with > mxnet=E2=80=99s > > gluon > > >> APIs this > > >> > > > could be > > >> > > > > useful in case Gluon becomes the only > standard > > that > > >> MXNet will > > >> > > > support. > > >> > > > > > > >> > > > > Cons: > > >> > > > > > > >> > > > > 1. > > >> > > > > > > >> > > > > Nascent project with few contributors > > >> > > > > 2. > > >> > > > > > > >> > > > > Does not support all operators that exist > in > > MXNet > > >> Symbolic > > >> > API > > >> > > > > 3. > > >> > > > > > > >> > > > > No CI Pipeline > > >> > > > > 4. > > >> > > > > > > >> > > > > Current Apache MXNet project does not use > > nnvm/tvm > > >> backend > > >> > > > > 5. > > >> > > > > > > >> > > > > mxnet->nnvm/tvm backend needs more testin= g > and > > user > > >> feedback. > > >> > > > > > > >> > > > > > > >> > > > > Any suggestions on both of these approaches? > From > > user's > > >> > > > perspective, this > > >> > > > > will be an implementation detail that is not > > exposed. > > >> > > > > > > >> > > > > Thanks, > > >> > > > > > > >> > > > > Roshani > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > --001a114453e0f6b861055beae624--