Re: [VOTE] Release Apache MXNet (incubating) 1.5.1.rc0

[Srivastava, Rohit Kumar]

+1 
build mxnet from source with large tensor support. Ran tests only for large 
array. All passed !

On 9/19/19, 2:58 PM, "Lai Wei"  wrote:

+1

build from source on GPU and tested with gluon estimator and latest
keras-mxnet.


Best Regards

Lai


On Thu, Sep 19, 2019 at 1:02 PM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> Thank you Tao for leading this and all the community members for helping 
in
> this release.
>
>
> +1
>
>
> -[Y] Are release files in correct location?
>
> -[Y] Do release files have the word incubating in their name?
>
> -[Y] Are the digital signature and hashes correct?
>
> -[Y] Does DISCLAIMER file exist?
>
> -[Y] Do LICENSE and NOTICE files exists?
>
> -[Y] Is the LICENSE and NOTICE text correct?
>
> -[Y] Is the NOTICE year correct?
>
> -[Y] Un-included software dependencies are not mentioned in LICENSE or
> NOTICE?
>
> -[Y] License information is not mentioned in NOTICE?
>
> Is there any 3rd party code contained inside the release? If so:
>
> -[N] Does the software have a compatible license?
>
> -[Y] Are all software licenses mentioned in LICENSE?
>
> -[Y] Is the full text of the licenses (or pointers to it) in LICENSE?
>
> Is any of this code Apache licensed? Do they have NOTICE files? If so:
>
> -[Y] Have relevant parts of those NOTICE files been added to this NOTICE
>
> file?
>
> -[Y] Do all source files have ASF headers?
>
> -[Y] Do the contents of the release match with what's tagged in version
> control?
>
> -[N] Are there any unexpected binary files in the release?
>
> -[Y] Can you compile from source? Are the instruction clear?
>
>
> Except the license issue mentioned in this Github issue -
> https://github.com/apache/incubator-mxnet/issues/15542
>
>
> I was able to build from source on GPU(p3.2x EC2 instance) and run
> opperf-operator
> benchmark utilit
> y
> successfully
> with no regression compared to v1.5.0.
>
>
>
>
> On Thu, Sep 19, 2019 at 11:51 AM Anirudh Subramanian <
> anirudh2...@gmail.com>
> wrote:
>
> > +1
> >
> > Build from source with cmake and ran unittest for gluon and amp.
> >
> > Noticed that test_sync_batchnorm fails on p3.8xlarge (hidden by the CI
> > because passes on machines with 1 or 2 gpus).
> > I have opened an issue for the same
> > https://github.com/apache/incubator-mxnet/issues/16214 though I think
> its
> > not a blocker for this release.
> >
> > Anirudh
> >
> > On Thu, Sep 19, 2019 at 11:28 AM Chaitanya Bapat 
> > wrote:
> >
> > > +1
> > >
> > > Correctly built for GPU, CPU on Ubuntu 14.01 (10.1 Cuda for GPU)
> > > Ran image classification (resnet50+cifar10)
> > > Ran Operator Performance (opperf)
> > >
> > > On Thu, 19 Sep 2019 at 02:12, Tao Lv  wrote:
> > >
> > > > Hi community,
> > > >
> > > > Friendly reminder: it is less than 1.5 days remaining, so please 
take
> > > your
> > > > time to verify and vote.
> > > >
> > > > Thanks,
> > > > -tao
> > > >
> > > > On Thu, Sep 19, 2019 at 3:06 PM Lin Yuan 
> wrote:
> > > >
> > > > > +1
> > > > > Tested Horovod on GPU
> > > > >
> > > > > On Wed, Sep 18, 2019 at 6:16 AM Zhao, Patric <
> patric.z...@intel.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Tested MKLDNN backend and everything looks great.
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Qing Lan 
> > > > > > > Sent: Wednesday, September 18, 2019 2:20 AM
> > > > > > > To: dev@mxnet.incubator.apache.org
> > > > > > > Subject: Re: [VOTE] Release Apache MXNet (incubating) 
1.5.1.rc0
> > > > > > >
> > > > > > > +1 for Scala/Java test. Passed all tests for CPU/GPU build.
> > > > > > > Also tested build from source with static build.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Qing
> > > > > > > 
> > > > > > > From: Tao Lv 
> > > > > > > Sent: Tuesday, September 17, 2019 14:14
> > > > > > > To: dev@mxnet.incubator.apache.org <
> > dev@mxnet.incubator.apache.org
> > > >
> > > > > > > Subject: [VOTE] Release Apache MXNet (incubating) 1.5.1.rc0
> > > > > > >
> > > > > > > Dear MXNet community,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This is the 3-day vote to release Apache MXNet (incubating)
> > version
> > > > > > 1.5.1.
> > > > > > >
> > > > > > > Voting on dev@ will start September 17, 12:00pm (PST)  and
> close
> > > on
> > >

