Re: [Discuss] MXNet Python 3.6 Support Deprecation

2019-11-06 Thread Lausen, Leonard 
Numpy team decided to wait another 4 weeks before dropping Python 3.5.
So they'll drop it in the 1.19 release.

Reference: 
https://mail.python.org/pipermail/numpy-discussion/2019-October/080191.html

On Wed, 2019-11-06 at 14:36 -0800, Pedro Larroy wrote:
> In Numpy they are considering dropping 3.5 support for 1.18 or 1.19.
> 
> P.
> 
> On Tue, Nov 5, 2019 at 11:15 PM Xingjian SHI  wrote:
> 
> > I don’t think we should drop Python 3.5 now because Ubuntu 16.04 ships
> > with that version. I suggest that we should revisit it next year.
> > 
> > Best,
> > Xingjian
> > 
> > From: Sheng Zha 
> > Sent: Tuesday, August 27, 2019 10:49 AM
> > To: d...@mxnet.apache.org
> > Subject: Re: [Discuss] MXNet Python  3.6 Support Deprecation
> > 
> > Good summary. At the start the discussion thread my ask is to announce the
> > intention of py2 deprecation in the next release, and then actually
> > deprecate py2 in the next major release. Thus, the appropriate timing for
> > dropping py2 support in CI should be the start of the next major release.
> > The py35 vs py36 discussion will not affect the outcome of py2 deprecation.
> > 
> > BTW, one alternative option to a formal voting in the Apache way is to
> > through lazy consensus [1], which could apply more in our project. Given
> > the positive feedback in this discussion thread, I will assume lazy
> > consensus in 72hrs on py2 deprecation as defined above.
> > 
> > [1] https://community.apache.org/committers/lazyConsensus.html
> > 
> > On 2019/08/27 00:19:14, Marco de Abreu  wrote:
> > > Pedro,
> > > 
> > > thanks for already starting these efforts, but it might be too early for
> > > that. Right now, this is a discussion thread where we try to gather
> > > different opinions in order to lay a good base for a future voting
> > thread.
> > > In there, we would define the detailed timeline, versions etc. Until the
> > > vote has passed, I'd say that it's too early to draw any conclusions. So
> > > far, there are two open discussion points:
> > > 
> > > 1. Which Python version to support. 3.5 vs 3.6 is currently in the
> > > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest
> > > market share being 3.6 as of now.
> > > 2. When to do the deprecation. EOY to match with official Python 2
> > > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the
> > > next major release (2.0) to adhere to semantic versioning.
> > > 
> > > Once these points (and any future ones) have been properly discussed and
> > > the community came to an agreement, we can formalize it with a voting
> > > thread. Until then, I'd recommend to refrain from any actions or
> > > user-facing communication regarding this topic.
> > > 
> > > Best regards,
> > > Marco
> > > 
> > > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > > wrote:
> > > 
> > > > I have sent a PR that removes Python2 from CI. But was closed. I
> > thought
> > > > everyone was +1 on this one. This would remove quite a bit of load on
> > CI:
> > > > https://github.com/apache/incubator-mxnet/pull/15990
> > > > 
> > > > If it's not the right time to do this, what steps do we need to take?
> > > > 
> > > > Pedro.
> > > > 
> > > > 
> > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen 
> > wrote:
> > > > > Lieven Govaerts  writes:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen 
> > > > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Pedro stated "Seems 3.6 is a reasonable choice." and there have
> > been a
> > > > > > > few +1 after Chaitanya's reply to Pedro. I would like to check if
> > > > these
> > > > > > > only refer to Chaitanya's mail about a dedicated "improvement"
> > effort
> > > > or
> > > > > > > about dropping 3.5.
> > > > > > > 
> > > > > > > Thus two questions:
> > > > > > > 
> > > > > > > 1) Are there any concerns about dropping Python 3.5? Now is your
> > > > chance
> > > > > to
> > > > > > > speak up if you think so.
> > > > > > > 
> > > > > > > 
> > > > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are
> > > > > supported
> > > > > > for 5 years, so for 16.04 LTS it ends in 1.5 years.
> > > > > > 
> > > > > > I'm not saying you should wait for 1.5 more years, people can
> > upgrade
> > > > to
> > > > > > 18.04 LTS after all, but may I suggest you make this switch in a
> > major
> > > > > > release only? More specifically, ensure that Python 3.6-only code
> > > > doesn't
> > > > > > accidentally gets merged into a 1.5.X patch release.
> > > > > > 
> > > > > > thanks,
> > > > > > 
> > > > > > Lieven
> > > > > 
> > > > > Hi Lieven,
> > > > > 
> > > > > thanks. I believe the Python version compatibility falls under the
> > > > > semantic versioning umbrella of things not to break within any 1.x
> > > > > release. Thus above suggestion would be with respect to a 2.x
> > release or
> > > > > experimental / preview / new features added to 1.x, without affecting
>

