Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Leonard Lausen]

NNPACK is currently only supported in the Makefile build 
(https://github.com/apache/incubator-mxnet/issues/15974), which will be 
removed. I think oneDNN (mkldnn) replaced it and we can remove it. Any concerns?

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-659039903

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Haibin Lin]

Drop the following loss operators since they are used with Module API:
- mx.symbol.LinearRegressionOutput
- mx.symbol.MAERegressionOutput
- mx.symbol.LogisticRegressionOutput
- mx.symbol.SVMOutput
- mx.symbol.SoftmaxOutput


-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-642389680

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[yifeim]

> the main function you listed will all be available in 2.x.

 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-639266219

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

@yifeim module API will continue to be supported in 1.x and users are free to 
stay on that version. For 2.x, we will only support numpy/npx API so users who 
adopt those API will have to reimplement the model anyway. the main function 
you listed will all be available in 2.x.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-639131712

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[yifeim]

Hi there, I am too a little concerned about dropping module support. Since a 
large percent of the user based started with module APIs, dropping that support 
could alienate the user base.

I got familiar around mxnet-1.3. The main functions I appreciate are:
1. sparse vector symbols - which are still best supported on module API or 
Symbol-Gluon;
2. control flow operators - which allow people to create basically any 
arbitrary operator that they would want (though it is still not quite 
arbitrary);
3. linalg package - some quite sophisticated algorithms that would not be easy 
to replicate.
4. Hybridize - some amount of input validation is desirable in shared 
libraries. I am not looking for the speed change, but rather the idea that I 
can easily catch the edge cases with a defined graph. To the gist of it, I do 
want to see more supports such as memory estimation / compute time estimation / 
nan checking, some of which are available in TVM.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-639087830

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

mxnet.rnn module should be deprecated and removed too given it's designed for 
interacting with symbol API.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-619624835

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

@zhreshold thanks for bringing this up. Currently the test for that is the 
longest running one too, so if there's no objection I hope that we could move 
forward in removing it soon

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-615394771

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Joshua Z. Zhang]

In the long run, gluon vision model zoo will be maintained in GluonCV and 
therefore mxnet.gluon.vision.model_zoo should be deprecated to avoid duplicate 
maintenance efforts in 2.0

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-613682982

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

caffe usage is very low now and let's deprecate caffe converter too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-613546835

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Lanking]

> @lanking520 @zachgk @terrytangyuan @aaronmarkham could one of you start a 
> discussion in a new issue on the JVM ecosystem support in 2.0? This topic 
> seems to require extended discussion.

I created one here https://github.com/apache/incubator-mxnet/issues/17783

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595923653

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

@lanking520 @zachgk @terrytangyuan @aaronmarkham could one of you start a 
discussion in a new issue on the JVM ecosystem support in 2.0? This topic seems 
to require extended discussion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595911490

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Good question. I don't know. There wasn't a new release then. 路‍♀ 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595885111

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Aaron Markham]

> Thanks @zachgk - I took a couple of screenshots so I could share here
> 
> Here is the Scala package
> ![scala-mxnet](https://user-images.githubusercontent.com/340299/76096507-3b206a00-5f94-11ea-839a-168fb923a59d.png)
> 
> and here is the Clojure package
> ![clojure-mxnet-downloads](https://user-images.githubusercontent.com/340299/76096528-41164b00-5f94-11ea-8313-5bfbc97ff689.png)
> 
> There are far more Scala downloads that Clojure.
> 
> @lanking520 and other Scala package maintainers. I thank you for all the work 
> that you've done on the Scala package so far. I will support whatever 
> decision makes most sense for the Scala package and for the JVM MXNet users 
> for 2.0.
> 
> Let's just make a plan and coordinate whatever that is so that the current 
> users have the most information to plan accordingly.

What's the big spike in January?

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595882233

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

I vote for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as
it took us a lot of efforts to bring MXNet to Scala originally and there
are already adopters of Scala API in industries.

On Fri, Mar 6, 2020 at 11:02 AM Wang Jiajun 
wrote:

> > We may also drop ONNX in MXNet 2. I'm not aware of anyone working on
> ONNX in MXNet and TVM can be used as a replacement.
>
> +1 for keeping ONNX support. Although it has a lot of small problems, but
> I've converted a lot of pytorch models to mxnet for deploying with the
> following pipeline:
>
> https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-onnx-pytorch-mxnet.html
>
> --
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub:
>
> https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595835658



-- 
Yuan Tang
https://terrytangyuan.github.io/about/ 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595840489

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Yuan Tang]

+1 for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as it took 
us a lot of efforts to bring MXNet to Scala originally and there are already 
adopters of Scala API in industries.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595840427

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Yuan Tang]

I vote for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as
it took us a lot of efforts to bring MXNet to Scala originally and there
are already adopters of Scala API in industries.

On Fri, Mar 6, 2020 at 11:02 AM Wang Jiajun 
wrote:

> > We may also drop ONNX in MXNet 2. I'm not aware of anyone working on
> ONNX in MXNet and TVM can be used as a replacement.
>
> +1 for keeping ONNX support. Although it has a lot of small problems, but
> I've converted a lot of pytorch models to mxnet for deploying with the
> following pipeline:
>
> https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-onnx-pytorch-mxnet.html
>
> --
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub:
>
> https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595835658



-- 
Yuan Tang
https://terrytangyuan.github.io/about/ 

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Wang Jiajun]

> We may also drop ONNX in MXNet 2. I'm not aware of anyone working on ONNX in 
> MXNet and TVM can be used as a replacement.

+1 for keeping ONNX support. Although it has a lot of small problems, but I've 
converted a lot of pytorch models to mxnet for deploying with the following 
pipeline:
https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-onnx-pytorch-mxnet.html

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595835658

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Thanks @zachgk  - I took a couple of screenshots so I could share here

Here is the Scala package
![scala-mxnet](https://user-images.githubusercontent.com/340299/76096507-3b206a00-5f94-11ea-839a-168fb923a59d.png)

and here is the Clojure package
![clojure-mxnet-downloads](https://user-images.githubusercontent.com/340299/76096528-41164b00-5f94-11ea-8313-5bfbc97ff689.png)

There are far more Scala downloads that Clojure.

@lanking520 and other Scala package maintainers. I thank you for all the work 
that you've done on the Scala package so far. I will support whatever decision 
makes most sense for the Scala package makes for the JVM MNNet users for 2.0.

Let's just make a plan and coordinate whatever that is so that the current 
users have the most information to plan accordingly.



-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595818419

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Zach Kimberg]

@gigasquid Yeah, you can view the download statistics from 
https://repository.apache.org/#central-stat.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595522607

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Is there anyway to get the stats on downloads of the maven central 
scala/clojure jars to see how much current use there is? If the numbers are 
high or low and what trend is can help shape the decision

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595511949

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Lanking]

@gigasquid @zachgk Since the Scala API are built a while ago, I can see some of 
the deprecated sections: Module, DataparallelGroup, Symbol ... Most of the 
training component would be invalid. There can be three approaches:
- upgrade/rewrite Scala API and bring up MXNet 2.0 features.
- drop Scala API
- adopt DJL (DeepJavaLibrary) to be the Java/Scala/Clojure backend.

I am not sure which way works the best, please leave any thoughts you have.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595380125

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Further thinking this through - since the Scala language binding currently 
provides the base for both Java and Clojure, I would be nice to know what the 
future plans for the Scala language binding is. Whether or not that path is 
supported will determine the other JVM langs.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595256200

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

If I understand this correctly, since the Scala, Java, and Clojure bindings use 
symbol and ndarray exclusively, this will also mean that they will be 
effectively deprecated as well.

This is fine if what the community decides upon, but it should be called out 
explicitly.

cc @lanking520 @nswamy @kedarbellare 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595245038

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

@TaoLv the search result shows API in the following categories:
- operator (these will be deprecated and the newest version should be covered 
in https://github.com/apache/incubator-mxnet/issues/17096)
- gluon blocks (e.g. Con**v1**D). they are not legacy ops and will be kept
- io (these will be deprecated and replacement is covered in 2.0 roadmap item 
4.8 data API enhancement)
- model zoo (e.g. ResNet**V1**). they are not legacy API and will be kept

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595018894

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Tao Lv]

We have `v1` and `v2` APIs like:
https://mxnet.incubator.apache.org/api/python/docs/search.html?q=v1
https://mxnet.incubator.apache.org/api/python/docs/search.html?q=v2

Do we need cover them in the RFC? How to deprecate or unify these APIs?


-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-594984804

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Przemyslaw Tredak]

I am generally in favor of those deprecations. The scariest part is the removal 
of `mx.module` API, so definitely `Gluon is on par with module in terms of 
functionality and performance` is very important for this to be successful. 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-594945007

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

TensorRT support is currently using ONNX to convert from NNVM: 
https://github.com/apache/incubator-mxnet/blob/746cbc55fd666bb4529e88d247fed8e0907270f9/src/operator/subgraph/tensorrt/tensorrt.cc#L313-L318

Although I would like to see TensorRT support moved away from ONNX with a 
native integration using the Accelerator API compile support: 
https://github.com/apache/incubator-mxnet/pull/17623. But the migration from 
ONNX to AccAPI is still in discussion and the compile support PR is not merged 
yet (shameless plug: please review! :-D)

Sam

On Feb 28, 2020, at 9:06 PM, JackieWu 
mailto:notificati...@github.com>> wrote:

I think we should keep ONNX APIs, since it is able to export many basic models, 
although it is not perfect. Users will train their models in MXNet 2.0, and 
export ONNX model,  then use the ONNX model in their deployment frameworks. 
(http://onnx.ai/supported-tools).

It is useful to attract users to use MXNet 2.0 to train their models with ONNX.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-592878029



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-593574187

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Skalicky, Sam]