Re: [Discuss] MXNet Python 2 Support Deprecation

[Srivastava, Rohit Kumar]

+1

On 7/19/19, 12:59 PM, "Zhu Zhaoqi"  wrote:

+1

Lin Yuan  于2019年7月19日周五 上午12:06写道：

> +1
>
> On Fri, Jul 19, 2019 at 12:03 AM Chaitanya Bapat 
> wrote:
>
> > +1 definitely.
> >
> > Going forward,
> > MXNet repo as it stands has ~95,000+ lines of Python code [1]
> > OpenEdx has a million (10x) LOC and this mammoth effort of porting from
> > Python 2 to 3 is treated as a separate project named Incremental
> > Improvement. [2]
> > We can take inspiration from them and have a similar effort by calling
> > action from the community. Issues can be maintained in a separate JIRA
> > board to track high priority tasks.
> >
> > Also, I can see gluon-nlp adding themselves to the Python3 statement.
> Once
> > the vote passes, one of us could submit a PR to add MXNet as well.
> >
> > [1] https://codeclimate.com/
> > [2]
> >
> https://open.edx.org/blog/python-2-is-ending-we-need-to-move-to-python-3/
> >
> >
> > On Thu, 18 Jul 2019 at 21:39, Kshitij Kalambarkar <
> > kshitijkalambar...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Fri, Jul 19, 2019, 04:28 Pedro Larroy  >
> > > wrote:
> > >
> > > > Seems 3.6 is a reasonable choice.
> > > >
> > > > On Thu, Jul 18, 2019 at 2:15 PM Marco de Abreu <
> > marco.g.ab...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Looking at EOL is certainly a good idea! I think once we get 
closer
> > to
> > > > > deprecation, we can check adoption statistics to make a
> well-informed
> > > > > decision that gives us the most advantages without dropping the
> ball
> > > on a
> > > > > majority of users (or supporting a branch that is going EOL soon).
> A
> > > > survey
> > > > > from 2018 [1] determined the following distribution:
> > > > > 3.5: 11%
> > > > > 3.6: 54%
> > > > > 3.7: 30%
> > > > >
> > > > > Deprecation for 3.5 is scheduled for 2020-09-13 [2]. Deprecation
> for
> > > 3.6
> > > > is
> > > > > scheduled for 2021-12-23 [2].Deprecation for 3.7 is scheduled
> > > > > for 2023-06-27 [2].
> > > > >
> > > > > Following the trend, I'd say that it would be a decision between
> > Python
> > > > 3.6
> > > > > and 3.7. Later on, I'd propose to check recent surveys and also
> have
> > a
> > > > > separate thread to determine if there's anything we're missing
> (e.g.
> > a
> > > > big
> > > > > company being unable to use Python 3.7). What do you think?
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > > > [1]:
> > https://www.jetbrains.com/research/python-developers-survey-2018/
> > > > > [2]: https://devguide.python.org/#status-of-python-branches
> > > > >
> > > > > On Thu, Jul 18, 2019 at 9:42 PM Yuan Tang  >
> > > > wrote:
> > > > >
> > > > > > I would suggest supporting Python 3.5+ since the earlier 
versions
> > > have
> > > > > > reached end-of-life status:
> > > > > > https://devguide.python.org/devcycle/#end-of-life-branches
> > > > > >
> > > > > > On Thu, Jul 18, 2019 at 3:36 PM Pedro Larroy <
> > > > pedro.larroy.li...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > This would simplify CI, reduce costs and more. I think a
> followup
> > > > > > > question is what would be the mininum Python3 version
> supported?
> > > > > > > Depending on that we might be able to use type annotations for
> > > > example
> > > > > > > or other features.
> > > > > > >
> > > > > > > Pedro.
> > > > > > >
> > > > > > > On Thu, Jul 18, 2019 at 12:07 PM Yuan Tang <
> > > terrytangy...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > On Thu, Jul 18, 2019 at 2:51 PM Yuxi Hu <
> darreny...@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > On Thu, Jul 18, 2019 at 11:31 AM Tong He <
> > hetong...@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > >
> > > > > > > > > > Tong He
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Jake Lee  于2019年7月18日周四 上午11:29写道：
> > > > > > > > > >
> > > > > > > > > > > +1
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jul 18, 2019 at 11:27 AM Junru Shao <
> > > > > > > junrushao1...@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jul 18, 2019 at 11:12 AM Anirudh Acharya <
> > > > > > > > > > anirudhk...@gmail.com>
> > > > > > > > > > > > 