Re: [Discuss] MXNet Python 3.6 Support Deprecation

2019-11-06 Thread Pedro Larroy 
In Numpy they are considering dropping 3.5 support for 1.18 or 1.19.

P.

On Tue, Nov 5, 2019 at 11:15 PM Xingjian SHI  wrote:

> I don’t think we should drop Python 3.5 now because Ubuntu 16.04 ships
> with that version. I suggest that we should revisit it next year.
>
> Best,
> Xingjian
> 
> From: Sheng Zha 
> Sent: Tuesday, August 27, 2019 10:49 AM
> To: d...@mxnet.apache.org
> Subject: Re: [Discuss] MXNet Python  3.6 Support Deprecation
>
> Good summary. At the start the discussion thread my ask is to announce the
> intention of py2 deprecation in the next release, and then actually
> deprecate py2 in the next major release. Thus, the appropriate timing for
> dropping py2 support in CI should be the start of the next major release.
> The py35 vs py36 discussion will not affect the outcome of py2 deprecation.
>
> BTW, one alternative option to a formal voting in the Apache way is to
> through lazy consensus [1], which could apply more in our project. Given
> the positive feedback in this discussion thread, I will assume lazy
> consensus in 72hrs on py2 deprecation as defined above.
>
> [1] https://community.apache.org/committers/lazyConsensus.html
>
> On 2019/08/27 00:19:14, Marco de Abreu  wrote:
> > Pedro,
> >
> > thanks for already starting these efforts, but it might be too early for
> > that. Right now, this is a discussion thread where we try to gather
> > different opinions in order to lay a good base for a future voting
> thread.
> > In there, we would define the detailed timeline, versions etc. Until the
> > vote has passed, I'd say that it's too early to draw any conclusions. So
> > far, there are two open discussion points:
> >
> > 1. Which Python version to support. 3.5 vs 3.6 is currently in the
> > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest
> > market share being 3.6 as of now.
> > 2. When to do the deprecation. EOY to match with official Python 2
> > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the
> > next major release (2.0) to adhere to semantic versioning.
> >
> > Once these points (and any future ones) have been properly discussed and
> > the community came to an agreement, we can formalize it with a voting
> > thread. Until then, I'd recommend to refrain from any actions or
> > user-facing communication regarding this topic.
> >
> > Best regards,
> > Marco
> >
> > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> > wrote:
> >
> > > I have sent a PR that removes Python2 from CI. But was closed. I
> thought
> > > everyone was +1 on this one. This would remove quite a bit of load on
> CI:
> > >
> > > https://github.com/apache/incubator-mxnet/pull/15990
> > >
> > > If it's not the right time to do this, what steps do we need to take?
> > >
> > > Pedro.
> > >
> > >
> > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen 
> wrote:
> > >
> > > > Lieven Govaerts  writes:
> > > > > Hi,
> > > > >
> > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen 
> > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have
> been a
> > > > >> few +1 after Chaitanya's reply to Pedro. I would like to check if
> > > these
> > > > >> only refer to Chaitanya's mail about a dedicated "improvement"
> effort
> > > or
> > > > >> about dropping 3.5.
> > > > >>
> > > > >> Thus two questions:
> > > > >>
> > > > >> 1) Are there any concerns about dropping Python 3.5? Now is your
> > > chance
> > > > to
> > > > >> speak up if you think so.
> > > > >>
> > > > >>
> > > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are
> > > > supported
> > > > > for 5 years, so for 16.04 LTS it ends in 1.5 years.
> > > > >
> > > > > I'm not saying you should wait for 1.5 more years, people can
> upgrade
> > > to
> > > > > 18.04 LTS after all, but may I suggest you make this switch in a
> major
> > > > > release only? More specifically, ensure that Python 3.6-only code
> > > doesn't
> > > > > accidentally gets merged into a 1.5.X patch release.
> > > > >
> > > > > thanks,
> > > > >
> > > > > Lieven
> > > >
> > > > Hi Lieven,
> > > >
> > > > thanks. I believe the Python version compatibility falls under the
> > > > semantic versioning umbrella of things not to break within any 1.x
> > > > release. Thus above suggestion would be with respect to a 2.x
> release or
> > > > experimental / preview / new features added to 1.x, without affecting
> > > > existing 1.x features. It would not affect 1.5.x patch releases.
> > > >
> > > > Best regards,
> > > > Leonard
> > > >
> > > >
> > > > >> 2) Should new MXNet 1.x (experimental?) functionality (for example
> > > numpy
> > > > >> compatible interface) only target the Python versions to be
> supported
> > > in
> > > > >> MXNet 2? The current plan is to make many MXNet 2 features
> available
> > > as
> > > > >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet
> 1 for
> > > > >> these

