Re: Cuda 10.2 Wheels

[Alfredo Luque]

Looks like it updated since I last posted. Thanks!

On February 6, 2020 at 3:20:34 PM, Pedro Larroy (
pedro.larroy.li...@gmail.com) wrote:

Hi Alfredo.

Isn't "mxnet_cu102mkl-1.6.0
<
https://repo.mxnet.io/dist/mxnet_cu102mkl-1.6.0-py2.py3-none-manylinux1_x86_64.whl>"

what you are looking for? I see it on the second link you posted.

Pedro

On Tue, Feb 4, 2020 at 3:29 PM Alfredo Luque
 wrote:

> Hi folks,
>
> Are there any blockers on releasing CUDA 10.2 compatible wheels? Based on
> this
> readme
> <
>
https://github.com/apache/incubator-mxnet/blob/master/tools/pip/doc/CU102_ADDITIONAL.md
> >
> the
> packages should be available on PyPi already but they don’t appear to
exist
> yet.
>
> On the other thread, someone posted this static page
>  that
has
> nightly builds hosted on S3 but it appears CUDA 10.2 wheels aren’t on
> there.
>
> —
> Alfredo Luque
> Software Engineer
> Machine Learning Infrastructure
> Airbnb
> San Francisco, CA
>

—
Alfredo Luque
Software Engineer
Machine Learning Infrastructure
Airbnb
San Francisco, CA

Re: Cuda 10.2 Wheels

[Pedro Larroy]

Hi Alfredo.

Isn't "mxnet_cu102mkl-1.6.0
"
what you are looking for? I see it on the second link you posted.

Pedro

On Tue, Feb 4, 2020 at 3:29 PM Alfredo Luque
 wrote:

> Hi folks,
>
> Are there any blockers on releasing CUDA 10.2 compatible wheels? Based on
> this
> readme
> <
> https://github.com/apache/incubator-mxnet/blob/master/tools/pip/doc/CU102_ADDITIONAL.md
> >
> the
> packages should be available on PyPi already but they don’t appear to exist
> yet.
>
> On the other thread, someone posted this static page
>  that has
> nightly builds hosted on S3 but it appears CUDA 10.2 wheels aren’t on
> there.
>
> —
> Alfredo Luque
> Software Engineer
> Machine Learning Infrastructure
> Airbnb
> San Francisco, CA
>

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

[Dick Carter]

+1 (binding)

I ran unittests successfully on 3 different GPU architectures on CUDA 10.2 :

Tesla P100-SXM2 (Pascal, arch = 60).
Tesla V100-SXM2 (Volta, arch = 70)
Tesla T4 (Turing, arch = 75)

Compilation was via ./tests/jenkins/run_test_ubuntu.sh modified with the 
additional lines:

echo "DEV=0" >> config.mk
echo "USE_MKLDNN=0" >> config.mk
echo "USE_LAPACK_PATH=/usr/lib/x86_64-linux-gnu" >> config.mk
echo "USE_BLAS=openblas" >> config.mk

Tests run were:

nosetests --verbose tests/python/unittest || exit 1
nosetests --verbose tests/python/gpu/ || exit 1
nosetests --verbose tests/python/train || exit 1

All tests on all 3 configurations passed.

-Dick