Re: [RFC] Support for creation of Large Tensors in MXNet

[Srivastava, Rohit Kumar]

Hi Tao,
Existing MXNet implementation doesn't support large tensors. MXNet NDArray 
creation for tensors of sizes larger than 2^32 is only supported by enabling a 
build flag for now. The purpose of this thread is to have the community provide 
feedback on the design cwiki for *Large Tensor Support* in MXNet. The intension 
is to make large tensor support as default feature in MXNet (in future) w/o any 
performance impact so consumers do not have to build it from source. 

-Rohit

On 5/18/19, 5:59 PM, "Lv, Tao A"  wrote:

Hi Rohit,

The existing MKL-DNN and its integration in MXNet should already support 
*large tensor* which means the total number of elements (Prod(shape)) can 
exceed INT_MAX. Feel free to me know if you find any issue when using MKL-DNN 
operators with large tensors.

For large dimension size (shape[x]), MKL-DNN is going to support in its 1.0 
release and will be released at the middle of year. But I'm not sure if MXNet 
has plan to support that.

Thanks,
-tao

-Original Message-
    From: Srivastava, Rohit Kumar [mailto:srivastava@buckeyemail.osu.edu] 
Sent: Sunday, May 19, 2019 7:23 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RFC] Support for creation of Large Tensors in MXNet

Hi Tao,
There are already couple of operators implemented in MXNet that are 
currently supporting Tensors with size over ~4.5 billion. In the meantime core 
MXNet can move ahead with providing initial support for such large tensors so 
MXNet customers can start using it.

Good to hear MKLDNN will provide support for such cases. Do you have a 
timeline as to when this feature will be released ?

-Rohit

On 4/29/19, 7:18 PM, "Lv, Tao A"  wrote:

Thank you Lin! I would expect the current MKL-DNN implementation 
already supports the scenario you mentioned here. Can be verified by this 
issue: https://github.com/apache/incubator-mxnet/issues/13451

But as I said before, since we support flatten or reshape operators, so 
it's possible for users to convert a tensor with large element size to a tensor 
with large dimension size. It possibly will cause issue there.

To cover more cases, MKL-DNN is going to support INT64 dimension size 
in its coming 1.0 major release.

-tao

-Original Message-
From: Lin Yuan [mailto:apefor...@gmail.com] 
Sent: Tuesday, April 30, 2019 12:56 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RFC] Support for creation of Large Tensors in MXNet

Tao,

- what's the max size of dimensionality? Which data type is used to 
define dimensionality (ndims)?
We assume the max size of dimensionality is relatively small. Hence 
`int` data type is used to define ndim

- what's the max size of each dimension? Which data type is used to 
define dimension size (shape[x])?
Currently, we assume the max size of each dimension is not going to 
exceed
2^31 in real applications. Hence the data type is `int32_t`

