RE: Stopping nightly releases to Pypi

[Zhao, Patric]

Agree, we should add the selection in the installation page for nightly build.

https://mxnet.apache.org/get_started?version=master=linux=python=pip=cpu#


> -Original Message-
> From: Haibin Lin 
> Sent: Tuesday, December 17, 2019 2:40 PM
> To: dev@mxnet.incubator.apache.org
> Cc: d...@mxnet.apache.org
> Subject: Re: Stopping nightly releases to Pypi
> 
> Shall we update the website installation page with nightly build information
> as well (after we figure out the CD details)?
> 
> Best,
> Haibin
> 
> On Tue, Dec 10, 2019 at 10:15 PM Lausen, Leonard
> 
> wrote:
> 
> > Not yet. As a community, we first need to add the nightly build
> > hosting feature to the community run CD and then we can add the page
> > so that the exact date doesn't need to be specified.
> >
> > I'm not sure what steps are required for this. Do we need to host the
> > artifacts on Apache's infrastructure? Or can we host the nightly CD
> > artifacts as part of the AWS sponsored community-maintained CD (S3
> > bucket associated to the account)?
> >
> > In the meantime, the "proprietary" AWS build solution could be
> > extended to publish an html page per artifact type (mxnet,
> > mxnet-cu100, ...) containing a link to all recent builds.
> >
> > Best regards
> > Leonard
> >
> > On Tue, 2019-12-10 at 22:03 -0800, Lin Yuan wrote:
> > > Is there a way to install the latest nightly package without having
> > > to specify exact date?
> > >
> > > Thanks,
> > >
> > > Lin
> > >
> > > On Sun, Dec 8, 2019 at 6:13 PM Lausen, Leonard
> > >  > >
> > > wrote:
> > >
> > > > From Shanghai, the closest endpoint (automatically chosen
> > > > endpoint) is
> > in
> > > > Tokyo
> > > > and download speed for mxnet-mkl was on average 1.7 MB/s with a
> > maximum of
> > > > 5
> > > > MB/s during my test.
> > > >
> > > > On Sun, 2019-12-08 at 01:30 +, Sheng Zha wrote:
> > > > > > Heres a set of links for today’s builds
> > > > > >
> > > > > > (Plain mxnet, no mkl no cuda)
> > > > > >
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > > > > (mxnet-mkl)
> > > > > >
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_mkl-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > > > > (mxnet-cuXXX)
> > > > > >
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu90-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu92-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu100-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu101-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > > > > (mxnet-cuXXXmkl)
> > > > > >
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu90mkl-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu92mkl-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu100mkl-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-
> 07/dist/m
> > xnet_cu101mkl-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> > > > > These links are not utilizing the s3 accelerate feature (i.e.
> > > > > not
> > backed
> > > > by
> > > > > cloudfront edges). Please use repo.mxnet.io instead. The updated
> > links
> > > > are:
> > > > > (Plain mxnet, no mkl no cuda)
> > > > >
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet-1.6.0b20191207-py2.py
> > 3-none-manylinux1_x86_64.whl
> > > > > (mxnet-mkl)
> > > > >
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_mkl-1.6.0b20191207-py
> > 2.py3-none-manylinux1_x86_64.whl
> > > > > (mxnet-cuXXX)
> > > > >
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_cu90-1.6.0b20191207-p
> > y2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_cu92-1.6.0b20191207-p
> > y2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_cu100-1.6.0b20191207-
> > py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_cu101-1.6.0b20191207-
> > py2.py3-none-manylinux1_x86_64.whl
> > > > > (mxnet-cuXXXmkl)
> > > > >
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_cu90mkl-1.6.0b2019120
> > 7-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > https://repo.mxnet.io/dist/2019-12-07/dist/mxnet_cu92mkl-1.6.0b2019120
> > 7-py2.py3-none-manylinux1_x86_64.whl
> > > >
> > 

Re: [apache/incubator-mxnet] [RFC] Custom Operator Part 2 (#17006)

[Pedro Larroy]

@wkcn could you explain your suggestion? calling gemm back into the framework 
which gets dispatched to GPU or CPU?

-- 
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/17006#issuecomment-569131388

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Pedro Larroy]

What's the point of having an API if you type erase it? Then you might as
well have a single function API with a type erased callback name to select
the function to call. In the end you move the burden away from the API to
the callers and inside the API to the dispatchers. For going this route of
uber-clever template tricks to generate code, I think it's better to just
put in place proper code generation for maintainability. Could you provide
a bit more details about tradeoffs? Everything has tradeoffs, I don't
believe any solution which is sold as a panacea, there's no silver bullet.

On Thu, Dec 19, 2019 at 10:21 AM Tianqi Chen 
wrote:

> I have another candidate that would highly recommend: adopt TVM's FFI
> convention.
>
> The historical problem of MXNet FFI was the blowing amount of the C API
> bindings as we add new features. This creates a huge amount of maintenance
> burden.
>
> The real problem was not really about which FFI system to adopt(cython and
> pybind are fine in that end, except for the cost of compilation), but more
> of the cost to maintain the FFI. MXNet used to have a fast cython binding,
> but that was abandoned because we keep add new APIs we cannot keep up both
> ctypes and cython.
>
> When developing TVM we learnt from the lesson and restrict the API to a
> limited set of runtime APIs that does not change, and have a stable cython,
> ctypes binding for them. The runtime support a type-erased
> function(PackedFunc), which can be efficiently called from any of the
> frontend language, and all the APIs are exposed through the PackedFunc. On
> the python side an additional wrapping is created for better documentation
> and call into the PackedFunc. See more in
> https://docs.tvm.ai/dev/runtime.html The system works great for over a
> few years now.
>
> Of course I understand there has been legacy issues in MXNet that is why I
> did not bring this proposal up. But given this is a proposal for 2.0, I
> would encourage everyone to give a serious thought about this possibility.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>


-- 
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/17097#issuecomment-569135511

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

[Pedro Larroy]

https://github.com/apache/incubator-mxnet/pull/17012  should be also ported
to the release branch.

On Fri, Dec 20, 2019 at 1:39 PM Przemysław Trędak 
wrote:

> That issue is now fixed in master, I am in the process of cherry-picking
> the fix to v1.6.x branch. I will prepare the RC1 once that is ready.
>
> Thanks
> Przemek
>
> On 2019/12/20 20:07:36, Lin Yuan  wrote:
> > What's the next step for the release? Should we continue testing this and
> > vote or wait until the
> > https://github.com/apache/incubator-mxnet/issues/17105 is fixed?
> >
> > Thanks!
> >
> > Lin
> >
> > On Wed, Dec 18, 2019 at 12:55 AM Lausen, Leonard
> 
> > wrote:
> >
> > > Thanks Przemysław for managing this release and everyone who
> contributed
> > > to it.
> > >
> > > Unfortunately Zechen Wang just discovered another issue with GPU
> Pointwise
> > > Fusion: https://github.com/apache/incubator-mxnet/issues/17105
> > >
> > > Thus, -1.
> > >
> > > Unfortunately, as the nightly release pipeline was broken until
> recently
> > > (and
> > > still isn't re-set up completely yet), the issue hasn't been discovered
> > > earlier.
> > >
> > > Przemysław may have a quick fix for the issue. Another option would be
> to
> > > release 1.6 with MXNET_USE_FUSION default to 0.
> > >
> > > Best regards
> > > Leonard
> > >
> > > On Wed, 2019-12-18 at 05:30 +, Chen, Ciyong wrote:
> > > > Appreciate Tredak to push out voting for 1.6 release.
> > > >
> > > > +1 as we've done lots of tests with expected performance in many
> > > different
> > > > scenarios including both single-node and multi-node (horovod based),
> > > both FP32
> > > > and INT8 precision on many topologies.
> > > >
> > > > -Ciyong
> > > >
> > > > -Original Message-
> > > > From: Zhao, Patric 
> > > > Sent: Tuesday, December 17, 2019 8:51 AM
> > > > To: dev@mxnet.incubator.apache.org; d...@mxnet.apache.org
> > > > Subject: RE: [VOTE] Release Apache MXNet (incubating) version
> 1.6.0.rc0
> > > >
> > > > Thanks, Tredak, I will add some words for the new feature in the
> release
> > > note.
> > > >
> > > > +1 for voting because we have ran multiple time of tests in local and
> > > got the
> > > > expected performance boost.
> > > >
> > > > --Patric
> > > >
> > > > > -Original Message-
> > > > > From: Przemysław Trędak 
> > > > > Sent: Tuesday, December 17, 2019 4:49 AM
> > > > > To: d...@mxnet.apache.org
> > > > > Subject: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0
> > > > >
> > > > > Dear MXNet community,
> > > > >
> > > > > This is the vote to release Apache MXNet (incubating) version
> 1.6.0.
> > > > > Voting starts now and will close on Friday, 20th December 2019
> > > 23:59:59 PST.
> > > > >
> > > > > Link to release notes:
> > > > >
> https://cwiki.apache.org/confluence/display/MXNET/1.6.0+Release+notes
> > > > >
> > > > > Link to release candidate:
> > > > > https://github.com/apache/incubator-mxnet/releases/tag/1.6.0.rc0
> > > > >
> > > > > Link to source and signatures on apache dist server:
> > > > > https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.6.0.rc0/
> > > > >
> > > > > Please remember to TEST first before voting accordingly:
> > > > > +1 = approve
> > > > > +0 = no opinion
> > > > > -1 = disapprove (provide reason)
> > > > >
> > > > > Additional notes:
> > > > >  - There was an issue[1] raised that 1.6.0.rc0 does not build with
> > > > > clang on FreeBSD - I decided to not block the voting for this and
> > > > > instead let the Community decide whether this is a blocker for the
> > > release.
> > > > >  - Patric Zhao and Tao Lv - could you help preparing a paragraph on
> > > > > MKLDNN
> > > > > 1.0 update in the New features section in the release notes?
> > > > >
> > > > > [1] https://github.com/apache/incubator-mxnet/issues/17076
> > > > >
> > > > > Best regards,
> > > > > Przemyslaw Tredak
> > >
> >
>

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Pedro Larroy]