TensorRT support is currently using ONNX to convert from NNVM: 
https://github.com/apache/incubator-mxnet/blob/746cbc55fd666bb4529e88d247fed8e0907270f9/src/operator/subgraph/tensorrt/tensorrt.cc#L313-L318

Although I would like to see TensorRT support moved away from ONNX with a 
native integration using the Accelerator API compile support: 
https://github.com/apache/incubator-mxnet/pull/17623. But the migration from 
ONNX to AccAPI is still in discussion and the compile support PR is not merged 
yet (shameless plug: please review! :-D)

Sam

On Feb 28, 2020, at 9:06 PM, JackieWu 
mailto:notificati...@github.com>> wrote:

I think we should keep ONNX APIs, since it is able to export many basic models, 
although it is not perfect. Users will train their models in MXNet 2.0, and 
export ONNX model,  then use the ONNX model in their deployment frameworks. 
(http://onnx.ai/supported-tools).

It is useful to attract users to use MXNet 2.0 to train their models with ONNX.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-592878029

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[JackieWu]

I think we should keep ONNX APIs, since it is able to export many basic models, 
although it is not perfect. Users will train their models in MXNet 2.0, and 
export ONNX model,  then use the ONNX model in their deployment frameworks. 
(http://onnx.ai/supported-tools).

It is useful to attract users to use MXNet 2.0 to train their models with ONNX. 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-592878029

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Leonard Lausen]

We may also drop ONNX in MXNet 2. I'm not aware of anyone working on ONNX in 
MXNet and TVM can be used as a replacement.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-592782629

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Tao Lv]

What about those v1, v2 APIs?

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-591754890

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

cc @apache/mxnet-committers 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-591743914

[apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Sheng Zha]

As the MXNet community is working on the next major version of MXNet as 
described in #16167, this RFC seeks to clarify the scope of API deprecation, to 
inform the community of the replacement API design, and to ensure informed 
consensus.

Thanks to the long history of MXNet and the accumulated efforts of the 
community, MXNet now supports a wide range of neural network model training and 
deployment use cases. Many of these use cases have seen several generations of 
API design and implementation. Take model training as an example, there have 
been the Symbol Model API, Symbol Module API, and Gluon Hybrid Block API, all 
of which coexist in MXNet. Older generations of API often have a significant 
body of users and thus require time from the community to maintain, even though 
the supported use cases are mostly covered by a newer generation of API. Such 
requirement for maintenance not only consumes time and energy of the MXNet 
community and can distract the community from its longer term goal, but also 
causes pressure on CI, binary distribution.

In this RFC, we list several candidate API to be deprecated and the 
corresponding new generation of API as replacement. Unless otherwise stated, 
these APIs will continue to be supported in the future 1.x releases that happen 
in parallel to the 2.0 development. On the other hand, participating in the RFC 
for the new replacement feature of the feature you are interested in is the 
best way to ensure continued support in 2.0 for that feature. To make it easier 
to navigate, the replacement feature RFCs are linked in each section.

To make the discussion more productive, I recommend the following actions:

* If a feature in MXNet that you are interested in currently depend on any of 
the deprecated API, and you plan to switch from 1.x to 2.0, please participate 
in the RFC for the replacement feature. Please also direct any related 
questions with respect to how the replacement feature covers your use cases to 
the replacement feature RFCs.
* If after discussion in the replacement RFCs, you believe that the replacement 
feature cannot replace the candidate feature for deprecation, please call out 
in this RFC.
* Make sure to include your argument on why it’s the case, and clarify what 
use case cannot be supported in the new feature.
* If you wish to commit time and sponsor the continued maintenance beyond 
what’s specified in the following sections, please state so along with your 
comment.
* You may also seek other community members to sponsor the feature as 
comments in this RFC.
* The group of sponsors needs to collectively clarify what additional 
support the feature will receive from them, and commit to the cost of 
maintenance, development, and operations (such as CI).


Please always keep the discussion civilized and informative. Comments otherwise 
will be folded.

## mxnet.numpy and mxnet.ndarray

Traditionally MXNet provided `mx.nd` API with operators inspired, but often 
incompatible with Numpy. Based on RFC 
[#14253](https://github.com/apache/incubator-mxnet/issues/14253) there has been 
a large and ongoing effort to provide Numpy compatible operators in `mx.np` 
namespace.
This means that MXNet currently provides two incompatible APIs with separate 
backend implementations achieving similar goals, doubling the maintenance 
burden of developers. Note that there are some deep learning operators in 
`mx.nd` that don't have the counterparts in `mx.np`. These operators will be 
migrated to `mx.npx` namespace and will be tracked in #17096.

Given the wide impact of this decision, these people convened on 2/19/2020 and 
reached consensus on recommending **Removal** and parallel maintenance of 1.x 
and 2.x as the option forward: @eric-haibin-lin, @mli, @haojin2, @szhengac, 
@yizhiliu, @sxjscience, @reminisce, @leezu, @zhreshold, @apeforest, @oorqueda, 
@rondogency

| Options | Removal 

| Deprecation   




  | Separate Compatibility API  




  |