Re: BytePS-MXNet Integration

2019-11-06 Thread Yimin Jiang 
Hi Zhennan,

Thanks for your interest. To be honest, our team currently do not have a
plan for CPU training. That said, the notion of BytePS is not GPU-specific
and should also apply to CPU. I do not see a fundamental challenge yet. And
we welcome contributions on this.

Thank you,
Yimin

On Wed, Nov 6, 2019 at 2:59 PM Qin, Zhennan  wrote:

> Hi Yimin,
>
> Welcome to make contribution to MXNet project!
>
> From 
> https://github.com/bytedance/byteps/blob/master/README.md I found another
> limitation that isn't shown in your proposal:
>
> BytePS does not support pure CPU training for now. One reason is that the
> cheap PS assumption<
> https://github.com/bytedance/byteps/blob/master/docs/rationale.md> of
> BytePS do not hold for CPU training. Consequently, you need CUDA and NCCL
> to build and run BytePS.
>
> I have a couple of question for this: How's the status of CPU training
> support? If CPU training isn't supported yet, what's the challenge to
> support it? Do you have a plan to support it?
>
> Thanks,
> Zhennan
>
> On Wed, 2019-11-06 at 12:14 +0800, Yimin Jiang wrote:
>
> Hi MXNet Community,
>
>
> BytePS (https://github.com/bytedance/byteps) is a high-performance,
>
> cross-framework architecture for distributed training. BytePS developers
>
> are planning to integrate a part of BytePS into MXNet. The link below is
>
> the proposal. Feedbacks are welcome.
>
>
> https://cwiki.apache.org/confluence/display/MXNET/BytePS-MXNet+Integration
>
>
>
> Thank you,
>
> Yimin Jiang
>
>

Re: BytePS-MXNet Integration

2019-11-06 Thread Marco de Abreu 
Great proposal, really looking forward to it!

Qin, Zhennan  schrieb am Mi., 6. Nov. 2019, 07:59:

> Hi Yimin,
>
> Welcome to make contribution to MXNet project!
>
> From 
> https://github.com/bytedance/byteps/blob/master/README.md I found another
> limitation that isn't shown in your proposal:
>
> BytePS does not support pure CPU training for now. One reason is that the
> cheap PS assumption<
> https://github.com/bytedance/byteps/blob/master/docs/rationale.md> of
> BytePS do not hold for CPU training. Consequently, you need CUDA and NCCL
> to build and run BytePS.
>
> I have a couple of question for this: How's the status of CPU training
> support? If CPU training isn't supported yet, what's the challenge to
> support it? Do you have a plan to support it?
>
> Thanks,
> Zhennan
>
> On Wed, 2019-11-06 at 12:14 +0800, Yimin Jiang wrote:
>
> Hi MXNet Community,
>
>
> BytePS (https://github.com/bytedance/byteps) is a high-performance,
>
> cross-framework architecture for distributed training. BytePS developers
>
> are planning to integrate a part of BytePS into MXNet. The link below is
>
> the proposal. Feedbacks are welcome.
>
>
> https://cwiki.apache.org/confluence/display/MXNET/BytePS-MXNet+Integration
>
>
>
> Thank you,
>
> Yimin Jiang
>
>