Re: [Proposal] MXNet operator benchmark library

[Marco de Abreu]

Great proposal!

sandeep krishnamurthy  schrieb am Di., 14. Mai
2019, 04:45:

> Hi Naveen,
>
> Thanks for your feedback and suggestions. I have updated the document
> addressing the feedback and concerns, alternate solutions pros/cons are
> added.
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Operator+Benchmarks
>
> Best,
> Sandeep
>
> On Mon, May 13, 2019 at 1:20 PM Naveen Swamy  wrote:
>
> > Sandeep,
> >
> > Thanks for initiating work on individual operator performance. However I
> > find the proposed approach(ie., a separate libary/framework) to
> unnecessary
> > and increases maintenance overhead for the project.
> > Also, have you considered alternate approaches to achieve the same goal.?
> >
> > Many of the requirements/motivations you have mentioned typically should
> be
> > covered in unit-tests(different data-types/ different dimensions), so
> > instead of having to rewrite for all operators measuring performance,
> > consider writing a @timeit routine(using Python decorators) which can be
> > called on individual unit tests.  Also even if you call the performance
> > script from Python, typically you want to measure as close to the kernel
> as
> > possible and avoid any other variables.
> >
> > I left some comments on the doc itself.
> >
> > Happy to discuss further.
> >
> > -Naveen
> >
> >
> > On Mon, Apr 29, 2019 at 1:57 PM sandeep krishnamurthy <
> > sandeep.krishn...@gmail.com> wrote:
> >
> > > Hello Community,
> > >
> > > I am currently working on building a utility/library to help us easily
> do
> > > individual operator benchmarking in MXNet. I have documented the
> proposal
> > > in
> > > this cwiki
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Operator+Benchmarks
> > > >,
> > > and staging the current development in this github repository
> > > .
> > Proposal
> > > is to get this library under incubator-mxnet/benchmark/
> > > .
> > Please
> > > do review and provide your feedback and suggestions.
> > >
> > > Thanks to fellow MXNet community members - Lin, Sam, Rohit for
> providing
> > > initial ideas and suggestion.
> > >
> > > Best,
> > > Sandeep
> > >
> > >
> > >
> > >
> > > --
> > > Sandeep Krishnamurthy
> > >
> >
>
>
> --
> Sandeep Krishnamurthy
>

Re: [Proposal] MXNet operator benchmark library

[sandeep krishnamurthy]

Hi Naveen,

Thanks for your feedback and suggestions. I have updated the document
addressing the feedback and concerns, alternate solutions pros/cons are
added.
https://cwiki.apache.org/confluence/display/MXNET/MXNet+Operator+Benchmarks

Best,
Sandeep

On Mon, May 13, 2019 at 1:20 PM Naveen Swamy  wrote:

> Sandeep,
>
> Thanks for initiating work on individual operator performance. However I
> find the proposed approach(ie., a separate libary/framework) to unnecessary
> and increases maintenance overhead for the project.
> Also, have you considered alternate approaches to achieve the same goal.?
>
> Many of the requirements/motivations you have mentioned typically should be
> covered in unit-tests(different data-types/ different dimensions), so
> instead of having to rewrite for all operators measuring performance,
> consider writing a @timeit routine(using Python decorators) which can be
> called on individual unit tests.  Also even if you call the performance
> script from Python, typically you want to measure as close to the kernel as
> possible and avoid any other variables.
>
> I left some comments on the doc itself.
>
> Happy to discuss further.
>
> -Naveen
>
>
> On Mon, Apr 29, 2019 at 1:57 PM sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
> > Hello Community,
> >
> > I am currently working on building a utility/library to help us easily do
> > individual operator benchmarking in MXNet. I have documented the proposal
> > in
> > this cwiki
> > <
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Operator+Benchmarks
> > >,
> > and staging the current development in this github repository
> > .
> Proposal
> > is to get this library under incubator-mxnet/benchmark/
> > .
> Please
> > do review and provide your feedback and suggestions.
> >
> > Thanks to fellow MXNet community members - Lin, Sam, Rohit for providing
> > initial ideas and suggestion.
> >
> > Best,
> > Sandeep
> >
> >
> >
> >
> > --
> > Sandeep Krishnamurthy
> >
>


-- 
Sandeep Krishnamurthy

Re: [Announcement] New Committer - Zach Kimberg

[Pedro Larroy]

Congratulations