Pybind is nice, I used Boost python many years ago, which I think is based
on. The problem with this is the hourglass C bindings, you have to go from
Python to C++ / Pybind, down to C and to the engine, this seems like a lot
of boilerplate.

On Mon, Dec 16, 2019 at 10:02 PM reminisce  wrote:

> MXNet imperative operator invocation overhead is as large as 30-60us,
> which is significant compared to the official NumPy operators with ~600ns
> overhead. This has negatively impacted the performance of applying MXNet to
> the models where many operators' kernel runtime duration is short,
> especially in the area of classic machine learning. We plan to address the
> problem in two steps:
>
>1.
>
>Short term: Use pybind11 to replace Python op API and ctypes/c api.
>Preliminary experiments show that the pure Python-C++ turnaround time by
>using Pybind is between 400-600ns, while the current Python op API using
>ctypes/c api costs more than 10us. We believe with the correct
>implementation, we can reduce the op invocation overhead to 2us including
>the time on FFI and engine.
>2.
>
>Long term: Adopt Python's C extension interface. NumPy did this by
>developing its own C API. This provides considerably less overhead compared
>to other solutions. However, it would cost much more engineering efforts by
>integrating this with our existing operator workflow in C++.
>
> @hzfan  @hgt312 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>


-- 
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/17097#issuecomment-569135990

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

@larroy indeed every solution has trade-offs, and these tradeoffs are discussed 
in the above posts when we compare solutions, and they are backed by benchmarks 
:) it would be great if you can also suggest potential tradeoffs here.

When you expose an API from typed language(c++) to a dynamic language(python), 
you have to type erase it, given that the python functions don't have the type, 
and you have to pass the information along.  

The only difference is where you do the type checking(that the python type 
corresponds to the right c++ type), and translation(translating to the c++ 
type).

For example, in the case of pybind, the erasure is done implicitly when you 
call the python function, then checking and translation happens when you call 
into the c++ function.

In the case of creating a C API for each feature and wrap things in the python 
side, the type checking is done in the python side, and translation as well.

In the case of tvm ffi, the type translation is done in the python/cython side, 
 while the type checking is done in the c++. 

To dive deeper into the tradeoffs for PackedFunc calling convention. The 
convention erases the type by having the type code stored into the arguments. 
This brings additional cost of passing arguments into heap, as opposed to 
registers. So they might not be designed for inline functions that needs to 
happen at the order of 1e-9s, however, for API functions that needs to run 
around 1e-7 or even 1e-8 level, this convention is pretty good.

In terms of the calling cost, it really depends on whether the caller and 
callee are strongly typed.
- If caller is strongly typed, then assigning type code is O(1)
- If caller is a dynamic type(like python) then we need to have a dispatcher to 
dispatch and select the right type code
- If callee is strongly typed, then the cost of checking is O(1) by just check 
the code to be the correct one 
- If the callee is dynamic type, then a dispatching need to happen, which have 
another level of hashtable lookup O(1)

As we can see, the only place where dispatching is necessary is the dynamic 
type handling case. Even in these cases, if there is a strong need of 
specialization, we can directly force the type by running checking on the 
caller, and pass in the right type code (the engineering burden is the same as 
wrapping the C API). However, the benchmark suggests that the dynamic 
dispatching cost is reasonable, and satisfies the API speed.

Coming back to the tradeoff, the main tradeoff here is the engineering burden 
to keep an hourglass design(with fixed set of API) vs efficiency. While my post 
did not suggest that TVM's ffi is a silver bullet, it does works pretty well 
for our use cases. hope it helps


-- 
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/17097#issuecomment-569139957

Re: [apache/incubator-mxnet] [RFC] Apache MXNet 2.0 Roadmap (#16167)

[Xingjian Shi]

Should we create a new branch for 2.0? I think we are also planing for 1.7.0 
https://github.com/apache/incubator-mxnet/issues/16864

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/16167#issuecomment-569139977