- what's the max size of total elements? Which data type is used to 
define element size (Prod(shape))?
We assume the total number of elements in a tensor can be larger than 
2^32 in some applications such as deep graph library. We use the data type 
`int64_t` to represent the total element size. Currently due to performance 
regression in some operators (such as transpose), we used a compiler flag to 
set this data type to `int32_t` by default. Once we have ways to mitigate the 
performance regression, we will set the default data type to `int64_t`, which 
is part of the effort in this project that Rohit proposed.

What is the plan in MKLDNN to support large tensors? We may want to 
coordinate the progress since many operators are using MKLDNN implementation in 
CPU now.

Many Thanks,

Lin

On Sun, Apr 28, 2019 at 7:52 PM Lv, Tao A  wrote:

> Thank you for bringing this topic to dev, Rohit.
>
> Regarding large tensor, can you articulate:
> - what's the max size of dimensionality? Which data type is used to 
> define dimensionality (ndims)?
> - what's the max size of each dimension? Which data type is used to 
> define dimension size (shape[x])?
> - what's the max size of total elements? Which data type is used to 
> define element size (Prod(shape))?
>
> For me, any of these three can be *large*.
>
> -Original Message-
> From: Srivastava, Rohit Kumar 
> [mailto:srivastava@buckeyemail.osu.edu]
> Sent: Saturday, April 27, 2019 7:33 AM
   

Re: [RFC] Support for creation of Large Tensors in MXNet

[Srivastava, Rohit Kumar]

Hi Tao,
There are already couple of operators implemented in MXNet that are 
currently supporting Tensors with size over ~4.5 billion. In the meantime core 
MXNet can move ahead with providing initial support for such large tensors so 
MXNet customers can start using it.

Good to hear MKLDNN will provide support for such cases. Do you have a timeline 
as to when this feature will be released ?

-Rohit

On 4/29/19, 7:18 PM, "Lv, Tao A"  wrote:

Thank you Lin! I would expect the current MKL-DNN implementation already 
supports the scenario you mentioned here. Can be verified by this issue: 
https://github.com/apache/incubator-mxnet/issues/13451

But as I said before, since we support flatten or reshape operators, so 
it's possible for users to convert a tensor with large element size to a tensor 
with large dimension size. It possibly will cause issue there.

To cover more cases, MKL-DNN is going to support INT64 dimension size in 
its coming 1.0 major release.

-tao

-Original Message-
From: Lin Yuan [mailto:apefor...@gmail.com] 
Sent: Tuesday, April 30, 2019 12:56 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RFC] Support for creation of Large Tensors in MXNet

Tao,

- what's the max size of dimensionality? Which data type is used to define 
dimensionality (ndims)?
We assume the max size of dimensionality is relatively small. Hence `int` 
data type is used to define ndim

- what's the max size of each dimension? Which data type is used to define 
dimension size (shape[x])?
Currently, we assume the max size of each dimension is not going to exceed
2^31 in real applications. Hence the data type is `int32_t`

- what's the max size of total elements? Which data type is used to define 
element size (Prod(shape))?
We assume the total number of elements in a tensor can be larger than 2^32 
in some applications such as deep graph library. We use the data type `int64_t` 
to represent the total element size. Currently due to performance regression in 
some operators (such as transpose), we used a compiler flag to set this data 
type to `int32_t` by default. Once we have ways to mitigate the performance 
regression, we will set the default data type to `int64_t`, which is part of 
the effort in this project that Rohit proposed.

What is the plan in MKLDNN to support large tensors? We may want to 
coordinate the progress since many operators are using MKLDNN implementation in 
CPU now.

Many Thanks,

Lin

On Sun, Apr 28, 2019 at 7:52 PM Lv, Tao A  wrote:

> Thank you for bringing this topic to dev, Rohit.
>
> Regarding large tensor, can you articulate:
> - what's the max size of dimensionality? Which data type is used to 
> define dimensionality (ndims)?
> - what's the max size of each dimension? Which data type is used to 
> define dimension size (shape[x])?
> - what's the max size of total elements? Which data type is used to 
> define element size (Prod(shape))?
>
> For me, any of these three can be *large*.
>
> -Original Message-
> From: Srivastava, Rohit Kumar 
> [mailto:srivastava@buckeyemail.osu.edu]
> Sent: Saturday, April 27, 2019 7:33 AM
> To: dev@mxnet.incubator.apache.org
> Subject: [RFC] Support for creation of Large Tensors in MXNet
>
> Dear Community,
>
> Currently MXNet supports creation of Tensors containing up to 2^32 
> elements. However there are cases where tensors of size over 5 billion 
> is required
>
> We plan to support creation of large tensors on MXNet. A design 
> proposal is ready for review:
> https://cwiki.apache.org/confluence/display/MXNET/Large+Tensor+Support
>
> We will appreciate any help and feedbacks from the community.
>
> Thank you!
>
> Rohit
>

[RFC] Support for creation of Large Tensors in MXNet

[Srivastava, Rohit Kumar]

Dear Community,

Currently MXNet supports creation of Tensors containing up to 2^32 elements. 
However there are cases where tensors of size over 5 billion is required

We plan to support creation of large tensors on MXNet. A design proposal is 
ready for review:
https://cwiki.apache.org/confluence/display/MXNET/Large+Tensor+Support

We will appreciate any help and feedbacks from the community.

Thank you!

Rohit

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[Srivastava, Rohit Kumar]

+1

On 8/29/18, 8:39 AM, "sandeep krishnamurthy"  
wrote:

+1 Thanks for bringing this up.

On Wed, Aug 29, 2018 at 6:38 AM Marco de Abreu
 wrote:

> +1
>
> On Wed, Aug 29, 2018 at 1:08 PM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > +1 (non-binding)
> >
> > On Wed, Aug 29, 2018, 1:18 AM Anirudh Acharya 
> > wrote:
> >
> > > +1 for discontinuing.
> > >
> > > On Tue, Aug 28, 2018 at 4:11 PM Naveen Swamy 
> wrote:
> > >
> > > > +1 to stop supporting Win7
> > > >
> > > > On Tue, Aug 28, 2018 at 3:54 PM Lin Yuan 
> wrote:
> > > >
> > > > > Dear Community,
> > > > >
> > > > >
> > > > >
> > > > > Currently, our MXNet installation guide for Windows does not work
> for
> > > > > Windows 7. e.g. Microsoft Visual Studio 2015 is not supported on
> > > Windows
> > > > 7
> > > > > <
> > > > >
> > > >
> > >
> >
> 
https://visualstudio.microsoft.com/vs/support/vs2015/received-error-specified-program-requires-newer-version-windows/
> > > > > >.
> > > > > In addition, MSFT ended “Mainstream” support for Windows 7 in 2015
> (
> > > > >
> > > >
> > >
> >
> 
https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
> > > > > ).
> > > > > Therefore, it is not possible for developers to build MXNet and
> > verify
> > > > the
> > > > > fix on Windows 7 platform. Given that there have been several
> issues
> > > > about
> > > > > MXNet error on Windows 7 (issue#9271
> > > > > , issue
> #8921
> > > > > , issue
> > #11163
> > > > > ), it will
> > > even
> > > > > add
> > > > > more burden on developers in the future if we were to continue
> > > supporting
> > > > > Windows 7.
> > > > >
> > > > >
> > > > >
> > > > > I therefore would like to propose that we discontinue the support
> of
> > > > MXNet
> > > > > on Windows 7 in the next release.
> > > > >
> > > > >
> > > > > Specifically, this means the following required actions:
> > > > >
> > > > > 1) state the discontinuation of Windows 7 support in the release
> note
> > > > >
> > > > > 2) update the MXNet webpage if Windows version is mentioned.
> > > > >
> > > > > 3) update the open Github issues related to Windows 7
> > > > >
> > > > >
> > > > > Please share your thoughts about this proposal and/or suggest if
> > there
> > > is
> > > > > any other missing action item from the above.
> > > > >
> > > > >
> > > > > Best Regards,
> > > > >
> > > > >
> > > > > Lin
> > > > >
> > > >
> > >
> >
>


-- 
Sandeep Krishnamurthy