On 2020/02/05 19:24:35, "Lausen, Leonard"  wrote: 
> Hi Markus,
> 
> you point out a critical flaw of the current MXNet website. We don't have any
> versioning and the website is always built from master branch.
> 
> Thus while recent improvements to the build system are backwards compatible 
> (ie.
> old instructions continue to work), there is no way to find the old 
> instructions
> to build "old" releases.
> 
> https://github.com/apache/incubator-mxnet/issues/17497 tracks the issue.
> 
> Including the package build instructions with the source release makes sense.
> To make sure they don't get out of date, including the html pages built from 
> the
> source release is another option.
> 
> Best regards
> Leonard
> 
> On Wed, 2020-02-05 at 11:06 -0800, Markus Weimer wrote:
> > Hi,
> > 
> > I was trying to follow the build instructions[0] on Ubuntu 18.04.
> > However, I a stumped at step 2:
> > 
> > `cp config/config.cmake config.cmake`
> > 
> > The file `cmake.conf` does not seem to exist in the tarball on the
> > dist sit. `find . -name "cmake.conf" -print` finds nothing. In fact,
> > the `config` folder doesn't seem to exist in the tarball either.
> > However, the file and folder do exist on GitHub[1]. Are the build
> > instructions for a release different from the build from the
> > repository?
> > 
> > On a related note: It might make sense to package build instructions
> > with the source release. Websites get updated to reflect current use,
> > and it might be difficult for future users of this version of mxnet to
> > piece together the build instructions.
> > 
> > Thanks,
> > 
> > Markus
> > 
> > 
> > [0]: https://mxnet.apache.org/get_started/ubuntu_setup
> > [1]: https://github.com/apache/incubator-mxnet/tree/master/config
> > 
> > On Tue, Feb 4, 2020 at 3:05 PM Lausen, Leonard
> >  wrote:
> > > Using latest upstream jemalloc
> > > https://github.com/leezu/mxnet/commit/fd4c78a635087f6164344da53a55ba2b67da2fd2
> > > fixes the issue.
> > > 
> > > However, there were concerns that this commit relies on unreleased
> > > development
> > > features of jemalloc (jemalloc cmake build system support) and we'll not
> > > merge
> > > this commit until upstream releases cmake build system support in a 
> > > release.
> > > 
> > > In the meantime anyone is welcome to work on an equivalent patch based on
> > > the
> > > custom build system in latest stable jemalloc.
> > > 
> > > On Tue, 2020-02-04 at 22:46 +, Lausen, Leonard wrote:
> > > > Bisect identifies
> > > > https://github.com/apache/incubator-mxnet/commit/425319cb59904573bd3fe1b6fe0a7381eceb9bbd
> > > > 
> > > > Thus this is an issue with jemalloc + llvm libopemnp.
> > > > 
> > > > The correct reproducer for latest master branch is
> > > > 
> > > > 
> > > >   git clone --recursive https://github.com/apache/incubator-mxnet/ mxnet
> > > >   cd mxnet
> > > >   git checkout a726c406964b9cd17efa826738a662e09d973972 # workaround
> > > > https://github.com/apache/incubator-mxnet/issues/17514
> > > >   mkdir build; cd build;
> > > >   cmake -DUSE_CPP_PACKAGE=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
> > > > -DUSE_CUDA=OFF -DUSE_JEMALLOC=ON ..
> > > >   ninja
> > > >   ./cpp-package/example/test_regress_label  # run a 2-3 times to 
> > > > reproduce
> > > > 
> > > > Let's move the discussion to about fixing the jemalloc, openmp
> > > > incompatibility
> > > > to https://github.com/apache/incubator-mxnet/issues/17043
> > > > 
> > > > 
> > > > 
> > > > @Chris, could you look into this issue as it only happens with LLVM
> > > > OpenMP?
> > > > 
> > > > 
> > > > 
> > > > @Przemek: For 1.6.0 releas notes I suggest include recommendation to set
> > > > USE_JEMALLOC=OFF when compiling from source.
> > > > 
> > > > This note should probably be added in any case, as building with
> > > > USE_JEMALLOC=ON
> > > > is broken on Ubuntu Ubuntu 18.10 and higher, as well as Debian Stable.
> > > > 
> > > > Given these release notes, +1 for the release.
> > > > 
> > > > 
> > > > Best regards
> > > > Leonard
> > > > 
> > > > On Tue, 2020-02-04 at 22:26 +, Lausen, Leonard wrote:
> > > > > Actually below reproducer is wrong. The issue was apparently fixed on
> > > > > master
> > > > > recently. I'm running an automated bisect and will report the result
> > > > > later.
> > > > > 
> > > > > On Tue, 2020-02-04 at 21:44