On Thu, May 9, 2019 at 11:29 AM Chaitanya Bapat  wrote:
>
> Congratulations Zachary! Way to go!
>
> On Thu, 9 May 2019 at 14:01, Carin Meier  wrote:
>
> > Congrats!
> >
> > On Thu, May 9, 2019 at 1:41 PM Per da Silva  wrote:
> >
> > > Nice one! Congratulations =)
> > >
> > > On Thu, May 9, 2019 at 7:38 PM Jake Lee  wrote:
> > >
> > > > Congrat!
> > > >
> > > > On Thu, May 9, 2019 at 10:37 AM Yuan Tang 
> > > wrote:
> > > >
> > > > > Welcome!
> > > > >
> > > > > On Thu, May 9, 2019 at 1:36 PM Marco de Abreu <
> > marco.g.ab...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Welcome!
> > > > > >
> > > > > > Hagay Lupesko  schrieb am Do., 9. Mai 2019,
> > > 19:33:
> > > > > >
> > > > > > > Congratulations Zach - well deserved!
> > > > > > >
> > > > > > > On Thu, May 9, 2019, 13:26 Qing Lan  wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > Please join me in welcoming Zach Kimberg (
> > > > https://github.com/zachgk)
> > > > > > as
> > > > > > > a
> > > > > > > > new committer.
> > > > > > > >
> > > > > > > > He has been solving some important bugs in MXNet JVM with
> > respect
> > > > to
> > > > > > > usage
> > > > > > > > improvement, build issues and a lot more. He also created the
> > > > Jenkins
> > > > > > > based
> > > > > > > > publish pipeline for us to have standard way to build and test
> > > > > > > > static-linked package conveniently for everyone in the
> > community.
> > > > > > > Moreover,
> > > > > > > > he solved a bunch of License problems we have in MXNet and
> > > brought
> > > > > > > several
> > > > > > > > fixes to let us get 1.4.0 release on time.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Qing
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> *Chaitanya Prakash Bapat*
> *+1 (973) 953-6299*
>
> [image: https://www.linkedin.com//in/chaibapat25]
> [image: https://www.facebook.com/chaibapat]
> [image:
> https://twitter.com/ChaiBapchya] [image:
> https://www.linkedin.com//in/chaibapat25]
> 

Re: Python2 End of Life

[Jake Lee]

+1 Recently I upgraded the Numpy version and found out that Pylint had
false alarm on it. The Pylint fix is only available on Python3. So I
changed the default python version of 'make pylint' command to python3 (PR
haven't been merged). It's time to drop support for Python2.

On Mon, May 13, 2019 at 1:37 PM Junru Shao  wrote:

> +1
>
> On Mon, May 13, 2019 at 1:34 PM Aaron Markham 
> wrote:
>
> > +1 for the pledge and to start moving things to Python 3.
> > I think our installation instructions and tutorials can be updated to
> > default to Python3 and we should update Python2-only tutorials. I know
> > we have a handful of those, and when I spot them, I'll create an
> > issue.
> > I can also look at migrating the docs build to Python 3.
> > Should we add a new label for issues relating to migrating to Python3?
> > Cheers,
> > Aaron
> >
> > On Mon, May 13, 2019 at 12:04 PM Zach Kimberg  >
> > wrote:
> > >
> > > Right now, the official date for ending support for Python 2.7 (and all
> > of
> > > python2) is set to January 1 [1]. As part of it, a number of projects
> > have
> > > pledged to drop support for Python2 in or before 2020 including
> > Tensorflow,
> > > requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
> > > should also join in this pledge on python3statement.org [2] because it
> > > would help clean up our project and it would be difficult to continue
> > > supporting Python2 anyway when some of our dependencies are dropping
> > > support.
> > >
> > > As a concrete step, we should decide on a date to remove all usages of
> > > Python2 from our CI and consider that officially dropping support.
> > > Following that, we can expect PRs will end up breaking support for
> > Python2.
> > > I suggest just using the same date that Python is dropping support of
> > > January 1. We may also need to update some examples or scripts that
> were
> > > written only for python2 that are around the project. Any thoughts?
> > >
> > > Zach
> > >
> > >
> > > [1] - https://www.python.org/dev/peps/pep-0373/
> > > [2] - https://python3statement.org/
> >
>

Re: Python2 End of Life

[Yuan Tang]

+1

On Mon, May 13, 2019 at 4:37 PM Junru Shao  wrote:

> +1
>
> On Mon, May 13, 2019 at 1:34 PM Aaron Markham 
> wrote:
>
> > +1 for the pledge and to start moving things to Python 3.
> > I think our installation instructions and tutorials can be updated to
> > default to Python3 and we should update Python2-only tutorials. I know
> > we have a handful of those, and when I spot them, I'll create an
> > issue.
> > I can also look at migrating the docs build to Python 3.
> > Should we add a new label for issues relating to migrating to Python3?
> > Cheers,
> > Aaron
> >
> > On Mon, May 13, 2019 at 12:04 PM Zach Kimberg  >
> > wrote:
> > >
> > > Right now, the official date for ending support for Python 2.7 (and all
> > of
> > > python2) is set to January 1 [1]. As part of it, a number of projects
> > have
> > > pledged to drop support for Python2 in or before 2020 including
> > Tensorflow,
> > > requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
> > > should also join in this pledge on python3statement.org [2] because it
> > > would help clean up our project and it would be difficult to continue
> > > supporting Python2 anyway when some of our dependencies are dropping
> > > support.
> > >
> > > As a concrete step, we should decide on a date to remove all usages of
> > > Python2 from our CI and consider that officially dropping support.
> > > Following that, we can expect PRs will end up breaking support for
> > Python2.
> > > I suggest just using the same date that Python is dropping support of
> > > January 1. We may also need to update some examples or scripts that
> were
> > > written only for python2 that are around the project. Any thoughts?
> > >
> > > Zach
> > >
> > >
> > > [1] - https://www.python.org/dev/peps/pep-0373/
> > > [2] - https://python3statement.org/
> >
>

Re: Python2 End of Life

[Junru Shao]

+1

On Mon, May 13, 2019 at 1:34 PM Aaron Markham 
wrote:

> +1 for the pledge and to start moving things to Python 3.
> I think our installation instructions and tutorials can be updated to
> default to Python3 and we should update Python2-only tutorials. I know
> we have a handful of those, and when I spot them, I'll create an
> issue.
> I can also look at migrating the docs build to Python 3.
> Should we add a new label for issues relating to migrating to Python3?
> Cheers,
> Aaron
>
> On Mon, May 13, 2019 at 12:04 PM Zach Kimberg 
> wrote:
> >
> > Right now, the official date for ending support for Python 2.7 (and all
> of
> > python2) is set to January 1 [1]. As part of it, a number of projects
> have
> > pledged to drop support for Python2 in or before 2020 including
> Tensorflow,
> > requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
> > should also join in this pledge on python3statement.org [2] because it
> > would help clean up our project and it would be difficult to continue
> > supporting Python2 anyway when some of our dependencies are dropping
> > support.
> >
> > As a concrete step, we should decide on a date to remove all usages of
> > Python2 from our CI and consider that officially dropping support.
> > Following that, we can expect PRs will end up breaking support for
> Python2.
> > I suggest just using the same date that Python is dropping support of
> > January 1. We may also need to update some examples or scripts that were
> > written only for python2 that are around the project. Any thoughts?
> >
> > Zach
> >
> >
> > [1] - https://www.python.org/dev/peps/pep-0373/
> > [2] - https://python3statement.org/
>

Re: Python2 End of Life

[Aaron Markham]

+1 for the pledge and to start moving things to Python 3.
I think our installation instructions and tutorials can be updated to
default to Python3 and we should update Python2-only tutorials. I know
we have a handful of those, and when I spot them, I'll create an
issue.
I can also look at migrating the docs build to Python 3.
Should we add a new label for issues relating to migrating to Python3?
Cheers,
Aaron

On Mon, May 13, 2019 at 12:04 PM Zach Kimberg  wrote:
>
> Right now, the official date for ending support for Python 2.7 (and all of
> python2) is set to January 1 [1]. As part of it, a number of projects have
> pledged to drop support for Python2 in or before 2020 including Tensorflow,
> requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
> should also join in this pledge on python3statement.org [2] because it
> would help clean up our project and it would be difficult to continue
> supporting Python2 anyway when some of our dependencies are dropping
> support.
>
> As a concrete step, we should decide on a date to remove all usages of
> Python2 from our CI and consider that officially dropping support.
> Following that, we can expect PRs will end up breaking support for Python2.
> I suggest just using the same date that Python is dropping support of
> January 1. We may also need to update some examples or scripts that were
> written only for python2 that are around the project. Any thoughts?
>
> Zach
>
>
> [1] - https://www.python.org/dev/peps/pep-0373/
> [2] - https://python3statement.org/

Re: [Proposal] MXNet operator benchmark library

[Naveen Swamy]

Sandeep,

Thanks for initiating work on individual operator performance. However I
find the proposed approach(ie., a separate libary/framework) to unnecessary
and increases maintenance overhead for the project.
Also, have you considered alternate approaches to achieve the same goal.?

Many of the requirements/motivations you have mentioned typically should be
covered in unit-tests(different data-types/ different dimensions), so
instead of having to rewrite for all operators measuring performance,
consider writing a @timeit routine(using Python decorators) which can be
called on individual unit tests.  Also even if you call the performance
script from Python, typically you want to measure as close to the kernel as
possible and avoid any other variables.

I left some comments on the doc itself.

Happy to discuss further.

-Naveen


On Mon, Apr 29, 2019 at 1:57 PM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> Hello Community,
>
> I am currently working on building a utility/library to help us easily do
> individual operator benchmarking in MXNet. I have documented the proposal
> in
> this cwiki
> <
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Operator+Benchmarks
> >,
> and staging the current development in this github repository
> . Proposal
> is to get this library under incubator-mxnet/benchmark/
> . Please
> do review and provide your feedback and suggestions.
>
> Thanks to fellow MXNet community members - Lin, Sam, Rohit for providing
> initial ideas and suggestion.
>
> Best,
> Sandeep
>
>
>
>
> --
> Sandeep Krishnamurthy
>

Python2 End of Life

[Zach Kimberg]

Right now, the official date for ending support for Python 2.7 (and all of
python2) is set to January 1 [1]. As part of it, a number of projects have
pledged to drop support for Python2 in or before 2020 including Tensorflow,
requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
should also join in this pledge on python3statement.org [2] because it
would help clean up our project and it would be difficult to continue
supporting Python2 anyway when some of our dependencies are dropping
support.

As a concrete step, we should decide on a date to remove all usages of
Python2 from our CI and consider that officially dropping support.
Following that, we can expect PRs will end up breaking support for Python2.
I suggest just using the same date that Python is dropping support of
January 1. We may also need to update some examples or scripts that were
written only for python2 that are around the project. Any thoughts?

Zach


[1] - https://www.python.org/dev/peps/pep-0373/
[2] - https://python3statement.org/

Re: [RESULTS] [VOTE] Release Apache MXNet (incubating) version 1.4.1.rc0

[Sheng Zha]

Thanks to the help from mentors, our vote on general@incubator is set to pass.

I'm sharing the issues mentioned in the vote that need us to fix before next 
release:
- Standard way to run rat, see [1]
- cpp-package/example/get_data.sh and similar scripts should use canonical URL 
for the MNIST data and mention the license (P.S. [2] mentions CC BY-SA 3.0 but 
the original link [3] didn't mention license. we may need to clarify this first)

And thank all who contributed to this release and thanks to Junru who drove the 
release work.

-sz

[1] https://github.com/apache/incubator-mxnet/issues/14936
[2] http://www.pymvpa.org/datadb/mnist.html
[3] http://yann.lecun.com/exdb/mnist/

On 2019/05/09 16:55:06, Hen  wrote: 
> Noting that I am a belated +1 on the release.
> 
> I had one item regarding dataset licensing that I’d like to see improved
> for the next release, but I don’t believe it would have been a blocker.
> 
> Hen
> 
> On Sat, May 4, 2019 at 00:00 Junru Shao  wrote:
> 
> > Dear MXNet community,
> >
> > I'm happy to announce the results of the vote.
> >
> > This vote passes with 12 +1 votes (3 binding), no 0 votes, and 1 -1 vote.
> > +1 votes
> > * Sheng Zha / binding
> > * Qing Lan / binding
> > * Carin Meier / binding
> > * Aaron Markham
> > * Pedro Larroy
> > * Lai Wei
> > * Damien Stanton
> > * Kellen Sunderland
> > * Yuxi Hu
> > * Joshua Z. Zhang
> > * Philip Hyunsu Cho
> > * Aston Zhang
> >
> > 0 votes
> > * No votes
> >
> > -1 votes
> > * Anirudh Subramanian
> >
> > Vote thread can be found here [1]. The list of members can be found here
> > [2].
> >
> > I'll continue with the release process and the release announcement will
> > follow in the next few days.
> >
> > Best regards,
> > Junru Shao
> >
> > [1]
> >
> > https://lists.apache.org/thread.html/6c140f4c180c259dd1b7f4ecf36f2d083ed810cd68b37d7f635f5614@%3Cdev.mxnet.apache.org%3E
> > [2] http://incubator.apache.org/projects/mxnet.html
> >
>