[incubator-mxnet] branch master updated: [MXNET-531] Integration Test for Scala (#11596)
This is an automated email from the ASF dual-hosted git repository.
nswamy pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git
The following commit(s) were added to refs/heads/master by this push:
new b786ead [MXNET-531] Integration Test for Scala (#11596)
b786ead is described below
commit b786ead562590300519a3f0725dafe7d40325edd
Author: Lanking
AuthorDate: Wed Jul 11 22:19:09 2018 -0700
[MXNET-531] Integration Test for Scala (#11596)
* Separate unit test and integration tests for Scala
---
Jenkinsfile| 24 +++---
Makefile | 10 +++--
ci/docker/runtime_functions.sh | 14 ++---
scala-package/README.md| 5 +++--
scala-package/core/pom.xml | 14 +
scala-package/examples/pom.xml | 13
.../imclassification/MNISTExampleSuite.scala | 8 +---
scala-package/infer/pom.xml| 13
scala-package/macros/pom.xml | 13
9 files changed, 84 insertions(+), 30 deletions(-)
diff --git a/Jenkinsfile b/Jenkinsfile
index 4ee1d98..c78a88e 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -712,18 +712,6 @@ try {
}
}
},
-'Scala: GPU': {
- node('mxnetlinux-gpu') {
-ws('workspace/ut-scala-gpu') {
- timeout(time: max_time, unit: 'MINUTES') {
-init_git()
-unpack_lib('gpu', mx_dist_lib)
-docker_run('ubuntu_gpu', 'unittest_ubuntu_gpu_scala', true)
-publish_test_coverage()
- }
-}
- }
-},
'Clojure: CPU': {
node('mxnetlinux-cpu') {
ws('workspace/ut-clojure-cpu') {
@@ -979,6 +967,18 @@ try {
}
}
}
+},
+'Scala: GPU': {
+ node('mxnetlinux-gpu') {
+ws('workspace/ut-scala-gpu') {
+ timeout(time: max_time, unit: 'MINUTES') {
+init_git()
+unpack_lib('gpu', mx_dist_lib)
+docker_run('ubuntu_gpu', 'integrationtest_ubuntu_gpu_scala', true)
+publish_test_coverage()
+ }
+}
+ }
}
// Disable until fixed
https://github.com/apache/incubator-mxnet/issues/11441
// 'dist-kvstore tests GPU': {
diff --git a/Makefile b/Makefile
index 2cf1ed1..5816637 100644
--- a/Makefile
+++ b/Makefile
@@ -593,9 +593,15 @@ scalapkg:
-Dcurrent_libdir="$(ROOTDIR)/lib" \
-Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a")
-scalatest:
+scalaunittest:
(cd $(ROOTDIR)/scala-package; \
- mvn verify -P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE)
-Dcxx="$(CXX)" \
+ mvn integration-test
-P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE),unittest -Dcxx="$(CXX)" \
+ -Dcflags="$(CFLAGS)" -Dldflags="$(LDFLAGS)" \
+ -Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a"
$(SCALA_TEST_ARGS))
+
+scalaintegrationtest:
+ (cd $(ROOTDIR)/scala-package; \
+ mvn integration-test
-P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE),integrationtest -Dcxx="$(CXX)" \
-Dcflags="$(CFLAGS)" -Dldflags="$(LDFLAGS)" \
-Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a"
$(SCALA_TEST_ARGS))
diff --git a/ci/docker/runtime_functions.sh b/ci/docker/runtime_functions.sh
index 4f0b146..3c19616 100755
--- a/ci/docker/runtime_functions.sh
+++ b/ci/docker/runtime_functions.sh
@@ -638,13 +638,7 @@ unittest_ubuntu_python3_quantization_gpu() {
unittest_ubuntu_cpu_scala() {
set -ex
make scalapkg USE_BLAS=openblas USE_DIST_KVSTORE=1
-make scalatest USE_BLAS=openblas USE_DIST_KVSTORE=1
-}
-
-unittest_ubuntu_gpu_scala() {
-set -ex
-make scalapkg USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 USE_DIST_KVSTORE=1 SCALA_ON_GPU=1
-make scalatest USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 SCALA_TEST_ON_GPU=1 USE_DIST_KVSTORE=1
+make scalaunittest USE_BLAS=openblas USE_DIST_KVSTORE=1
}
unittest_ubuntu_cpu_clojure() {
@@ -724,6 +718,12 @@ integrationtest_ubuntu_gpu_cpp_package() {
cpp-package/tests/ci_test.sh
}
+integrationtest_ubuntu_gpu_scala() {
+set -ex
+make scalapkg USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 USE_DIST_KVSTORE=1 SCALA_ON_GPU=1
+make scalaintegrationtest USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 SCALA_TEST_ON_GPU=1 USE_DIST_KVSTORE=1
+}
+
integrationtest_ubuntu_gpu_dist_kvstore() {
set -ex
export PYTHONPATH=./python/
diff --git a/scala-package/README.md b/scala-package/README.md
index 785bb39..79caaf3 100644
--- a/scala-package/README.md
+++
[GitHub] nswamy closed pull request #11596: [MXNET-531] Integration Test for Scala
nswamy closed pull request #11596: [MXNET-531] Integration Test for Scala
URL: https://github.com/apache/incubator-mxnet/pull/11596
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/Jenkinsfile b/Jenkinsfile
index 4ee1d982fed..c78a88e3b76 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -712,18 +712,6 @@ try {
}
}
},
-'Scala: GPU': {
- node('mxnetlinux-gpu') {
-ws('workspace/ut-scala-gpu') {
- timeout(time: max_time, unit: 'MINUTES') {
-init_git()
-unpack_lib('gpu', mx_dist_lib)
-docker_run('ubuntu_gpu', 'unittest_ubuntu_gpu_scala', true)
-publish_test_coverage()
- }
-}
- }
-},
'Clojure: CPU': {
node('mxnetlinux-cpu') {
ws('workspace/ut-clojure-cpu') {
@@ -979,6 +967,18 @@ try {
}
}
}
+},
+'Scala: GPU': {
+ node('mxnetlinux-gpu') {
+ws('workspace/ut-scala-gpu') {
+ timeout(time: max_time, unit: 'MINUTES') {
+init_git()
+unpack_lib('gpu', mx_dist_lib)
+docker_run('ubuntu_gpu', 'integrationtest_ubuntu_gpu_scala', true)
+publish_test_coverage()
+ }
+}
+ }
}
// Disable until fixed
https://github.com/apache/incubator-mxnet/issues/11441
// 'dist-kvstore tests GPU': {
diff --git a/Makefile b/Makefile
index 2cf1ed1ece2..5816637f989 100644
--- a/Makefile
+++ b/Makefile
@@ -593,9 +593,15 @@ scalapkg:
-Dcurrent_libdir="$(ROOTDIR)/lib" \
-Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a")
-scalatest:
+scalaunittest:
(cd $(ROOTDIR)/scala-package; \
- mvn verify -P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE)
-Dcxx="$(CXX)" \
+ mvn integration-test
-P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE),unittest -Dcxx="$(CXX)" \
+ -Dcflags="$(CFLAGS)" -Dldflags="$(LDFLAGS)" \
+ -Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a"
$(SCALA_TEST_ARGS))
+
+scalaintegrationtest:
+ (cd $(ROOTDIR)/scala-package; \
+ mvn integration-test
-P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE),integrationtest -Dcxx="$(CXX)" \
-Dcflags="$(CFLAGS)" -Dldflags="$(LDFLAGS)" \
-Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a"
$(SCALA_TEST_ARGS))
diff --git a/ci/docker/runtime_functions.sh b/ci/docker/runtime_functions.sh
index 4f0b1464742..3c196164d57 100755
--- a/ci/docker/runtime_functions.sh
+++ b/ci/docker/runtime_functions.sh
@@ -638,13 +638,7 @@ unittest_ubuntu_python3_quantization_gpu() {
unittest_ubuntu_cpu_scala() {
set -ex
make scalapkg USE_BLAS=openblas USE_DIST_KVSTORE=1
-make scalatest USE_BLAS=openblas USE_DIST_KVSTORE=1
-}
-
-unittest_ubuntu_gpu_scala() {
-set -ex
-make scalapkg USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 USE_DIST_KVSTORE=1 SCALA_ON_GPU=1
-make scalatest USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 SCALA_TEST_ON_GPU=1 USE_DIST_KVSTORE=1
+make scalaunittest USE_BLAS=openblas USE_DIST_KVSTORE=1
}
unittest_ubuntu_cpu_clojure() {
@@ -724,6 +718,12 @@ integrationtest_ubuntu_gpu_cpp_package() {
cpp-package/tests/ci_test.sh
}
+integrationtest_ubuntu_gpu_scala() {
+set -ex
+make scalapkg USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 USE_DIST_KVSTORE=1 SCALA_ON_GPU=1
+make scalaintegrationtest USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 SCALA_TEST_ON_GPU=1 USE_DIST_KVSTORE=1
+}
+
integrationtest_ubuntu_gpu_dist_kvstore() {
set -ex
export PYTHONPATH=./python/
diff --git a/scala-package/README.md b/scala-package/README.md
index 785bb39bd83..79caaf30915 100644
--- a/scala-package/README.md
+++ b/scala-package/README.md
@@ -55,13 +55,14 @@ make scalapkg
(Optional) run unit/integration tests by
```bash
-make scalatest
+make scalaunittest
+make scalaintegrationtest
```
Or run a subset of unit tests by, e.g.,
```bash
-make SCALA_TEST_ARGS=-Dsuites=org.apache.mxnet.NDArraySuite scalatest
+make SCALA_TEST_ARGS=-Dsuites=org.apache.mxnet.NDArraySuite scalaunittest
```
If everything goes well, you will find jars for `assembly`, `core` and
`example` modules.
diff --git a/scala-package/core/pom.xml b/scala-package/core/pom.xml
index 3b1b051f60b..631b6bd3810 100644
--- a/scala-package/core/pom.xml
+++ b/scala-package/core/pom.xml
@@ -14,6 +14,18 @@
MXNet Scala Package - Core
+
+ unittest
+
+false
+
+
+
+ integrationtest
+
+true
+
[GitHub] nswamy commented on issue #11596: [MXNET-531] Integration Test for Scala
nswamy commented on issue #11596: [MXNET-531] Integration Test for Scala URL: https://github.com/apache/incubator-mxnet/pull/11596#issuecomment-404392074 @lanking520 thanks for separating the tests into two phases, this definitely helps in speeding up the CI pipeline. @marcoabreu consider moving Scala Integration tests to the next stage, we don't need to run Unit Tests and Integration tests in parallel This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet] branch master updated: [MXNET-627] Fix Installation instructions for R bindings on Linux systems. (#11590)
This is an automated email from the ASF dual-hosted git repository. zhasheng pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git The following commit(s) were added to refs/heads/master by this push: new ea24c1c [MXNET-627] Fix Installation instructions for R bindings on Linux systems. (#11590) ea24c1c is described below commit ea24c1c6d53c1fb67e2872e7adc4841edd5400b1 Author: Anirudh AuthorDate: Wed Jul 11 22:15:19 2018 -0700 [MXNET-627] Fix Installation instructions for R bindings on Linux systems. (#11590) * fix doc * fix * fix * fix * gpu * nit * new ubuntu and r install scripts and docs; minor osx update * script now uses requirements.txt * removed unneeded commands * fixed path for make rpkg --- ci/docker/install/ubuntu_r.sh | 28 +++-- docs/install/build_from_source.md | 1 - docs/install/index.md | 157 +--- docs/install/install_mxnet_ubuntu_python.sh | 74 + docs/install/install_mxnet_ubuntu_r.sh | 55 ++ docs/install/osx_setup.md | 9 +- docs/install/requirements.txt | 8 ++ docs/install/ubuntu_setup.md| 135 docs/install/windows_setup.md | 8 -- 9 files changed, 300 insertions(+), 175 deletions(-) diff --git a/ci/docker/install/ubuntu_r.sh b/ci/docker/install/ubuntu_r.sh index 05e3e7c..097a651 100755 --- a/ci/docker/install/ubuntu_r.sh +++ b/ci/docker/install/ubuntu_r.sh @@ -20,17 +20,31 @@ # build and install are separated so changes to build don't invalidate # the whole docker cache for the image +# Important Maintenance Instructions: +# Align changes with installation instructions in /docs/install/ubuntu_setup.md +# Align with R install script: /docs/install/install_mxnet_ubuntu_r.sh + set -ex cd "$(dirname "$0")" # install libraries for mxnet's r package on ubuntu echo "deb http://cran.rstudio.com/bin/linux/ubuntu trusty/" >> /etc/apt/sources.list -#key=E084DAB9 -#gpg --keyserver keyserver.ubuntu.com --recv-key $key || \ -#gpg --keyserver keyserver.pgp.com --recv-keys $key || \ -#gpg --keyserver ha.pool.sks-keyservers.net --recv-keys $key ; -#gpg -a --export $key | apt-key add - -apt-key add r.gpg +key=E084DAB9 + +gpg --keyserver keyserver.ubuntu.com --recv-key $key || \ +gpg --keyserver keyserver.pgp.com --recv-keys $key || \ +gpg --keyserver ha.pool.sks-keyservers.net --recv-keys $key ; + +# Installing the latest version (3.3+) that is compatible with MXNet +add-apt-repository 'deb [arch=amd64,i386] https://cran.rstudio.com/bin/linux/ubuntu xenial/' + +gpg -a --export $key | apt-key add - apt-get update -apt-get install -y --allow-unauthenticated r-base r-base-dev libxml2-dev libssl-dev libxt-dev +apt-get install -y --allow-unauthenticated \ +libcairo2-dev \ +libssl-dev \ +libxml2-dev \ +libxt-dev \ +r-base \ +r-base-dev diff --git a/docs/install/build_from_source.md b/docs/install/build_from_source.md index 2505f00..b22ff88 100644 --- a/docs/install/build_from_source.md +++ b/docs/install/build_from_source.md @@ -394,7 +394,6 @@ Next, build and install the MXNet R package: ```bash cd .. make rpkg -R CMD INSTALL mxnet_current_r.tar.gz ``` ## Build the Scala package diff --git a/docs/install/index.md b/docs/install/index.md index ab99bbd..3ea4ea0 100644 --- a/docs/install/index.md +++ b/docs/install/index.md @@ -939,58 +939,13 @@ pip install graphviz - +The default version of R that is installed with `apt-get` is insufficient. You will need to first [install R v3.4.4+ and build MXNet from source](ubuntu_setup.html#install-the-mxnet-package-for-r). -Building *MXNet* from source is a 2 step process. -1. Build the *MXNet* core shared library, `libmxnet.so`, from the C++ sources. -2. Build the language specific bindings. - -**Minimum Requirements** -1. [GCC 4.8](https://gcc.gnu.org/gcc-4.8/) or later to compile C++ 11. -2. [GNU Make](https://www.gnu.org/software/make/) - - - -**Build the MXNet core shared library** - -**Step 1** Install build tools and git. -```bash -$ sudo apt-get update -$ sudo apt-get install -y build-essential git -``` - -**Step 2** Install OpenBLAS. - -*MXNet* uses [BLAS](https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms) and [LAPACK](https://en.wikipedia.org/wiki/LAPACK) libraries for accelerated numerical computations on CPU machine. There are several flavors of BLAS/LAPACK libraries - [OpenBLAS](http://www.openblas.net/), [ATLAS](http://math-atlas.sourceforge.net/) and [MKL](https://software.intel.com/en-us/intel-mkl). In this step we install OpenBLAS. You can choose to install ATLAS or MKL. -```bash -$ sudo apt-get install -y libopenblas-dev liblapack-dev -``` - -**Step 3** Install OpenCV. - -*MXNet* uses
[GitHub] nswamy commented on a change in pull request #11596: [MXNET-531] Integration Test for Scala
nswamy commented on a change in pull request #11596: [MXNET-531] Integration Test for Scala URL: https://github.com/apache/incubator-mxnet/pull/11596#discussion_r201911570 ## File path: Makefile ## @@ -593,7 +593,13 @@ scalapkg: -Dcurrent_libdir="$(ROOTDIR)/lib" \ -Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a") -scalatest: +scalaunittest: + (cd $(ROOTDIR)/scala-package; \ + mvn integration-test -P$(SCALA_PKG_PROFILE),$(SCALA_VERSION_PROFILE) -Dcxx="$(CXX)" \ + -Dcflags="$(CFLAGS)" -Dldflags="$(LDFLAGS)" \ + -Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a" $(SCALA_TEST_ARGS)) + +scalaintegrationtest: Review comment: I tried to centralize the two profiles in the main pom file instead of changing these properties in every module. The test plugins are spread in all the modules, After cleaning them and adding two profiles in the main pom configuration. The tests are now segfaulting, not sure what is causing. I will stop this effort here and we can see later. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] szha closed pull request #11590: [MXNET-627] Fix Installation instructions for R bindings on Linux systems.
szha closed pull request #11590: [MXNET-627] Fix Installation instructions for R bindings on Linux systems. URL: https://github.com/apache/incubator-mxnet/pull/11590 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/ci/docker/install/ubuntu_r.sh b/ci/docker/install/ubuntu_r.sh index 05e3e7cca07..097a651b2bf 100755 --- a/ci/docker/install/ubuntu_r.sh +++ b/ci/docker/install/ubuntu_r.sh @@ -20,17 +20,31 @@ # build and install are separated so changes to build don't invalidate # the whole docker cache for the image +# Important Maintenance Instructions: +# Align changes with installation instructions in /docs/install/ubuntu_setup.md +# Align with R install script: /docs/install/install_mxnet_ubuntu_r.sh + set -ex cd "$(dirname "$0")" # install libraries for mxnet's r package on ubuntu echo "deb http://cran.rstudio.com/bin/linux/ubuntu trusty/" >> /etc/apt/sources.list -#key=E084DAB9 -#gpg --keyserver keyserver.ubuntu.com --recv-key $key || \ -#gpg --keyserver keyserver.pgp.com --recv-keys $key || \ -#gpg --keyserver ha.pool.sks-keyservers.net --recv-keys $key ; -#gpg -a --export $key | apt-key add - -apt-key add r.gpg +key=E084DAB9 + +gpg --keyserver keyserver.ubuntu.com --recv-key $key || \ +gpg --keyserver keyserver.pgp.com --recv-keys $key || \ +gpg --keyserver ha.pool.sks-keyservers.net --recv-keys $key ; + +# Installing the latest version (3.3+) that is compatible with MXNet +add-apt-repository 'deb [arch=amd64,i386] https://cran.rstudio.com/bin/linux/ubuntu xenial/' + +gpg -a --export $key | apt-key add - apt-get update -apt-get install -y --allow-unauthenticated r-base r-base-dev libxml2-dev libssl-dev libxt-dev +apt-get install -y --allow-unauthenticated \ +libcairo2-dev \ +libssl-dev \ +libxml2-dev \ +libxt-dev \ +r-base \ +r-base-dev diff --git a/docs/install/build_from_source.md b/docs/install/build_from_source.md index 2505f00eb95..b22ff8833e9 100644 --- a/docs/install/build_from_source.md +++ b/docs/install/build_from_source.md @@ -394,7 +394,6 @@ Next, build and install the MXNet R package: ```bash cd .. make rpkg -R CMD INSTALL mxnet_current_r.tar.gz ``` ## Build the Scala package diff --git a/docs/install/index.md b/docs/install/index.md index ab99bbdd509..3ea4ea0ef4d 100644 --- a/docs/install/index.md +++ b/docs/install/index.md @@ -939,58 +939,13 @@ pip install graphviz - +The default version of R that is installed with `apt-get` is insufficient. You will need to first [install R v3.4.4+ and build MXNet from source](ubuntu_setup.html#install-the-mxnet-package-for-r). -Building *MXNet* from source is a 2 step process. -1. Build the *MXNet* core shared library, `libmxnet.so`, from the C++ sources. -2. Build the language specific bindings. - -**Minimum Requirements** -1. [GCC 4.8](https://gcc.gnu.org/gcc-4.8/) or later to compile C++ 11. -2. [GNU Make](https://www.gnu.org/software/make/) - - - -**Build the MXNet core shared library** - -**Step 1** Install build tools and git. -```bash -$ sudo apt-get update -$ sudo apt-get install -y build-essential git -``` - -**Step 2** Install OpenBLAS. - -*MXNet* uses [BLAS](https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms) and [LAPACK](https://en.wikipedia.org/wiki/LAPACK) libraries for accelerated numerical computations on CPU machine. There are several flavors of BLAS/LAPACK libraries - [OpenBLAS](http://www.openblas.net/), [ATLAS](http://math-atlas.sourceforge.net/) and [MKL](https://software.intel.com/en-us/intel-mkl). In this step we install OpenBLAS. You can choose to install ATLAS or MKL. -```bash -$ sudo apt-get install -y libopenblas-dev liblapack-dev -``` - -**Step 3** Install OpenCV. - -*MXNet* uses [OpenCV](http://opencv.org/) for efficient image loading and augmentation operations. -```bash -$ sudo apt-get install -y libopencv-dev -``` - -**Step 4** Download MXNet sources and build MXNet core shared library. You can clone the repository as described in the following code block, or you may try the download links for your desired MXNet version. +After you have setup R v3.4.4+ and MXNet, you can build and install the MXNet R bindings with the following, assuming that `incubator-mxnet` is the source directory you used to build MXNet as follows: ```bash -$ git clone --recursive https://github.com/apache/incubator-mxnet $ cd incubator-mxnet -$ make -j $(nproc) USE_OPENCV=1 USE_BLAS=openblas -``` - -*Note* - USE_OPENCV and USE_BLAS are make file flags to set compilation options to use OpenCV and BLAS library. You can explore and use more compilation options in `make/config.mk`. - - - -**Build and install the MXNet R binding** - - -```bash $ make rpkg -$ R CMD INSTALL mxnet_current_r.tar.gz ``` @@
[GitHub] lightingghost commented on issue #8513: --start-group not supported for macOS
lightingghost commented on issue #8513: --start-group not supported for macOS URL: https://github.com/apache/incubator-mxnet/issues/8513#issuecomment-404390873 @azai91 I have updated that PR. @tqchen @piiswrong, would you please take a look? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sergeykolychev commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples
sergeykolychev commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples URL: https://github.com/apache/incubator-mxnet/pull/11642#discussion_r201905284 ## File path: perl-package/AI-MXNet-Gluon-ModelZoo/examples/image_classification.pl ## @@ -0,0 +1,80 @@ +#!/usr/bin/env perl +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +use strict; +use warnings; +use AI::MXNet::Gluon::ModelZoo 'get_model'; +use AI::MXNet::Gluon::Utils 'download'; +use Getopt::Long qw(HelpMessage); + +GetOptions( +## my Pembroke Welsh Corgi Kyuubi, enjoing Solar eclipse of August 21, 2017 +'image=s' => \(my $image = 'https://scontent-sea1-1.cdninstagram.com/vp/'. Review comment: Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - greedily growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected from the growing subgraph. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the greedy subgraph growth with cycle checks after each node addition to the subgraph, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and of an incompatible pair, it's no longer a candidate for the TensorRT graph. The contradiction forces it into the incompatible class. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this PR takes Approach 2. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. Approach 2 works. We will add a unit test for this to show that it works for your scenario. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - greedily growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected from the growing subgraph. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the greedy subgraph growth with cycle checks after each node addition to the subgraph, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. The contradiction forces it into the incompatible class. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this PR takes Approach 2. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. Approach 2 works. We will add a unit test for this to show that it works for your scenario. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected from the growing subgraph. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. The contradiction forces it into the incompatible class. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this PR takes Approach 2. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. Approach 2 works. We will add a unit test for this to show that it works for your scenario. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] szha commented on a change in pull request #11657: documentation enhancement for optimizers
szha commented on a change in pull request #11657: documentation enhancement for optimizers URL: https://github.com/apache/incubator-mxnet/pull/11657#discussion_r201902109 ## File path: docs/tutorials/sparse/row_sparse.md ## @@ -531,8 +534,9 @@ sgd.update(0, weight, grad, momentum) -Note that both [mxnet.optimizer.SGD](https://mxnet.incubator.apache.org/api/python/optimization/optimization.html#mxnet.optimizer.SGD) -and [mxnet.optimizer.Adam](https://mxnet.incubator.apache.org/api/python/optimization/optimization.html#mxnet.optimizer.Adam) support sparse updates in MXNet. +Note that only [mxnet.optimizer.SGD](https://mxnet.incubator.apache.org/api/python/optimization/optimization.html#mxnet.optimizer.SGD) +and [mxnet.optimizer.Adam](https://mxnet.incubator.apache.org/api/python/optimization/optimization.html#mxnet.optimizer.Adam) and +[mxnet.optimizer.AdaGrad](https://mxnet.incubator.apache.org/api/python/optimization/optimization.html#mxnet.optimizer.AdaGrad) support sparse updates in MXNet. Review comment: consider writing it as "a, b, and c" instead of "a and b and c" for three items This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet] branch master updated: [MXNET-670] shape_array and size_array operator is non-differentiable (#11661)
This is an automated email from the ASF dual-hosted git repository.
zhasheng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git
The following commit(s) were added to refs/heads/master by this push:
new d25fdb7 [MXNET-670] shape_array and size_array operator is
non-differentiable (#11661)
d25fdb7 is described below
commit d25fdb7068a66944b658ca8a8e913904d03d8e4e
Author: Jian Guo <13162287+ijk...@users.noreply.github.com>
AuthorDate: Wed Jul 11 20:44:00 2018 -0700
[MXNET-670] shape_array and size_array operator is non-differentiable
(#11661)
* zero gradient for size_array, shape_array
* add op test for shape, size
---
src/operator/tensor/elemwise_unary_op_basic.cc | 2 ++
tests/python/unittest/test_operator.py | 34 --
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/src/operator/tensor/elemwise_unary_op_basic.cc
b/src/operator/tensor/elemwise_unary_op_basic.cc
index 8e64a7f..929bc74 100644
--- a/src/operator/tensor/elemwise_unary_op_basic.cc
+++ b/src/operator/tensor/elemwise_unary_op_basic.cc
@@ -417,6 +417,7 @@ Example::
.set_num_inputs(1)
.set_num_outputs(1)
.set_attr("FCompute", ShapeComputeCPU)
+.set_attr("FGradient", MakeZeroGradNodes)
.set_attr("FInferShape",
[](const nnvm::NodeAttrs& attrs,
std::vector *in_attrs,
@@ -466,6 +467,7 @@ Example::
.set_num_inputs(1)
.set_num_outputs(1)
.set_attr("FCompute", SizeComputeCPU)
+.set_attr("FGradient", MakeZeroGradNodes)
.set_attr("FInferShape",
[](const nnvm::NodeAttrs& attrs,
std::vector *in_attrs,
diff --git a/tests/python/unittest/test_operator.py
b/tests/python/unittest/test_operator.py
index 6529601..44fffdd 100644
--- a/tests/python/unittest/test_operator.py
+++ b/tests/python/unittest/test_operator.py
@@ -828,19 +828,37 @@ def test_sigmoid():
def test_shape_array():
for i in range(1,6):
shape = rand_shape_nd(i)
-x = np.random.ranf(shape)
-y = mx.nd.shape_array(mx.nd.array(x))
-expected_y = np.shape(x)
-same(y.asnumpy(), expected_y)
+x = mx.sym.var('x')
+y = mx.sym.shape_array(x)
+xa = mx.nd.array(np.random.ranf(shape))
+xg = mx.nd.empty(xa.shape)
+ya = np.shape(xa)
+yg = mx.nd.ones(ya)
+exe = y.bind(ctx=default_context(), args={'x': xa},
+ args_grad={'x': xg})
+exe.forward(is_train=True)
+exe.backward([yg])
+yo = exe.outputs[0].asnumpy()
+same(yo, ya)
+assert_almost_equal(xg.asnumpy(), np.zeros_like(xg.asnumpy()))
@with_seed()
def test_size_array():
for i in range(1,6):
shape = rand_shape_nd(i)
-x = np.random.ranf(shape)
-y = mx.nd.size_array(mx.nd.array(x))
-expected_y = np.size(x)
-same(y.asnumpy(), expected_y)
+x = mx.sym.var('x')
+y = mx.sym.size_array(x)
+xa = mx.nd.array(np.random.ranf(shape))
+xg = mx.nd.empty(xa.shape)
+ya = np.size(xa)
+yg = mx.nd.ones(ya)
+exe = y.bind(ctx=default_context(), args={'x': xa},
+ args_grad={'x': xg})
+exe.forward(is_train=True)
+exe.backward([yg])
+yo = exe.outputs[0].asnumpy()
+same(yo, ya)
+assert_almost_equal(xg.asnumpy(), np.zeros_like(xg.asnumpy()))
@with_seed()
def test_hard_sigmoid():
[GitHub] szha closed pull request #11661: [MXNET-670] shape_array and size_array operator is non-differentiable
szha closed pull request #11661: [MXNET-670] shape_array and size_array
operator is non-differentiable
URL: https://github.com/apache/incubator-mxnet/pull/11661
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/operator/tensor/elemwise_unary_op_basic.cc
b/src/operator/tensor/elemwise_unary_op_basic.cc
index 8e64a7f6366..929bc7426d5 100644
--- a/src/operator/tensor/elemwise_unary_op_basic.cc
+++ b/src/operator/tensor/elemwise_unary_op_basic.cc
@@ -417,6 +417,7 @@ Example::
.set_num_inputs(1)
.set_num_outputs(1)
.set_attr("FCompute", ShapeComputeCPU)
+.set_attr("FGradient", MakeZeroGradNodes)
.set_attr("FInferShape",
[](const nnvm::NodeAttrs& attrs,
std::vector *in_attrs,
@@ -466,6 +467,7 @@ Example::
.set_num_inputs(1)
.set_num_outputs(1)
.set_attr("FCompute", SizeComputeCPU)
+.set_attr("FGradient", MakeZeroGradNodes)
.set_attr("FInferShape",
[](const nnvm::NodeAttrs& attrs,
std::vector *in_attrs,
diff --git a/tests/python/unittest/test_operator.py
b/tests/python/unittest/test_operator.py
index faaa45efdb1..2aa2fa4f11c 100644
--- a/tests/python/unittest/test_operator.py
+++ b/tests/python/unittest/test_operator.py
@@ -827,19 +827,37 @@ def fsigmoid(a):
def test_shape_array():
for i in range(1,6):
shape = rand_shape_nd(i)
-x = np.random.ranf(shape)
-y = mx.nd.shape_array(mx.nd.array(x))
-expected_y = np.shape(x)
-same(y.asnumpy(), expected_y)
+x = mx.sym.var('x')
+y = mx.sym.shape_array(x)
+xa = mx.nd.array(np.random.ranf(shape))
+xg = mx.nd.empty(xa.shape)
+ya = np.shape(xa)
+yg = mx.nd.ones(ya)
+exe = y.bind(ctx=default_context(), args={'x': xa},
+ args_grad={'x': xg})
+exe.forward(is_train=True)
+exe.backward([yg])
+yo = exe.outputs[0].asnumpy()
+same(yo, ya)
+assert_almost_equal(xg.asnumpy(), np.zeros_like(xg.asnumpy()))
@with_seed()
def test_size_array():
for i in range(1,6):
shape = rand_shape_nd(i)
-x = np.random.ranf(shape)
-y = mx.nd.size_array(mx.nd.array(x))
-expected_y = np.size(x)
-same(y.asnumpy(), expected_y)
+x = mx.sym.var('x')
+y = mx.sym.size_array(x)
+xa = mx.nd.array(np.random.ranf(shape))
+xg = mx.nd.empty(xa.shape)
+ya = np.size(xa)
+yg = mx.nd.ones(ya)
+exe = y.bind(ctx=default_context(), args={'x': xa},
+ args_grad={'x': xg})
+exe.forward(is_train=True)
+exe.backward([yg])
+yo = exe.outputs[0].asnumpy()
+same(yo, ya)
+assert_almost_equal(xg.asnumpy(), np.zeros_like(xg.asnumpy()))
@with_seed()
def test_hard_sigmoid():
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] reminisce commented on issue #11639: some big numbers can not be assigned correctly with ndarray, it is a big bug???
reminisce commented on issue #11639: some big numbers can not be assigned correctly with ndarray, it is a big bug??? URL: https://github.com/apache/incubator-mxnet/issues/11639#issuecomment-404378030 This is a problem of using `float32` by passing big integers to the backend from frontend. In this case, `1681` becomes `1.68e+07`. That's why `1` is missing. I think we can add a `int` field in the `_slice_assign_scalar` operator and use that to pass integers. @piiswrong What do you think? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] szha commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples
szha commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples URL: https://github.com/apache/incubator-mxnet/pull/11642#discussion_r201899941 ## File path: perl-package/AI-MXNet-Gluon-ModelZoo/examples/image_classification.pl ## @@ -0,0 +1,80 @@ +#!/usr/bin/env perl +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +use strict; +use warnings; +use AI::MXNet::Gluon::ModelZoo 'get_model'; +use AI::MXNet::Gluon::Utils 'download'; +use Getopt::Long qw(HelpMessage); + +GetOptions( +## my Pembroke Welsh Corgi Kyuubi, enjoing Solar eclipse of August 21, 2017 +'image=s' => \(my $image = 'https://scontent-sea1-1.cdninstagram.com/vp/'. Review comment: http://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/kyuubi_blacksquare.jpg http://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/kyuubi_mural.jpg http://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/kyuubi_dali.jpg http://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/kyuubi_starry.jpg This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] zheng-da commented on issue #11658: Optimize cached op static memory allocation
zheng-da commented on issue #11658: Optimize cached op static memory allocation URL: https://github.com/apache/incubator-mxnet/pull/11658#issuecomment-404375815 I think you should test on models with static memory alloc when mkldnn is enabled. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11658: Optimize cached op static memory allocation
zheng-da commented on a change in pull request #11658: Optimize cached op
static memory allocation
URL: https://github.com/apache/incubator-mxnet/pull/11658#discussion_r201897425
##
File path: include/mxnet/ndarray.h
##
@@ -513,6 +515,7 @@ class NDArray {
// We can't reuse memory in a view.
CHECK(!IsView());
NDArray ret = *this;
+ret.byte_offset_ = byte_offset_ + byte_offset;
Review comment:
this might be problematic. The way of testing if an array is a view uses
both `reuse_` and `byte_offset_`.
https://github.com/apache/incubator-mxnet/blob/master/include/mxnet/ndarray.h#L147
if `reuse_` is true, the array can't be a view. I wonder if setting
`byte_offset_` to non-zero can cause problems.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] sandeep-krishnamurthy closed issue #10006: How to visualise filters of MXNet model?
sandeep-krishnamurthy closed issue #10006: How to visualise filters of MXNet model? URL: https://github.com/apache/incubator-mxnet/issues/10006 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool test
zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool
test
URL: https://github.com/apache/incubator-mxnet/pull/11608#discussion_r201889199
##
File path: tests/cpp/operator/mkldnn.cc
##
@@ -1042,6 +1106,115 @@ void TestConcatOp(const OpAttrs , VerifyFunc
verify_fn,
}
}
+int CalculateWidthPoolOutput(int width, int kernel, int padding, int stride) {
+ return (width - kernel + 2 * padding) / stride + 1;
+}
+
+void TestPoolingOp(const OpAttrs _attrs, const OpAttrs
_attrs) {
+ std::vector inputs(forward_attrs.num_inputs);
+ std::vector outputs(forward_attrs.num_outputs);
+ std::vector ex_outputs(forward_attrs.num_outputs);
+
+ std::vector backwards_input(backwards_attrs.num_inputs);
+ std::vector backwards_outputs(backwards_attrs.num_outputs);
+ std::vector backwards_ex_outputs(backwards_attrs.num_outputs);
+
+
+ std::vector req(forward_attrs.num_outputs);
+ std::vector back_req(backwards_attrs.num_outputs);
+ std::vector dispatches = forward_attrs.dispatches;
+
+ TestArrayShapes tas = GetTestArrayShapes();
+ std::vector pds = tas.pds;
+
+ mxnet::op::PoolingParam param;
+ param.Init(forward_attrs.attrs.dict);
+ TShape kernel = param.kernel;
+ TShape padding = param.pad;
+ TShape stride = param.stride;
+
+ std::vector in_arrs = GetTestInputArrays();
+ std::vector> out_arrs(forward_attrs.num_outputs);
+ std::vector>
ex_out_arrs(forward_attrs.num_outputs);
+
+ for (int i1 = 0; i1 < in_arrs.size(); i1++) {
+auto in_arr = in_arrs[i1];
+
+// can only pool only 3D and 4D inputs
+TShape input_shape = in_arr.arr.shape();
+if (input_shape.ndim() != kernel.ndim() + 2)
+ continue;
+
+// skip if not default layout since memory layout must match
+if (in_arr.arr.IsMKLDNNData())
+ continue;
+
+std::vector scale_vector(in_arr.arr.shape().ndim());
+for (int i = 0; i < in_arr.arr.shape().ndim(); i++) {
+ if (i < 2)
+scale_vector[i] = 1;
+ else
+scale_vector[i] = CalculateWidthPoolOutput(
+input_shape[i], kernel[i-2], padding[i-2], stride[i-2]) /
+static_cast(input_shape[i]);
+}
+for (int i = 0; i < forward_attrs.num_outputs; i++) {
+ out_arrs[i] = GetTestOutputArrays(in_arr.arr.shape(), pds, scale_vector);
+ ex_out_arrs[i] = GetTestOutputArrays(in_arr.arr.shape(), pds,
scale_vector);
+}
+
+for (int i = 0; i < forward_attrs.num_inputs; i++)
+ inputs[i] = _arr.arr;
+
+for (size_t output_i = 0; output_i < out_arrs[0].size(); output_i++) {
+ for (int i = 0; i < forward_attrs.num_outputs; i++) {
+req[i] = kWriteTo;
+outputs[i] = _arrs[i][output_i].arr;
+ex_outputs[i] = _out_arrs[i][output_i].arr;
+ }
+ Imperative::Get()->set_is_training(true);
+
+ PrintVerifyMsg(in_arr, out_arrs[0][output_i]);
+ Imperative::Get()->InvokeOp(Context(), forward_attrs.attrs, inputs,
+ outputs, req, DispatchMode::kFCompute,
mxnet::OpStatePtr());
+ Imperative::Get()->InvokeOp(Context(), forward_attrs.attrs, inputs,
+ ex_outputs, req, DispatchMode::kFComputeEx,
mxnet::OpStatePtr());
+ Engine::Get()->WaitForAll();
+ VerifyCopyResult(outputs, ex_outputs);
+
+
+ // backwards test performed same time since output needed
+ if (backwards_attrs.num_inputs == 3) {
+backwards_input[0] = outputs[0]; // output grad
+backwards_input[1] = inputs[0]; // input
+backwards_input[2] = outputs[0]; // output
+ } else if (backwards_attrs.num_inputs == 5) {
+backwards_input[0] = outputs[0]; // output grad
+backwards_input[1] = outputs[0]; // workspace grad
+backwards_input[2] = inputs[0]; // input
+backwards_input[3] = outputs[0]; // output
+backwards_input[4] = ex_outputs[1]; // workspace
+ }
+
+ auto tmp_output = GetTestInputArrays(true)[i1];
+ auto tmp_output2 = GetTestInputArrays(true)[i1];
Review comment:
do you create a list of arrays, but only take one of them?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool test
zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool
test
URL: https://github.com/apache/incubator-mxnet/pull/11608#discussion_r201888472
##
File path: tests/cpp/operator/mkldnn.cc
##
@@ -515,33 +557,34 @@ void PrintVerifyMsg(const NDArrayAttrs , const
NDArrayAttrs ) {
*
* num_inputs / dim arguments used to scale shape (used for concat backwards
to enlarge input shapes)
*/
-std::vector GetTestInputArrays(bool rand = false, int num_inputs
= 1, int dim = 0) {
+std::vector GetTestInputArrays(bool rand = false,
+std::vector scale = {1}) {
Review comment:
can you update the comments on `scale`? previously, you only scale on one
dimension. why do you want to scale on multiple dimensions?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool test
zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool
test
URL: https://github.com/apache/incubator-mxnet/pull/11608#discussion_r201888769
##
File path: tests/cpp/operator/mkldnn.cc
##
@@ -1042,6 +1106,115 @@ void TestConcatOp(const OpAttrs , VerifyFunc
verify_fn,
}
}
+int CalculateWidthPoolOutput(int width, int kernel, int padding, int stride) {
+ return (width - kernel + 2 * padding) / stride + 1;
+}
+
+void TestPoolingOp(const OpAttrs _attrs, const OpAttrs
_attrs) {
+ std::vector inputs(forward_attrs.num_inputs);
+ std::vector outputs(forward_attrs.num_outputs);
+ std::vector ex_outputs(forward_attrs.num_outputs);
+
+ std::vector backwards_input(backwards_attrs.num_inputs);
+ std::vector backwards_outputs(backwards_attrs.num_outputs);
+ std::vector backwards_ex_outputs(backwards_attrs.num_outputs);
+
+
+ std::vector req(forward_attrs.num_outputs);
+ std::vector back_req(backwards_attrs.num_outputs);
+ std::vector dispatches = forward_attrs.dispatches;
+
+ TestArrayShapes tas = GetTestArrayShapes();
+ std::vector pds = tas.pds;
+
+ mxnet::op::PoolingParam param;
+ param.Init(forward_attrs.attrs.dict);
+ TShape kernel = param.kernel;
+ TShape padding = param.pad;
+ TShape stride = param.stride;
+
+ std::vector in_arrs = GetTestInputArrays();
+ std::vector> out_arrs(forward_attrs.num_outputs);
+ std::vector>
ex_out_arrs(forward_attrs.num_outputs);
+
+ for (int i1 = 0; i1 < in_arrs.size(); i1++) {
+auto in_arr = in_arrs[i1];
+
+// can only pool only 3D and 4D inputs
+TShape input_shape = in_arr.arr.shape();
+if (input_shape.ndim() != kernel.ndim() + 2)
+ continue;
+
+// skip if not default layout since memory layout must match
+if (in_arr.arr.IsMKLDNNData())
+ continue;
Review comment:
why do you skip mkldnn input arrays?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool test
zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool
test
URL: https://github.com/apache/incubator-mxnet/pull/11608#discussion_r201887521
##
File path: tests/cpp/operator/mkldnn.cc
##
@@ -485,6 +486,47 @@ OpAttrs GetConcatBackwardsOp(int num_args, int dim) {
return attrs;
}
+std::string CreateShapeString(int value, int dim) {
+ std::stringstream ss;
+ ss << "(";
+ for (int i = 0; i < dim; i++) {
+ss << value;
+if (i != dim - 1) ss << ",";
+ }
+ ss << ")";
+ return ss.str();
+}
+
+
+OpAttrs GetPoolingOp(int kernel, int dim, int stride, int pad) {
+ OpAttrs attrs;
+ attrs.attrs.op = Op::Get("Pooling");
+ attrs.num_inputs = 1;
+ attrs.num_outputs = dim == 2 ? 2 : 1;
+ TShape kernel_shape(dim);
+ attrs.attrs.dict.insert({"kernel" , CreateShapeString(kernel, dim)});
+ attrs.attrs.dict.insert({"stride" , CreateShapeString(stride, dim)});
+ attrs.attrs.dict.insert({"pad" , CreateShapeString(pad, dim)});
+ attrs.attrs.dict.insert({"pool_type" , "max"});
+ attrs.attrs.op->attr_parser();
+ return attrs;
+}
+
+OpAttrs GetPoolingBackwardsOp(int kernel, int dim, int stride, int pad) {
+ OpAttrs attrs;
+ attrs.attrs.op = Op::Get("_backward_Pooling");
+ attrs.num_inputs = dim == 2 ? 5 : 3;
+ attrs.num_outputs = 1;
+ TShape kernel_shape(dim);
Review comment:
this one isn't used
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool test
zheng-da commented on a change in pull request #11608: [MXNET-489] MKLDNN Pool
test
URL: https://github.com/apache/incubator-mxnet/pull/11608#discussion_r201887497
##
File path: tests/cpp/operator/mkldnn.cc
##
@@ -485,6 +486,47 @@ OpAttrs GetConcatBackwardsOp(int num_args, int dim) {
return attrs;
}
+std::string CreateShapeString(int value, int dim) {
+ std::stringstream ss;
+ ss << "(";
+ for (int i = 0; i < dim; i++) {
+ss << value;
+if (i != dim - 1) ss << ",";
+ }
+ ss << ")";
+ return ss.str();
+}
+
+
+OpAttrs GetPoolingOp(int kernel, int dim, int stride, int pad) {
+ OpAttrs attrs;
+ attrs.attrs.op = Op::Get("Pooling");
+ attrs.num_inputs = 1;
+ attrs.num_outputs = dim == 2 ? 2 : 1;
+ TShape kernel_shape(dim);
Review comment:
this one isn't used.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] sergeykolychev commented on issue #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples
sergeykolychev commented on issue #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples URL: https://github.com/apache/incubator-mxnet/pull/11642#issuecomment-404362282 @szha Thank you! I'll update the file with new uri. When you have time could you, please, upload the images from that facebook post as well ? I'll then change stock images with Kyuubi's images for the style transfer example cause they are quite a bit cutier :-) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201886287 ## File path: MKLDNN_README.md ## @@ -0,0 +1,287 @@ +# Build/Install MXNet with MKL-DNN + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +apt-get update && apt-get install -y build-essential git libopencv-dev curl gcc libopenblas-dev python python-pip python-dev python-opencv graphviz python-scipy python-sklearn +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git +cd incubator-mxnet +git submodule update --recursive --init +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(nproc) USE_OPENCV=1 USE_MKLDNN=1 USE_BLAS=mkl USE_INTEL_PATH=/opt/intel +``` + +If you don't have full MKL library installed, you can use OpenBLAS by setting `USE_BLAS=openblas`. + +MacOS + +### Prerequisites + +Install the dependencies, required for MXNet, with the following commands: + +- [Homebrew](https://brew.sh/) +- gcc (clang in macOS does not support OpenMP) +- OpenCV (for computer vision operations) + +``` +# Paste this command in Mac terminal to install Homebrew +/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + +# install dependency +brew update +brew install pkg-config +brew install graphviz +brew tap homebrew/core +brew install opencv +brew tap homebrew/versions +brew install gcc49 +brew link gcc49 +``` + +### Enable OpenMP for MacOS + +If you want to enable OpenMP for better performance, you should modify these two files: + +1. Makefile L138: + +``` +ifeq ($(USE_OPENMP), 1) +# ifneq ($(UNAME_S), Darwin) +CFLAGS += -fopenmp +# endif +endif +``` + +2. prepare_mkldnn.sh L96: + +``` +CC=gcc-4.9 CXX=g++-4.9 cmake $MKLDNN_ROOTDIR -DCMAKE_INSTALL_PREFIX=$MKLDNN_INSTALLDIR -B$MKLDNN_BUILDDIR -DARCH_OPT_FLAGS="-mtune=generic" -DWITH_TEST=OFF -DWITH_EXAMPLE=OFF >&2 +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(sysctl -n hw.ncpu) CC=gcc-4.9 CXX=g++-4.9 USE_OPENCV=0 USE_OPENMP=1 USE_MKLDNN=1 USE_BLAS=apple USE_PROFILER=1 +``` + +*Note: Temporarily disable OPENCV.* + +Windows + +We recommend to build and install MXNet yourself using [Microsoft Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/), or you can also try experimentally the latest [Microsoft Visual Studio 2017](https://www.visualstudio.com/downloads/). + +**Visual Studio 2015** + +To build and install MXNet yourself, you need the following dependencies. Install the required dependencies: + +1. If [Microsoft Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/) is not already installed, download and install it. You can download and install the free community edition. +2. Download and Install [CMake](https://cmake.org/) if it is not already installed. +3. Download and install [OpenCV](http://sourceforge.net/projects/opencvlibrary/files/opencv-win/3.0.0/opencv-3.0.0.exe/download). +4. Unzip the OpenCV package. +5. Set the environment variable ```OpenCV_DIR``` to point to the ```OpenCV build directory``` (```C:\opencv\build\x64\vc14``` for example). Also, you need to add the OpenCV bin directory (```C:\opencv\build\x64\vc14\bin``` for example) to the ``PATH`` variable. +6. If you have Intel Math Kernel Library (MKL) installed, set ```MKL_ROOT``` to point to ```MKL``` directory that contains the ```include``` and ```lib```. If you want to use MKL blas, you should set ```-DUSE_BLAS=mkl``` when cmake. Typically, you can find the directory in +```C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\mkl```. +7. If you don't have the Intel Math Kernel Library (MKL) installed, download and install [OpenBLAS](http://sourceforge.net/projects/openblas/files/v0.2.14/). Note that you should also download ```mingw64.dll.zip`` along with openBLAS and add them to PATH. +8. Set the environment variable ```OpenBLAS_HOME``` to point to the ```OpenBLAS``` directory that contains the ```include``` and ```lib``` directories. Typically, you can find the directory in ```C:\Program files (x86)\OpenBLAS\```. + +After you have installed all of the required dependencies, build the MXNet source code: + +1. Download the MXNet source code from [GitHub](https://github.com/apache/incubator-mxnet). Don't forget to pull the submodules: +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git +``` + +2. Copy file `3rdparty/mkldnn/config_template.vcxproj` to incubator-mxnet root. + +3. Start a Visual Studio command prompt. + +4. Use [CMake](https://cmake.org/) to create a Visual Studio solution in ```./build``` or some other directory. Make sure to specify the architecture in the +[CMake](https://cmake.org/) command: +``` +mkdir build +cd build +cmake -G
[GitHub] yzhliu commented on a change in pull request #11596: [MXNET-531] Integration Test for Scala
yzhliu commented on a change in pull request #11596: [MXNET-531] Integration Test for Scala URL: https://github.com/apache/incubator-mxnet/pull/11596#discussion_r201885838 ## File path: Makefile ## @@ -593,9 +593,15 @@ scalapkg: -Dcurrent_libdir="$(ROOTDIR)/lib" \ -Dlddeps="$(LIB_DEP) $(ROOTDIR)/lib/libmxnet.a") -scalatest: +scalaunittest: Review comment: I didn't notice. my bad.. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201884754 ## File path: MKLDNN_README.md ## @@ -0,0 +1,287 @@ +# Build/Install MXNet with MKL-DNN + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +apt-get update && apt-get install -y build-essential git libopencv-dev curl gcc libopenblas-dev python python-pip python-dev python-opencv graphviz python-scipy python-sklearn +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git +cd incubator-mxnet +git submodule update --recursive --init +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(nproc) USE_OPENCV=1 USE_MKLDNN=1 USE_BLAS=mkl USE_INTEL_PATH=/opt/intel +``` + +If you don't have full MKL library installed, you can use OpenBLAS by setting `USE_BLAS=openblas`. + +MacOS + +### Prerequisites + +Install the dependencies, required for MXNet, with the following commands: + +- [Homebrew](https://brew.sh/) +- gcc (clang in macOS does not support OpenMP) +- OpenCV (for computer vision operations) + +``` +# Paste this command in Mac terminal to install Homebrew +/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + +# install dependency +brew update +brew install pkg-config +brew install graphviz +brew tap homebrew/core +brew install opencv +brew tap homebrew/versions +brew install gcc49 +brew link gcc49 +``` + +### Enable OpenMP for MacOS + +If you want to enable OpenMP for better performance, you should modify these two files: + +1. Makefile L138: + +``` +ifeq ($(USE_OPENMP), 1) +# ifneq ($(UNAME_S), Darwin) +CFLAGS += -fopenmp +# endif +endif +``` + +2. prepare_mkldnn.sh L96: + +``` +CC=gcc-4.9 CXX=g++-4.9 cmake $MKLDNN_ROOTDIR -DCMAKE_INSTALL_PREFIX=$MKLDNN_INSTALLDIR -B$MKLDNN_BUILDDIR -DARCH_OPT_FLAGS="-mtune=generic" -DWITH_TEST=OFF -DWITH_EXAMPLE=OFF >&2 +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(sysctl -n hw.ncpu) CC=gcc-4.9 CXX=g++-4.9 USE_OPENCV=0 USE_OPENMP=1 USE_MKLDNN=1 USE_BLAS=apple USE_PROFILER=1 +``` + +*Note: Temporarily disable OPENCV.* + +Windows + +We recommend to build and install MXNet yourself using [Microsoft Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/), or you can also try experimentally the latest [Microsoft Visual Studio 2017](https://www.visualstudio.com/downloads/). + +**Visual Studio 2015** + +To build and install MXNet yourself, you need the following dependencies. Install the required dependencies: + +1. If [Microsoft Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/) is not already installed, download and install it. You can download and install the free community edition. +2. Download and Install [CMake](https://cmake.org/) if it is not already installed. Review comment: I'll add this. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201884744 ## File path: MKLDNN_README.md ## @@ -0,0 +1,287 @@ +# Build/Install MXNet with MKL-DNN + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +apt-get update && apt-get install -y build-essential git libopencv-dev curl gcc libopenblas-dev python python-pip python-dev python-opencv graphviz python-scipy python-sklearn +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git +cd incubator-mxnet +git submodule update --recursive --init +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(nproc) USE_OPENCV=1 USE_MKLDNN=1 USE_BLAS=mkl USE_INTEL_PATH=/opt/intel +``` + +If you don't have full MKL library installed, you can use OpenBLAS by setting `USE_BLAS=openblas`. + +MacOS + +### Prerequisites + +Install the dependencies, required for MXNet, with the following commands: + +- [Homebrew](https://brew.sh/) +- gcc (clang in macOS does not support OpenMP) +- OpenCV (for computer vision operations) + +``` +# Paste this command in Mac terminal to install Homebrew +/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + +# install dependency +brew update +brew install pkg-config +brew install graphviz +brew tap homebrew/core +brew install opencv +brew tap homebrew/versions +brew install gcc49 +brew link gcc49 +``` + +### Enable OpenMP for MacOS + +If you want to enable OpenMP for better performance, you should modify these two files: + +1. Makefile L138: + +``` +ifeq ($(USE_OPENMP), 1) +# ifneq ($(UNAME_S), Darwin) +CFLAGS += -fopenmp +# endif +endif +``` + +2. prepare_mkldnn.sh L96: + +``` +CC=gcc-4.9 CXX=g++-4.9 cmake $MKLDNN_ROOTDIR -DCMAKE_INSTALL_PREFIX=$MKLDNN_INSTALLDIR -B$MKLDNN_BUILDDIR -DARCH_OPT_FLAGS="-mtune=generic" -DWITH_TEST=OFF -DWITH_EXAMPLE=OFF >&2 +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(sysctl -n hw.ncpu) CC=gcc-4.9 CXX=g++-4.9 USE_OPENCV=0 USE_OPENMP=1 USE_MKLDNN=1 USE_BLAS=apple USE_PROFILER=1 +``` + +*Note: Temporarily disable OPENCV.* + +Windows + +We recommend to build and install MXNet yourself using [Microsoft Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/), or you can also try experimentally the latest [Microsoft Visual Studio 2017](https://www.visualstudio.com/downloads/). + +**Visual Studio 2015** + +To build and install MXNet yourself, you need the following dependencies. Install the required dependencies: + +1. If [Microsoft Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/) is not already installed, download and install it. You can download and install the free community edition. +2. Download and Install [CMake](https://cmake.org/) if it is not already installed. +3. Download and install [OpenCV](http://sourceforge.net/projects/opencvlibrary/files/opencv-win/3.0.0/opencv-3.0.0.exe/download). Review comment: I'll add this. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201884410 ## File path: MKLDNN_README.md ## @@ -0,0 +1,229 @@ +# Build/Install MXNet with MKL-DNN + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +apt-get update && apt-get install -y build-essential git libopencv-dev curl gcc libopenblas-dev python python-pip python-dev python-opencv graphviz python-scipy python-sklearn +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git +cd incubator-mxnet +git submodule update --recursive --init +``` + +### Build MXNet with MKL-DNN + +``` +make -j $(nproc) USE_OPENCV=1 USE_MKLDNN=1 USE_BLAS=mkl USE_INTEL_PATH=/opt/intel +``` + +If you don't have full MKL library installed, you can use OpenBLAS by setting `USE_BLAS=openblas`. + +MacOS + +### Prerequisites + +Install the dependencies, required for MXNet, with the following commands: + +- [Homebrew](https://brew.sh/) +- gcc (clang in macOS does not support OpenMP) +- OpenCV (for computer vision operations) + +``` +# Paste this command in Mac terminal to install Homebrew +/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + +# install dependency +brew update +brew install pkg-config +brew install graphviz +brew tap homebrew/core +brew install opencv +brew tap homebrew/versions +brew install gcc49 +brew link gcc49 +``` + +### Enable OpenMP for MacOS + +If you want to enable OpenMP for better performance, you should modify these two files: + +1. Makefile L138: + +``` +ifeq ($(USE_OPENMP), 1) +# ifneq ($(UNAME_S), Darwin) +CFLAGS += -fopenmp Review comment: Don't you see this means if your os is Darwin, you will not enable openmp even if you USE_OPENMP=1? If possible, i need check gcc version (whether apple clang or gnu-gcc) here. Any good suggestions? @szha @zheng-da This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] huangzhiyuan commented on issue #11611: MKLDNN Forward FullyConnected op cache
huangzhiyuan commented on issue #11611: MKLDNN Forward FullyConnected op cache URL: https://github.com/apache/incubator-mxnet/pull/11611#issuecomment-404358263 The PR is based on release v0.14 version. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201883931 ## File path: MKLDNN_README.md ## @@ -0,0 +1,302 @@ +# Build/Install MXNet with MKL-DNN + +Building MXNet with [Intel MKL-DNN](https://github.com/intel/mkl-dnn) will gain better performance when using Intel Xeon CPUs for training and inference. The improvement of performance can be seen in this [page](https://mxnet.incubator.apache.org/faq/perf.html#intel-cpu). Below are instructions for linux, MacOS and Windows platform. + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +sudo apt-get update +sudo apt-get install -y build-essential git +sudo apt-get install -y libopenblas-dev liblapack-dev +sudo apt-get install -y libopencv-dev +sudo apt-get install -y graphviz +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git Review comment: why pip? This is just a instruction for building with mkldnn or MKL blas from source. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201883671 ## File path: MKLDNN_README.md ## @@ -0,0 +1,302 @@ +# Build/Install MXNet with MKL-DNN + +Building MXNet with [Intel MKL-DNN](https://github.com/intel/mkl-dnn) will gain better performance when using Intel Xeon CPUs for training and inference. The improvement of performance can be seen in this [page](https://mxnet.incubator.apache.org/faq/perf.html#intel-cpu). Below are instructions for linux, MacOS and Windows platform. + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +sudo apt-get update +sudo apt-get install -y build-essential git +sudo apt-get install -y libopenblas-dev liblapack-dev +sudo apt-get install -y libopencv-dev +sudo apt-get install -y graphviz +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git Review comment: why pip? This is just a instruction for building with mkldnn or MKL blas from source. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] szha commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples
szha commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples URL: https://github.com/apache/incubator-mxnet/pull/11642#discussion_r201883928 ## File path: perl-package/AI-MXNet-Gluon-ModelZoo/examples/image_classification.pl ## @@ -0,0 +1,80 @@ +#!/usr/bin/env perl +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +use strict; +use warnings; +use AI::MXNet::Gluon::ModelZoo 'get_model'; +use AI::MXNet::Gluon::Utils 'download'; +use Getopt::Long qw(HelpMessage); + +GetOptions( +## my Pembroke Welsh Corgi Kyuubi, enjoing Solar eclipse of August 21, 2017 +'image=s' => \(my $image = 'https://scontent-sea1-1.cdninstagram.com/vp/'. Review comment: http://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/kyuubi.jpg This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction
xinyu-intel commented on a change in pull request #11049: Add linux and macos MKLDNN Building Instruction URL: https://github.com/apache/incubator-mxnet/pull/11049#discussion_r201883671 ## File path: MKLDNN_README.md ## @@ -0,0 +1,302 @@ +# Build/Install MXNet with MKL-DNN + +Building MXNet with [Intel MKL-DNN](https://github.com/intel/mkl-dnn) will gain better performance when using Intel Xeon CPUs for training and inference. The improvement of performance can be seen in this [page](https://mxnet.incubator.apache.org/faq/perf.html#intel-cpu). Below are instructions for linux, MacOS and Windows platform. + +Contents + +* [1. Linux](#1) +* [2. MacOS](#2) +* [3. Windows](#3) +* [4. Verify MXNet with python](#4) +* [5. Enable MKL BLAS](#5) + +Linux + +### Prerequisites + +``` +sudo apt-get update +sudo apt-get install -y build-essential git +sudo apt-get install -y libopenblas-dev liblapack-dev +sudo apt-get install -y libopencv-dev +sudo apt-get install -y graphviz +``` + +### Clone MXNet sources + +``` +git clone --recursive https://github.com/apache/incubator-mxnet.git Review comment: why pip? This is just a instruction for building with mkldnn or MKL blas from source. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] aaronmarkham commented on issue #11662: make docs - lein not found
aaronmarkham commented on issue #11662: make docs - lein not found URL: https://github.com/apache/incubator-mxnet/issues/11662#issuecomment-404357840 I'm going to wait until this PR is merged: https://github.com/apache/incubator-mxnet/pull/11590 Then I can use the installation script I made for the Ubuntu deps as a base rather than starting from scratch. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] aaronmarkham commented on issue #11562: [MXNET-244] Update RaspberryPI instructions
aaronmarkham commented on issue #11562: [MXNET-244] Update RaspberryPI instructions URL: https://github.com/apache/incubator-mxnet/pull/11562#issuecomment-404357602 Also, this is a recent issue for running `make docs`: https://github.com/apache/incubator-mxnet/issues/11662 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. The contradiction forces it into the incompatible class. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this PR takes Approach 2. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. Approach 2 works. We will add a unit test for this to show that it works for your scenario. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] aaronmarkham opened a new issue #11662: make docs - lein not found
aaronmarkham opened a new issue #11662: make docs - lein not found URL: https://github.com/apache/incubator-mxnet/issues/11662 Lein needs to be added to the docs build instructions. If you're stuck on this error, do this: ``` wget https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein chmod 775 lein sudo cp lein /usr/local/bin ``` Or some directory that is in your `$PATH`. Then re-run, and you should be good to go. I'll submit a PR to add this to the instructions. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ifeherva commented on a change in pull request #11643: Added the diag() operator
ifeherva commented on a change in pull request #11643: Added the diag() operator URL: https://github.com/apache/incubator-mxnet/pull/11643#discussion_r201881825 ## File path: tests/python/unittest/test_operator.py ## @@ -6977,6 +6977,109 @@ def test_roi_align_autograd(sampling_ratio=0): test_roi_align_value(2) test_roi_align_autograd() +@with_seed() +def test_diag(): + +# test 2d input +h = np.random.randint(2,9) +w = np.random.randint(2,9) +a_np = np.random.random((h, w)) +a = mx.nd.array(a_np) + +# k == 0 +r = mx.nd.diag(a) + +for i in range(r.shape[0]): +assert r[i] == a[i][i] Review comment: Incorporated the changes. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet-site] branch asf-site updated: Bump the publish timestamp.
This is an automated email from the ASF dual-hosted git repository. zhasheng pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/incubator-mxnet-site.git The following commit(s) were added to refs/heads/asf-site by this push: new a490d86 Bump the publish timestamp. a490d86 is described below commit a490d866447c829537999031e84ab0cc917e9ab4 Author: mxnet-ci AuthorDate: Thu Jul 12 00:47:21 2018 + Bump the publish timestamp. --- date.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/date.txt b/date.txt new file mode 100644 index 000..89a22a7 --- /dev/null +++ b/date.txt @@ -0,0 +1 @@ +Thu Jul 12 00:47:21 UTC 2018
[GitHub] sergeykolychev commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples
sergeykolychev commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples URL: https://github.com/apache/incubator-mxnet/pull/11642#discussion_r201880066 ## File path: perl-package/AI-MXNet-Gluon-ModelZoo/examples/image_classification.pl ## @@ -0,0 +1,80 @@ +#!/usr/bin/env perl +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +use strict; +use warnings; +use AI::MXNet::Gluon::ModelZoo 'get_model'; +use AI::MXNet::Gluon::Utils 'download'; +use Getopt::Long qw(HelpMessage); + +GetOptions( +## my Pembroke Welsh Corgi Kyuubi, enjoing Solar eclipse of August 21, 2017 +'image=s' => \(my $image = 'https://scontent-sea1-1.cdninstagram.com/vp/'. Review comment: @szha I am not sure. But I'll be glad if I can put this image on mxnet data server. Besides that I have a few blog posts that I want in future to have added as a tutorials for perl api http://blogs.perl.org/users/sergey_kolychev/, they do contain some images and data files that would be nice to have on mxnet data server as well. I'll be writing new blog post soon announcing ModelZoo for perl and I'll use images from https://www.facebook.com/sergey.kolychev.39/posts/10155737425303434. Can you help me with putting these images/data files to the server ? Or may be I can get a write access somehow so I'll not bother you with this ? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ijkguo commented on issue #11661: [MXNET-670] shape_array and size_array operator is non-differentiable
ijkguo commented on issue #11661: [MXNET-670] shape_array and size_array
operator is non-differentiable
URL: https://github.com/apache/incubator-mxnet/pull/11661#issuecomment-404352517
https://github.com/apache/incubator-mxnet/issues/10789 This issue discussed
generating array using a runtime shape information is impossible right now.
https://github.com/apache/incubator-mxnet/pull/10889 This pr added
shape_array and size_array to generate output of shape information.
Use case in training
```python
img = mx.sym.var('img')
box = mx.sym.var('box')
im_shape = mx.sym.shape_array(img)
box = mx.sym.maximum(box, im_shape)
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] ijkguo opened a new pull request #11661: [MXNET-670] shape_array and size_array operator is non-differentiable
ijkguo opened a new pull request #11661: [MXNET-670] shape_array and size_array operator is non-differentiable URL: https://github.com/apache/incubator-mxnet/pull/11661 ## Description ## mxnet.base.MXNetError: [00:21:26] src/pass/gradient.cc:192: Operator shape_array is non-differentiable because it didn't register FGradient attribute. shape_array and size_array are generating new array, similar to ones_like. To use them in training, zero gradient should be attached. ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes) - [ ] Changes are complete (i.e. I finished coding on this PR) - [ ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ ] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [ ] Feature1, tests, (and when applicable, API doc) - [ ] Feature2, tests, (and when applicable, API doc) ## Comments ## - If this change is a backward incompatible change, why must this change be made. - Interesting edge cases to note here This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] junrushao1994 commented on a change in pull request #11566: [MXNET-626] Add while_loop
junrushao1994 commented on a change in pull request #11566: [MXNET-626] Add
while_loop
URL: https://github.com/apache/incubator-mxnet/pull/11566#discussion_r201877733
##
File path: python/mxnet/ndarray/contrib.py
##
@@ -191,3 +191,128 @@ def check_input(inputs, in_type, msg):
if not_data_list and len(outputs) == 1:
outputs = outputs[0]
return (outputs, states)
+
+
+def while_loop(loop_vars, cond, func, max_iterations):
+"""Run a while loop with user-defined computation and loop condition.
+
+This operator simulates a while loop which iterately does customized
computation
+as long as the condition is satisfied.
+
+`loop_vars` is a list of NDArrays on which the computation uses.
+
+`cond` is a user-defined function as the loop condition.
+It consumes `loop_vars`, and produces a scalar MXNet NDArray,
+indicating the termination of the loop.
+The loop ends when `cond` returns false (zero).
+The `cond` is variadic, and its signature should be
+`cond(*loop_vars) => NDArray`.
+
+`func` is a user-defined function as the loop body.
+It also consumes `loop_vars`, and produces `step_output` and
`new_loop_vars` at each step.
+The number of elements, shape, dtype of each element in `step_output`
should be consistent.
+The `new_loop_vars` should be consistent with `loop_vars` on each step.
+The `func` is variadic, and its signature should be
+`func(*loop_vars) => (List[NDArray] step_output, List[NDArray]
new_loop_vars)`.
+
+`max_iterations` is a scalar that defines the maximum number of iterations
allowed.
+
+This function returns a list of NDArrays of length `|step_output| +
|loop_vars|`.
+The i-th element in the first `|step_output|` ones of the list represent
+the i-th `step_output` at all step, stacked along axis 0.
+The i-th element in the last `|loop_vars|` ones of the list
+represent the final state of each loop variable.
+
+Warning 1: when `cond` is never satisfied, we assume `step_output` is
empty.
+Warning 2: The output shape along axis 0 is currently `max_iteration`,
+which not consistent to the symbloic version.
+
+Parameters
+--
+loop_vars: list of NDArrays.
+The initial values of the loop variables.
+cond: a Python function.
+The loop condition.
+func: a Python function.
+The loop body.
+max_iteration: a python int.
+Maximum number of iterations.
+
+Returns
+---
+outputs: a tuple of two lists, which both contains 0, 1 or more NDArrays.
+The first list contains the stacked output from each step,
+The second list contains the final state.
+
+Examples
+
+>>> cond = lambda i, s: i <= 5
+>>> func = lambda i, s: ([i + s], [i + 1, s + i])
+>>> loop_vars = (mx.nd.array([0], dtype="int64"), mx.nd.array([1],
dtype="int64"))
+>>> outputs, states = mx.nd.contrib.while_loop(loop_vars, cond, func,
max_iterations=10)
+"""
+def _to_python_scalar(inputs, type_, name):
+"""Converts "inputs", possibly typed mxnet NDArray, a numpy ndarray,
other python types,
+to the given type
+"""
+if isinstance(inputs, ndarray.NDArray):
+inputs = inputs.asscalar()
+try:
+inputs = type_(inputs)
+except:
+raise ValueError("Cannot convert %s to python %s" % (name,
type_.__name__))
+return inputs
+
+def _to_ndarray_tuple(inputs, name):
+"""Converts "inputs", possibly a single mxnet NDArray, a list of mxnet
NDArray,
+a tuple of mxnet NDArray, into a tuple of NDArray
+"""
+if isinstance(inputs, list):
+inputs = tuple(inputs)
+if isinstance(inputs, ndarray.NDArray):
+inputs = (inputs, )
+if not isinstance(inputs, tuple):
+raise ValueError("%s must be an NDArray, or a tuple or list of
NDArrays" % (name, ))
+for item in inputs:
+if not isinstance(item, ndarray.NDArray):
+raise ValueError("%s must be an NDArray, or a tuple or list of
NDArrays" % (name, ))
+return inputs
+
+def _func_wrapper(loop_vars):
+"""This wrapper unifies
+ "func: loop_vars -> new_loop_vars"
+ and "func: loop_vars -> (step_output, new_loop_vars)"
+into "func: loop_vars -> (None or tuple of step_outputs, tuple of
new_loop_vars)
+"""
+step_output, new_loop_vars = func(*loop_vars)
+if step_output is None:
+step_output = []
+if new_loop_vars is None:
+new_loop_vars = []
+step_output = _to_ndarray_tuple(step_output, "step_output")
+new_loop_vars = _to_ndarray_tuple(new_loop_vars, "new_loop_vars")
+if len(loop_vars) != len(new_loop_vars):
+raise ValueError("The length of loop_vars should be consistent
during the loop")
+return
[GitHub] junrushao1994 commented on a change in pull request #11566: [MXNET-626] Add while_loop
junrushao1994 commented on a change in pull request #11566: [MXNET-626] Add
while_loop
URL: https://github.com/apache/incubator-mxnet/pull/11566#discussion_r201877733
##
File path: python/mxnet/ndarray/contrib.py
##
@@ -191,3 +191,128 @@ def check_input(inputs, in_type, msg):
if not_data_list and len(outputs) == 1:
outputs = outputs[0]
return (outputs, states)
+
+
+def while_loop(loop_vars, cond, func, max_iterations):
+"""Run a while loop with user-defined computation and loop condition.
+
+This operator simulates a while loop which iterately does customized
computation
+as long as the condition is satisfied.
+
+`loop_vars` is a list of NDArrays on which the computation uses.
+
+`cond` is a user-defined function as the loop condition.
+It consumes `loop_vars`, and produces a scalar MXNet NDArray,
+indicating the termination of the loop.
+The loop ends when `cond` returns false (zero).
+The `cond` is variadic, and its signature should be
+`cond(*loop_vars) => NDArray`.
+
+`func` is a user-defined function as the loop body.
+It also consumes `loop_vars`, and produces `step_output` and
`new_loop_vars` at each step.
+The number of elements, shape, dtype of each element in `step_output`
should be consistent.
+The `new_loop_vars` should be consistent with `loop_vars` on each step.
+The `func` is variadic, and its signature should be
+`func(*loop_vars) => (List[NDArray] step_output, List[NDArray]
new_loop_vars)`.
+
+`max_iterations` is a scalar that defines the maximum number of iterations
allowed.
+
+This function returns a list of NDArrays of length `|step_output| +
|loop_vars|`.
+The i-th element in the first `|step_output|` ones of the list represent
+the i-th `step_output` at all step, stacked along axis 0.
+The i-th element in the last `|loop_vars|` ones of the list
+represent the final state of each loop variable.
+
+Warning 1: when `cond` is never satisfied, we assume `step_output` is
empty.
+Warning 2: The output shape along axis 0 is currently `max_iteration`,
+which not consistent to the symbloic version.
+
+Parameters
+--
+loop_vars: list of NDArrays.
+The initial values of the loop variables.
+cond: a Python function.
+The loop condition.
+func: a Python function.
+The loop body.
+max_iteration: a python int.
+Maximum number of iterations.
+
+Returns
+---
+outputs: a tuple of two lists, which both contains 0, 1 or more NDArrays.
+The first list contains the stacked output from each step,
+The second list contains the final state.
+
+Examples
+
+>>> cond = lambda i, s: i <= 5
+>>> func = lambda i, s: ([i + s], [i + 1, s + i])
+>>> loop_vars = (mx.nd.array([0], dtype="int64"), mx.nd.array([1],
dtype="int64"))
+>>> outputs, states = mx.nd.contrib.while_loop(loop_vars, cond, func,
max_iterations=10)
+"""
+def _to_python_scalar(inputs, type_, name):
+"""Converts "inputs", possibly typed mxnet NDArray, a numpy ndarray,
other python types,
+to the given type
+"""
+if isinstance(inputs, ndarray.NDArray):
+inputs = inputs.asscalar()
+try:
+inputs = type_(inputs)
+except:
+raise ValueError("Cannot convert %s to python %s" % (name,
type_.__name__))
+return inputs
+
+def _to_ndarray_tuple(inputs, name):
+"""Converts "inputs", possibly a single mxnet NDArray, a list of mxnet
NDArray,
+a tuple of mxnet NDArray, into a tuple of NDArray
+"""
+if isinstance(inputs, list):
+inputs = tuple(inputs)
+if isinstance(inputs, ndarray.NDArray):
+inputs = (inputs, )
+if not isinstance(inputs, tuple):
+raise ValueError("%s must be an NDArray, or a tuple or list of
NDArrays" % (name, ))
+for item in inputs:
+if not isinstance(item, ndarray.NDArray):
+raise ValueError("%s must be an NDArray, or a tuple or list of
NDArrays" % (name, ))
+return inputs
+
+def _func_wrapper(loop_vars):
+"""This wrapper unifies
+ "func: loop_vars -> new_loop_vars"
+ and "func: loop_vars -> (step_output, new_loop_vars)"
+into "func: loop_vars -> (None or tuple of step_outputs, tuple of
new_loop_vars)
+"""
+step_output, new_loop_vars = func(*loop_vars)
+if step_output is None:
+step_output = []
+if new_loop_vars is None:
+new_loop_vars = []
+step_output = _to_ndarray_tuple(step_output, "step_output")
+new_loop_vars = _to_ndarray_tuple(new_loop_vars, "new_loop_vars")
+if len(loop_vars) != len(new_loop_vars):
+raise ValueError("The length of loop_vars should be consistent
during the loop")
+return
[incubator-mxnet] branch master updated: Fix InferStorage for sparse fallback in FullyConnected (#11498)
This is an automated email from the ASF dual-hosted git repository.
haibin pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git
The following commit(s) were added to refs/heads/master by this push:
new 7dbbe59 Fix InferStorage for sparse fallback in FullyConnected
(#11498)
7dbbe59 is described below
commit 7dbbe59009ffb294a6aa0fd95eca7329b6e8331a
Author: Hao Jin
AuthorDate: Wed Jul 11 17:18:38 2018 -0700
Fix InferStorage for sparse fallback in FullyConnected (#11498)
* fix inferstorage for sparse in FullyConnected
* test for the new infer storage
---
src/operator/nn/fully_connected-inl.h | 1 +
src/operator/nn/fully_connected.cc| 22 +-
tests/python/mkl/test_mkldnn.py | 22 +-
3 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/src/operator/nn/fully_connected-inl.h
b/src/operator/nn/fully_connected-inl.h
index 7eba2e2..2338f89 100644
--- a/src/operator/nn/fully_connected-inl.h
+++ b/src/operator/nn/fully_connected-inl.h
@@ -35,6 +35,7 @@
#include "../operator_common.h"
#include "../elemwise_op_common.h"
#include "../linalg.h"
+#include "../../common/utils.h"
namespace mxnet {
namespace op {
diff --git a/src/operator/nn/fully_connected.cc
b/src/operator/nn/fully_connected.cc
index ed950c0..d9099cb 100644
--- a/src/operator/nn/fully_connected.cc
+++ b/src/operator/nn/fully_connected.cc
@@ -209,17 +209,21 @@ inline static bool BackwardFCStorageType(const
nnvm::NodeAttrs& attrs,
CHECK_EQ(in_attrs->size(), 3U);
CHECK_EQ(out_attrs->size(), out_expected);
- DispatchMode wanted_mode;
-#if 0
+ bool dispatched = false;
// TODO(zhengda) let's disable MKLDNN for FullyConnected for now.
// It seems there is a bug.
- if (dev_mask == mshadow::cpu::kDevMask)
-*dispatch_mode = DispatchMode::kFComputeEx;
- else
-#endif
-wanted_mode = DispatchMode::kFCompute;
- return storage_type_assign(out_attrs, mxnet::kDefaultStorage,
- dispatch_mode, wanted_mode);
+ if (!dispatched && common::ContainsOnlyStorage(*in_attrs,
mxnet::kDefaultStorage)) {
+storage_type_assign(out_attrs, mxnet::kDefaultStorage,
+dispatch_mode, DispatchMode::kFCompute);
+ }
+ if (!dispatched && common::ContainsStorageType(*in_attrs,
mxnet::kRowSparseStorage)) {
+dispatched = dispatch_fallback(out_attrs, dispatch_mode);
+ }
+ if (!dispatched) {
+dispatched = storage_type_assign(out_attrs, mxnet::kDefaultStorage,
+ dispatch_mode, DispatchMode::kFCompute);
+ }
+ return dispatched;
}
DMLC_REGISTER_PARAMETER(FullyConnectedParam);
diff --git a/tests/python/mkl/test_mkldnn.py b/tests/python/mkl/test_mkldnn.py
index 8c296de..a6d7743 100644
--- a/tests/python/mkl/test_mkldnn.py
+++ b/tests/python/mkl/test_mkldnn.py
@@ -22,7 +22,7 @@ import sys
import os
import numpy as np
import mxnet as mx
-from mxnet.test_utils import assert_almost_equal
+from mxnet.test_utils import rand_ndarray, assert_almost_equal
from mxnet import gluon
from mxnet.gluon import nn
from mxnet.test_utils import *
@@ -240,5 +240,25 @@ def test_batchnorm():
for stype in stypes:
check_batchnorm_training(stype)
+
+@with_seed()
+def test_fullyconnected():
+def check_fullyconnected_training(stype):
+data_shape = rand_shape_nd(2)
+weight_shape = rand_shape_nd(2)
+weight_shape = (weight_shape[0], data_shape[1])
+for density in [1.0, 0.5, 0.0]:
+x = rand_ndarray(shape=data_shape, stype=stype, density=density)
+w = rand_ndarray(shape=weight_shape, stype=stype, density=density)
+x_sym = mx.sym.Variable("data")
+w_sym = mx.sym.Variable("weight")
+sym = mx.sym.FullyConnected(data=x_sym, weight=w_sym,
num_hidden=weight_shape[0], no_bias=True)
+in_location = [x, w]
+check_numeric_gradient(sym, in_location, numeric_eps=1e-3,
rtol=1e-3, atol=5e-3)
+stypes = ['row_sparse', 'default']
+for stype in stypes:
+check_fullyconnected_training(stype)
+
+
if __name__ == '__main__':
test_mkldnn_install()
[GitHub] eric-haibin-lin closed pull request #11498: Fix InferStorage for sparse fallback in FullyConnected
eric-haibin-lin closed pull request #11498: Fix InferStorage for sparse
fallback in FullyConnected
URL: https://github.com/apache/incubator-mxnet/pull/11498
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/operator/nn/fully_connected-inl.h
b/src/operator/nn/fully_connected-inl.h
index 7eba2e20e57..2338f8974aa 100644
--- a/src/operator/nn/fully_connected-inl.h
+++ b/src/operator/nn/fully_connected-inl.h
@@ -35,6 +35,7 @@
#include "../operator_common.h"
#include "../elemwise_op_common.h"
#include "../linalg.h"
+#include "../../common/utils.h"
namespace mxnet {
namespace op {
diff --git a/src/operator/nn/fully_connected.cc
b/src/operator/nn/fully_connected.cc
index 48d479ccf60..46772a4db18 100644
--- a/src/operator/nn/fully_connected.cc
+++ b/src/operator/nn/fully_connected.cc
@@ -210,17 +210,21 @@ inline static bool BackwardFCStorageType(const
nnvm::NodeAttrs& attrs,
CHECK_EQ(in_attrs->size(), 3U);
CHECK_EQ(out_attrs->size(), out_expected);
- DispatchMode wanted_mode;
-#if 0
+ bool dispatched = false;
// TODO(zhengda) let's disable MKLDNN for FullyConnected for now.
// It seems there is a bug.
- if (dev_mask == mshadow::cpu::kDevMask)
-*dispatch_mode = DispatchMode::kFComputeEx;
- else
-#endif
-wanted_mode = DispatchMode::kFCompute;
- return storage_type_assign(out_attrs, mxnet::kDefaultStorage,
- dispatch_mode, wanted_mode);
+ if (!dispatched && common::ContainsOnlyStorage(*in_attrs,
mxnet::kDefaultStorage)) {
+storage_type_assign(out_attrs, mxnet::kDefaultStorage,
+dispatch_mode, DispatchMode::kFCompute);
+ }
+ if (!dispatched && common::ContainsStorageType(*in_attrs,
mxnet::kRowSparseStorage)) {
+dispatched = dispatch_fallback(out_attrs, dispatch_mode);
+ }
+ if (!dispatched) {
+dispatched = storage_type_assign(out_attrs, mxnet::kDefaultStorage,
+ dispatch_mode, DispatchMode::kFCompute);
+ }
+ return dispatched;
}
DMLC_REGISTER_PARAMETER(FullyConnectedParam);
diff --git a/tests/python/mkl/test_mkldnn.py b/tests/python/mkl/test_mkldnn.py
index 8c296deef20..a6d7743e926 100644
--- a/tests/python/mkl/test_mkldnn.py
+++ b/tests/python/mkl/test_mkldnn.py
@@ -22,7 +22,7 @@
import os
import numpy as np
import mxnet as mx
-from mxnet.test_utils import assert_almost_equal
+from mxnet.test_utils import rand_ndarray, assert_almost_equal
from mxnet import gluon
from mxnet.gluon import nn
from mxnet.test_utils import *
@@ -240,5 +240,25 @@ def check_batchnorm_training(stype):
for stype in stypes:
check_batchnorm_training(stype)
+
+@with_seed()
+def test_fullyconnected():
+def check_fullyconnected_training(stype):
+data_shape = rand_shape_nd(2)
+weight_shape = rand_shape_nd(2)
+weight_shape = (weight_shape[0], data_shape[1])
+for density in [1.0, 0.5, 0.0]:
+x = rand_ndarray(shape=data_shape, stype=stype, density=density)
+w = rand_ndarray(shape=weight_shape, stype=stype, density=density)
+x_sym = mx.sym.Variable("data")
+w_sym = mx.sym.Variable("weight")
+sym = mx.sym.FullyConnected(data=x_sym, weight=w_sym,
num_hidden=weight_shape[0], no_bias=True)
+in_location = [x, w]
+check_numeric_gradient(sym, in_location, numeric_eps=1e-3,
rtol=1e-3, atol=5e-3)
+stypes = ['row_sparse', 'default']
+for stype in stypes:
+check_fullyconnected_training(stype)
+
+
if __name__ == '__main__':
test_mkldnn_install()
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] szha commented on issue #11626: [MXNET-651] MXNet Model Backwards Compatibility Checker
szha commented on issue #11626: [MXNET-651] MXNet Model Backwards Compatibility Checker URL: https://github.com/apache/incubator-mxnet/pull/11626#issuecomment-404348704 For loading in past versions, there's no need to perform repeated tests as the code is not being updated. We only need to test them if there's a patch. For new versions, you can simply generate and save random parameters on s3, and use those in unit test to make sure it loads correctly. Let's avoid copying the example codes. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] thomelane commented on issue #9064: How to perform 2D convolution with user defined kernel just like sobel filter?
thomelane commented on issue #9064: How to perform 2D convolution with user defined kernel just like sobel filter? URL: https://github.com/apache/incubator-mxnet/issues/9064#issuecomment-404347843 With Gluon API you can `set_data` on a parameter. So for a convolutional layer you can select the `weight` (which will be the kernel) and call `set_data` on this with the kernel of your choosing. You must make sure you have the correct shape, with the dimensions being (filter, channel, height, width). So if we wanted a single sobel kernel applied to a single channel input we could for the following: ``` import mxnet as mx # kernel of your choosing (e.g. a sobel filter) kernel = mx.nd.array(((1,0,-1), (2,0,-2), (1,0,-1))) # add dimensions for filters, and input channel # both of which will have shape 1, since single filter and single input channel weight = kernel.expand_dims(0).expand_dims(0) conv = mx.gluon.nn.Conv2D(channels=1, kernel_size=(3,3), padding=(1,1)) conv._in_channels = 1 conv.initialize() conv.weight.set_data(weight) ``` This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ifeherva commented on a change in pull request #11643: Added the diag() operator
ifeherva commented on a change in pull request #11643: Added the diag() operator URL: https://github.com/apache/incubator-mxnet/pull/11643#discussion_r201874422 ## File path: tests/python/unittest/test_operator.py ## @@ -6977,6 +6977,109 @@ def test_roi_align_autograd(sampling_ratio=0): test_roi_align_value(2) test_roi_align_autograd() +@with_seed() +def test_diag(): + +# test 2d input +h = np.random.randint(2,9) +w = np.random.randint(2,9) +a_np = np.random.random((h, w)) +a = mx.nd.array(a_np) + +# k == 0 +r = mx.nd.diag(a) + +for i in range(r.shape[0]): +assert r[i] == a[i][i] Review comment: Good point, will do This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] thomelane commented on issue #9915: Our FCN-xs result on Pascal VOC Validation
thomelane commented on issue #9915: Our FCN-xs result on Pascal VOC Validation URL: https://github.com/apache/incubator-mxnet/issues/9915#issuecomment-404345421 @shipeng-uestc Are you referring to the example [here](https://github.com/apache/incubator-mxnet/tree/master/example/fcn-xs)? When running the script you should be able to see the validation loss logged after every epoch. It will depend on the specific model you've selected though. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] eric-haibin-lin opened a new issue #11660: MXNet aborts when setting round_batch=False for LibSVMIter
eric-haibin-lin opened a new issue #11660: MXNet aborts when setting round_batch=False for LibSVMIter URL: https://github.com/apache/incubator-mxnet/issues/11660 As title. This should be fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] zhreshold commented on a change in pull request #11643: Added the diag() operator
zhreshold commented on a change in pull request #11643: Added the diag() operator URL: https://github.com/apache/incubator-mxnet/pull/11643#discussion_r201872980 ## File path: tests/python/unittest/test_operator.py ## @@ -6977,6 +6977,109 @@ def test_roi_align_autograd(sampling_ratio=0): test_roi_align_value(2) test_roi_align_autograd() +@with_seed() +def test_diag(): + +# test 2d input +h = np.random.randint(2,9) +w = np.random.randint(2,9) +a_np = np.random.random((h, w)) +a = mx.nd.array(a_np) + +# k == 0 +r = mx.nd.diag(a) + +for i in range(r.shape[0]): +assert r[i] == a[i][i] Review comment: you can use numpy for consistency check. It's more stable than manually setting the desired values This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] zhreshold commented on a change in pull request #11643: Added the diag() operator
zhreshold commented on a change in pull request #11643: Added the diag()
operator
URL: https://github.com/apache/incubator-mxnet/pull/11643#discussion_r201871245
##
File path: src/operator/tensor/diag_op-inl.h
##
@@ -0,0 +1,214 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+/*!
+* Copyright (c) 2015 by Contributors
+* \file diag_op-inl.h
+* \brief CPU Implementation of the diag op
+* \author Istvan Fehervari
+*/
+
+#ifndef MXNET_OPERATOR_TENSOR_DIAG_OP_INL_H_
+#define MXNET_OPERATOR_TENSOR_DIAG_OP_INL_H_
+
+#include
+#include
+#include
+#include "../mxnet_op.h"
+#include "../operator_common.h"
+#include "../elemwise_op_common.h"
+
+namespace mxnet {
+namespace op {
+
+struct DiagParam : public dmlc::Parameter {
+int32_t k;
+DMLC_DECLARE_PARAMETER(DiagParam) {
+DMLC_DECLARE_FIELD(k)
Review comment:
indentation looks weird, I think the lint suggest 2 spaces or 4 spaces
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] thomelane commented on issue #10006: How to visualise filters of MXNet model?
thomelane commented on issue #10006: How to visualise filters of MXNet model? URL: https://github.com/apache/incubator-mxnet/issues/10006#issuecomment-404344062 @sandeep-krishnamurthy good answer on this, so good to close. thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] OneRaynyDay commented on issue #11659: Segmentation fault upon using mx2onnx (export_model)
OneRaynyDay commented on issue #11659: Segmentation fault upon using mx2onnx (export_model) URL: https://github.com/apache/incubator-mxnet/issues/11659#issuecomment-404341382 Suggested labels: Bug This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] OneRaynyDay opened a new issue #11659: Segmentation fault upon using onnx
OneRaynyDay opened a new issue #11659: Segmentation fault upon using onnx
URL: https://github.com/apache/incubator-mxnet/issues/11659
## Description
Hi, Airbnb is currently using ONNX for our model applications. We ran into
this error while trying to serialize mxnet with onnx. It appears that trying to
import onnx at some stage of `export_model` in `mx2onnx` gives us a
segmentation fault.
NOTE: The problem is not reproducible in mac OS X. The code is in a nosetest
and the tests all pass in High Sierra. Specific OS information is enumerated
below.
# Error:
```
Segmentation fault: 11
Stack trace returned 10 entries:
[bt] (0) /usr/local/lib/python3.6/dist-packages/mxnet/libmxnet.so(+0x19e004)
[0x7f9952c71004]
[bt] (1)
/usr/local/lib/python3.6/dist-packages/mxnet/libmxnet.so(+0x2c42bc6)
[0x7f9955715bc6]
[bt] (2) /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f9975bfef20]
[bt] (3)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(+0x63bfd)
[0x7f99388cabfd]
[bt] (4)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(+0x6f82f)
[0x7f99388d682f]
[bt] (5)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(+0x54019)
[0x7f99388bb019]
[bt] (6)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(PyInit_onnx_cpp2py_export+0x10f)
[0x7f99388bea1f]
[bt] (7) /usr/bin/python3.6(_PyImport_LoadDynamicModuleWithSpec+0x17b)
[0x576fab]
[bt] (8) /usr/bin/python3.6() [0x574825]
[bt] (9) /usr/bin/python3.6(PyCFunction_Call+0xbd) [0x4c517d]
```
# Operating system information:
```
root@ec34adf6c4e7:/mnt/bighead# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename:bionic
```
# PDB stack trace(sensitive details redacted):
```
-> self.serialize_transform(model, X, serializer_key='onnx')
(Pdb) s
--Call--
> /mnt/xxx/python/xxx/tests/test_utils.py(16)serialize_transform()
-> def serialize_transform(self, model, data, check=True,
serializer_key=None):
(Pdb) s
> /mnt/xxx/python/xxx/tests/test_utils.py(28)serialize_transform()
-> srz = get_serializer(model.serializer, key=serializer_key)
(Pdb) n
> /mnt/xxx/python/xxx/tests/test_utils.py(29)serialize_transform()
-> desrz = get_deserializer(model.deserializer, key=serializer_key)
(Pdb) n
> /mnt/xxx/python/xxx/tests/test_utils.py(30)serialize_transform()
-> with tempfile.TemporaryDirectory() as temp_dir:
(Pdb) n
> /mnt/xxx/python/xxx/tests/test_utils.py(31)serialize_transform()
-> srz(model, temp_dir)
(Pdb) s
--Call--
> /mnt/xxx/python/xxx/ml_frameworks/mxnet/gluon.py(393)onnx_serialize_fn()
-> @classmethod
(Pdb) n
> /mnt/xxx/python/xxx/ml_frameworks/mxnet/gluon.py(406)onnx_serialize_fn()
-> try:
(Pdb) n
> /mnt/xxx/python/xxx/ml_frameworks/mxnet/gluon.py(407)onnx_serialize_fn()
-> import onnx # noqa
(Pdb) n
Segmentation fault: 11
Stack trace returned 10 entries:
[bt] (0) /usr/local/lib/python3.6/dist-packages/mxnet/libmxnet.so(+0x19e004)
[0x7faa1b0d0004]
[bt] (1)
/usr/local/lib/python3.6/dist-packages/mxnet/libmxnet.so(+0x2c42bc6)
[0x7faa1db74bc6]
[bt] (2) /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7faa3e05df20]
[bt] (3)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(+0x63bfd)
[0x7fa9f4c0bbfd]
[bt] (4)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(+0x6f82f)
[0x7fa9f4c1782f]
[bt] (5)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(+0x54019)
[0x7fa9f4bfc019]
[bt] (6)
/usr/local/lib/python3.6/dist-packages/onnx/onnx_cpp2py_export.cpython-36m-x86_64-linux-gnu.so(PyInit_onnx_cpp2py_export+0x10f)
[0x7fa9f4bffa1f]
[bt] (7) /usr/bin/python3.6(_PyImport_LoadDynamicModuleWithSpec+0x17b)
[0x576fab]
[bt] (8) /usr/bin/python3.6() [0x574825]
[bt] (9) /usr/bin/python3.6(PyCFunction_Call+0xbd) [0x4c517d]
```
### A couple lines around the segfault code
```
@classmethod
def onnx_serialize_fn(cls, t, path):
"""
...
"""
try:
import onnx # noqa
except ImportError:
raise ImportError('Onnx and protobuf need to be installed.
Instructions to'
+ ' install -
https://github.com/onnx/onnx#installation')
...
```
# ONNX and protobuf versions
```
root@ec34adf6c4e7:/mnt# pip3 freeze | grep onnx
onnx==1.2.2
root@ec34adf6c4e7:/mnt# pip3 freeze | grep protobuf
protobuf==3.6.0
root@ec34adf6c4e7:/mnt/bighead# pip freeze | grep mxnet
keras-mxnet==2.2.0
mxnet-mkl==1.3.0b20180711
[GitHub] access2rohit commented on issue #11120: Address already in use during tutorial test
access2rohit commented on issue #11120: Address already in use during tutorial test URL: https://github.com/apache/incubator-mxnet/issues/11120#issuecomment-404341030 @ThomasDelteil : Can you specify which "jenkins functions for tutorial tests" are you referring to in order to reproduce the tests ? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] piiswrong commented on issue #11658: Optimize cached op static memory allocation
piiswrong commented on issue #11658: Optimize cached op static memory allocation URL: https://github.com/apache/incubator-mxnet/pull/11658#issuecomment-404339419 what API doc? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] eric-haibin-lin opened a new issue #10709: [SPARSE] undeterministic result of sparse dot(csr, dense, transpose_a=True)
eric-haibin-lin opened a new issue #10709: [SPARSE] undeterministic result of
sparse dot(csr, dense, transpose_a=True)
URL: https://github.com/apache/incubator-mxnet/issues/10709
The following test failed because of the limited precision of fp32 and the
usage of atomicAdd in sparse dot implementation:
```
def check_dot_determinism(lhs_stype, rhs_stype, lhs_density,
rhs_density, transpose_a, transpose_b):
lhs_shape = (2, 200)
rhs_shape = (2, 200)
lhs = rand_ndarray(lhs_shape, lhs_stype, density=lhs_density)
rhs = rand_ndarray(rhs_shape, rhs_stype, density=rhs_density)
res1 = mx.nd.sparse.dot(lhs, rhs, transpose_a=transpose_a,
transpose_b=transpose_b)
res2 = mx.nd.sparse.dot(lhs, rhs, transpose_a=transpose_a,
transpose_b=transpose_b)
assert_almost_equal(res1.asnumpy(), res2.asnumpy(), rtol=0.0,
atol=0.0)
check_dot_determinism('csr', 'default', 0.5, 1.0, True, False)
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] eric-haibin-lin commented on issue #10709: [SPARSE] undeterministic result of sparse dot(csr, dense, transpose_a=True)
eric-haibin-lin commented on issue #10709: [SPARSE] undeterministic result of sparse dot(csr, dense, transpose_a=True) URL: https://github.com/apache/incubator-mxnet/issues/10709#issuecomment-404338961 we still have the same problem for dot(csr.T, dns) = dns This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] safrooze commented on issue #11658: Optimize cached op static memory allocation
safrooze commented on issue #11658: Optimize cached op static memory allocation URL: https://github.com/apache/incubator-mxnet/pull/11658#issuecomment-404338259 @piiswrong API doc needs permissions. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] piiswrong opened a new pull request #11658: Optimize cached op static memory allocation
piiswrong opened a new pull request #11658: Optimize cached op static memory allocation URL: https://github.com/apache/incubator-mxnet/pull/11658 ## Description ## (Brief description on what this PR is about) ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes) - [ ] Changes are complete (i.e. I finished coding on this PR) - [ ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ ] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [ ] Feature1, tests, (and when applicable, API doc) - [ ] Feature2, tests, (and when applicable, API doc) ## Comments ## - If this change is a backward incompatible change, why must this change be made. - Interesting edge cases to note here This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] eric-haibin-lin opened a new pull request #11657: documentation enhancement for optimizers
eric-haibin-lin opened a new pull request #11657: documentation enhancement for optimizers URL: https://github.com/apache/incubator-mxnet/pull/11657 ## Description ## Added more clarification for optimizers ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes) - [ ] Changes are complete (i.e. I finished coding on this PR) - [ ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ ] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [ ] Feature1, tests, (and when applicable, API doc) - [ ] Feature2, tests, (and when applicable, API doc) ## Comments ## - If this change is a backward incompatible change, why must this change be made. - Interesting edge cases to note here This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] aaronmarkham commented on issue #11562: [MXNET-244] Update RaspberryPI instructions
aaronmarkham commented on issue #11562: [MXNET-244] Update RaspberryPI instructions URL: https://github.com/apache/incubator-mxnet/pull/11562#issuecomment-404333098 CI seems to be running fine for the docs job... I guess when you try to run that script manually you get an error? Have you run this first? `./ci/docker/install/ubuntu_scala.sh` There was a new scaladocs step added to the build fairly recently which does a make scalapkg prior to scaladocs being run. You'll need all of the scala deps to run that. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] eric-haibin-lin commented on issue #11633: Fix dist kvstore for trainer and flaky dist kvstore test
eric-haibin-lin commented on issue #11633: Fix dist kvstore for trainer and flaky dist kvstore test URL: https://github.com/apache/incubator-mxnet/pull/11633#issuecomment-404331568 I thought @rahul003 fixed that? Could you confirm? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. The contradiction forces it into the incompatible class. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. Approach 2 works. We will add a unit test for this to show that it works for your scenario. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. Approach 2 works. We will add a unit test for this to show that it works for your scenario. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. The nice thing is that the pair compatibility can be determined once to test all possibilities of subgraph growing, instead of having to do a full search (e.g. DFS, DFS with graph coloring, Kahn's algorithm, whatever) every time a node is greedily added and substituted. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] kpmurali commented on issue #11634: website install page query string needed for devices
kpmurali commented on issue #11634: website install page query string needed for devices URL: https://github.com/apache/incubator-mxnet/issues/11634#issuecomment-404325923 I will work on this. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] szha commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples
szha commented on a change in pull request #11642: MXNET-650 [Perl] Gluon ModelZoo, Gluon examples URL: https://github.com/apache/incubator-mxnet/pull/11642#discussion_r201854260 ## File path: perl-package/AI-MXNet-Gluon-ModelZoo/examples/image_classification.pl ## @@ -0,0 +1,80 @@ +#!/usr/bin/env perl +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +use strict; +use warnings; +use AI::MXNet::Gluon::ModelZoo 'get_model'; +use AI::MXNet::Gluon::Utils 'download'; +use Getopt::Long qw(HelpMessage); + +GetOptions( +## my Pembroke Welsh Corgi Kyuubi, enjoing Solar eclipse of August 21, 2017 +'image=s' => \(my $image = 'https://scontent-sea1-1.cdninstagram.com/vp/'. Review comment: How long does this pic persist on the CDN of instagram? Will the link expire? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓ ↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓ ↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] zheng-da commented on a change in pull request #11566: [MXNET-626] Add while_loop
zheng-da commented on a change in pull request #11566: [MXNET-626] Add
while_loop
URL: https://github.com/apache/incubator-mxnet/pull/11566#discussion_r201852717
##
File path: python/mxnet/ndarray/contrib.py
##
@@ -191,3 +191,128 @@ def check_input(inputs, in_type, msg):
if not_data_list and len(outputs) == 1:
outputs = outputs[0]
return (outputs, states)
+
+
+def while_loop(loop_vars, cond, func, max_iterations):
+"""Run a while loop with user-defined computation and loop condition.
+
+This operator simulates a while loop which iterately does customized
computation
+as long as the condition is satisfied.
+
+`loop_vars` is a list of NDArrays on which the computation uses.
+
+`cond` is a user-defined function as the loop condition.
+It consumes `loop_vars`, and produces a scalar MXNet NDArray,
+indicating the termination of the loop.
+The loop ends when `cond` returns false (zero).
+The `cond` is variadic, and its signature should be
+`cond(*loop_vars) => NDArray`.
+
+`func` is a user-defined function as the loop body.
+It also consumes `loop_vars`, and produces `step_output` and
`new_loop_vars` at each step.
+The number of elements, shape, dtype of each element in `step_output`
should be consistent.
+The `new_loop_vars` should be consistent with `loop_vars` on each step.
+The `func` is variadic, and its signature should be
+`func(*loop_vars) => (List[NDArray] step_output, List[NDArray]
new_loop_vars)`.
+
+`max_iterations` is a scalar that defines the maximum number of iterations
allowed.
+
+This function returns a list of NDArrays of length `|step_output| +
|loop_vars|`.
+The i-th element in the first `|step_output|` ones of the list represent
+the i-th `step_output` at all step, stacked along axis 0.
+The i-th element in the last `|loop_vars|` ones of the list
+represent the final state of each loop variable.
+
+Warning 1: when `cond` is never satisfied, we assume `step_output` is
empty.
+Warning 2: The output shape along axis 0 is currently `max_iteration`,
+which not consistent to the symbloic version.
+
+Parameters
+--
+loop_vars: list of NDArrays.
+The initial values of the loop variables.
+cond: a Python function.
+The loop condition.
+func: a Python function.
+The loop body.
+max_iteration: a python int.
+Maximum number of iterations.
+
+Returns
+---
+outputs: a tuple of two lists, which both contains 0, 1 or more NDArrays.
+The first list contains the stacked output from each step,
+The second list contains the final state.
+
+Examples
+
+>>> cond = lambda i, s: i <= 5
+>>> func = lambda i, s: ([i + s], [i + 1, s + i])
+>>> loop_vars = (mx.nd.array([0], dtype="int64"), mx.nd.array([1],
dtype="int64"))
+>>> outputs, states = mx.nd.contrib.while_loop(loop_vars, cond, func,
max_iterations=10)
+"""
+def _to_python_scalar(inputs, type_, name):
+"""Converts "inputs", possibly typed mxnet NDArray, a numpy ndarray,
other python types,
+to the given type
+"""
+if isinstance(inputs, ndarray.NDArray):
+inputs = inputs.asscalar()
+try:
+inputs = type_(inputs)
+except:
+raise ValueError("Cannot convert %s to python %s" % (name,
type_.__name__))
+return inputs
+
+def _to_ndarray_tuple(inputs, name):
+"""Converts "inputs", possibly a single mxnet NDArray, a list of mxnet
NDArray,
+a tuple of mxnet NDArray, into a tuple of NDArray
+"""
+if isinstance(inputs, list):
+inputs = tuple(inputs)
+if isinstance(inputs, ndarray.NDArray):
+inputs = (inputs, )
+if not isinstance(inputs, tuple):
+raise ValueError("%s must be an NDArray, or a tuple or list of
NDArrays" % (name, ))
+for item in inputs:
+if not isinstance(item, ndarray.NDArray):
+raise ValueError("%s must be an NDArray, or a tuple or list of
NDArrays" % (name, ))
+return inputs
+
+def _func_wrapper(loop_vars):
+"""This wrapper unifies
+ "func: loop_vars -> new_loop_vars"
+ and "func: loop_vars -> (step_output, new_loop_vars)"
+into "func: loop_vars -> (None or tuple of step_outputs, tuple of
new_loop_vars)
+"""
+step_output, new_loop_vars = func(*loop_vars)
+if step_output is None:
+step_output = []
+if new_loop_vars is None:
+new_loop_vars = []
+step_output = _to_ndarray_tuple(step_output, "step_output")
+new_loop_vars = _to_ndarray_tuple(new_loop_vars, "new_loop_vars")
+if len(loop_vars) != len(new_loop_vars):
+raise ValueError("The length of loop_vars should be consistent
during the loop")
+return step_output,
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair is compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` **Approach 1 - naively growing the subgraph and checking for cycles each time** This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. Hence, the most contracted legal subgraph contains the nodes T*, D and C*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. **Approach 2 - Examining sets of pairs** Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge from the node replacing the subgraph is from B* to C*, not the other way around. So, we have the following: ``` ↗D T* ↓ ↘C* ``` Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] slitsey commented on issue #11466: [MXNET-560] Add temperature parameter in Softmax operator
slitsey commented on issue #11466: [MXNET-560] Add temperature parameter in Softmax operator URL: https://github.com/apache/incubator-mxnet/pull/11466#issuecomment-404322634 @haojin2 Does this approach sound like something you would be comfortable with? It seems like it resolves the issues we've discussed in an elegant and efficient way. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node while greedily growing the subgraph and if a cycle is formed while adding a new node, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] anirudh2290 commented on issue #11655: CI Problem: new commits not triggering new builds
anirudh2290 commented on issue #11655: CI Problem: new commits not triggering new builds URL: https://github.com/apache/incubator-mxnet/issues/11655#issuecomment-404322283 Closing and tracking in #11654. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] anirudh2290 closed issue #11655: CI Problem: new commits not triggering new builds
anirudh2290 closed issue #11655: CI Problem: new commits not triggering new builds URL: https://github.com/apache/incubator-mxnet/issues/11655 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] haojin2 commented on issue #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True
haojin2 commented on issue #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True URL: https://github.com/apache/incubator-mxnet/pull/11656#issuecomment-404322020 @anirudh2290 That's a duplicate issue of #11654. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] haojin2 commented on issue #11655: CI Problem: new commits not triggering new builds
haojin2 commented on issue #11655: CI Problem: new commits not triggering new builds URL: https://github.com/apache/incubator-mxnet/issues/11655#issuecomment-404321926 This is a duplicate of #11654. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] anirudh2290 commented on issue #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True
anirudh2290 commented on issue #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True URL: https://github.com/apache/incubator-mxnet/pull/11656#issuecomment-404321518 Link to the issue: https://github.com/apache/incubator-mxnet/issues/11655 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓ ↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓ ↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): ``` A* → D ↓ ↓ B* → C* ``` Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: ``` A* → D ↘ T* ↙ ``` The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] anirudh2290 commented on issue #11568: Issues with spatial transformer op when cudnn disabled
anirudh2290 commented on issue #11568: Issues with spatial transformer op when cudnn disabled URL: https://github.com/apache/incubator-mxnet/issues/11568#issuecomment-404320744 Added disabled test since the tests are disabled for USE_CUDA=ON USE_CUDNN=OFF as part of #11470 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): A* → D ↓↓ B* → C* Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: A* → D ↘ T* ↙ The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] haojin2 commented on issue #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True
haojin2 commented on issue #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True URL: https://github.com/apache/incubator-mxnet/pull/11656#issuecomment-404320740 @marcoabreu Seems like there's no build triggered for this: http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/activity/?branch=PR-11656. Can you take a look? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod edited a comment on issue #11325: Added TensorRT runtime integration
mkolod edited a comment on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): A* → D ↓ ↓ B* → C* Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: A* → D ↘ T* ↙ The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] mkolod commented on issue #11325: Added TensorRT runtime integration
mkolod commented on issue #11325: Added TensorRT runtime integration URL: https://github.com/apache/incubator-mxnet/pull/11325#issuecomment-404320678 @reminisce Regarding your question about the cycle check, I'd like to juxtapose two approaches, one of which is the one taken here, and the other is more typical but probably less efficient for large graphs. Here's your graph (starred nodes are TensorRT-compatible, unstarred ones are not): A* → D ↓↓ B* → C* Approach 1 - naively growing the subgraph and checking for cycles each time This approach tests adding a new node and if a cycle is formed, the node is rejected. Taking your graph as an example, say we start with A*. Clearly TensorRT only helps when there are 2 or more nodes, due to its benefit being mainly due to fusion. So, we get (A*, B*) in the set of nodes in the TensorRT graph. This is fine, there's no cycle, because the edge is from B* to C*, not the other way around. Now we try adding C*, to get (A*, B*, C*) in the TensorRT subgraph. Let's call this subgraph T*. Now D is the only node outside the subgraph and we have a cycle from T* to D, back to T*. This was an illegal contraction, so the last step is rejected, and only A* → B* gets substituted with T*. This is in fact how TensorRT integration with TensorFlow works, or used to, the last time I checked. Approach 2 - two search passes, examining sets of pairs Instead of the naive subgraph growth, let's enumerate all pairs of nodes that are TensorRT-compatible or incompatible. A pair compatible if both nodes between the edge are TensorRT-compatible - only then can they go into the TensorRT subgraph. For the graph above, this would be A* → B* and B* → C*. A* → D is incompatible because D is incompatible, so the whole pair is incompatible. Similarly, D → C* is incompatible because D is incompatible. However, if there is a node which is part of both a compatible pair and an incompatible pair, it's no longer a candidate for the TensorRT graph. Such a node is A*. That's because even though it's compatible in one pair (A* → B*), it's incompatible in another (A* → D). So, the only edge that can be collapsed is B* → C* and these two nodes become T*. Now the graph after the rewrite will look as follows: A* → D ↘ T* ↙ The graph partitioner for this commit takes Approach 2. We will add a unit test for this to show that it works. I hope this clarifies your question as to how we handle cycles. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] haojin2 opened a new pull request #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True
haojin2 opened a new pull request #11656: Fix batchnorm problem with sparse matrices when fix_gamma=True URL: https://github.com/apache/incubator-mxnet/pull/11656 ## Description ## As title. ## Checklist ## ### Essentials ### - [x] Changes are complete (i.e. I finished coding on this PR) - [x] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [x] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [x] Fix fallback logic for batchnorm operator - [x] Block usage of fix_gamma=True when input is sparse - [x] Unit tests ## Comments ## This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] haojin2 closed pull request #11631: Fix batchnorm problem with sparse matrices when fix_gamma=True
haojin2 closed pull request #11631: Fix batchnorm problem with sparse matrices
when fix_gamma=True
URL: https://github.com/apache/incubator-mxnet/pull/11631
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/operator/batch_norm_v1.cc b/src/operator/batch_norm_v1.cc
index 5da4af25368..cefadc481a2 100644
--- a/src/operator/batch_norm_v1.cc
+++ b/src/operator/batch_norm_v1.cc
@@ -89,6 +89,9 @@ the output. It is often used during inference.
Both ``gamma`` and ``beta`` are learnable parameters. But if ``fix_gamma`` is
true,
then set ``gamma`` to 1 and its gradient to 0.
+There's no sparse support for this operator, and will exhibit problematic
behavior if used with
+sparse tensors.
+
)code" ADD_FILELINE)
.add_argument("data", "NDArray-or-Symbol", "Input data to batch normalization")
.add_argument("gamma", "NDArray-or-Symbol", "gamma array")
diff --git a/src/operator/nn/batch_norm.cc b/src/operator/nn/batch_norm.cc
index 1f9e8289f4a..6548f4692ac 100644
--- a/src/operator/nn/batch_norm.cc
+++ b/src/operator/nn/batch_norm.cc
@@ -444,6 +444,7 @@ void BatchNormGradComputeExCPU(const nnvm::NodeAttrs ,
}
FallBackCompute(BatchNormGradCompute, attrs, ctx, inputs, req, outputs);
}
+#endif
static inline bool BatchNormStorageType(const nnvm::NodeAttrs ,
const int dev_mask,
@@ -452,8 +453,32 @@ static inline bool BatchNormStorageType(const
nnvm::NodeAttrs ,
std::vector *out_attrs) {
CHECK_EQ(in_attrs->size(), 5);
CHECK_EQ(out_attrs->size(), 3);
- return MKLDNNStorageType(attrs, dev_mask, true, dispatch_mode,
- in_attrs, out_attrs);
+ const BatchNormParam = nnvm::get(attrs.parsed);
+
+ if ((common::ContainsStorageType(*in_attrs, kRowSparseStorage) ||
+ common::ContainsStorageType(*in_attrs, kCSRStorage)) &&
+ param.fix_gamma) {
+LOG(FATAL) << "fix_gamma=True is not supported for sparse ndarrays.
Tracked at #11647";
+ }
+ for (int& v : *in_attrs)
+if (v == - 1) v = kDefaultStorage;
+ bool dispatched = false;
+ if (!dispatched && (common::ContainsStorageType(*in_attrs,
kRowSparseStorage) ||
+ common::ContainsStorageType(*in_attrs, kCSRStorage))) {
+dispatched = dispatch_fallback(out_attrs, dispatch_mode);
+ }
+#if MXNET_USE_MKLDNN == 1
+ if (!dispatched) {
+dispatched = MKLDNNStorageType(attrs, dev_mask, true, dispatch_mode,
+ in_attrs, out_attrs);
+ }
+#else
+ if (!dispatched) {
+dispatched = storage_type_assign(out_attrs, kDefaultStorage,
+ dispatch_mode, DispatchMode::kFCompute);
+ }
+#endif
+ return dispatched;
}
static inline bool backward_BatchNormStorageType(const nnvm::NodeAttrs ,
@@ -461,10 +486,33 @@ static inline bool backward_BatchNormStorageType(const
nnvm::NodeAttrs ,
DispatchMode *dispatch_mode,
std::vector *in_attrs,
std::vector *out_attrs) {
- return MKLDNNStorageType(attrs, dev_mask, true, dispatch_mode,
- in_attrs, out_attrs);
-}
+ const BatchNormParam = nnvm::get(attrs.parsed);
+
+ if ((common::ContainsStorageType(*in_attrs, kRowSparseStorage) ||
+ common::ContainsStorageType(*in_attrs, kCSRStorage)) &&
+ param.fix_gamma) {
+LOG(FATAL) << "fix_gamma=True is not supported for sparse ndarrays.
Tracked at #11647";
+ }
+ for (int& v : *in_attrs)
+if (v == - 1) v = kDefaultStorage;
+ bool dispatched = false;
+ if (!dispatched && (common::ContainsStorageType(*in_attrs,
kRowSparseStorage) ||
+ common::ContainsStorageType(*in_attrs, kCSRStorage))) {
+dispatched = dispatch_fallback(out_attrs, dispatch_mode);
+ }
+#if MXNET_USE_MKLDNN == 1
+ if (!dispatched) {
+dispatched = MKLDNNStorageType(attrs, dev_mask, true, dispatch_mode,
+ in_attrs, out_attrs);
+ }
+#else
+ if (!dispatched) {
+dispatched = storage_type_assign(out_attrs, kDefaultStorage,
+ dispatch_mode, DispatchMode::kFCompute);
+ }
#endif
+ return dispatched;
+}
std::vector BatchNormGrad(const nnvm::NodePtr& n,
const std::vector&
ograds) {
@@ -552,6 +600,11 @@ axis to be the last item in the input shape.
Both ``gamma`` and ``beta`` are learnable parameters. But if ``fix_gamma`` is
true,
then set ``gamma`` to 1 and its gradient to 0.
+Note::
+
+When fix_gamma is set to True, no sparse support is provided. If fix_gamma is
set to False,
+the sparse tensors will fallback.
+
)code"
[GitHub] haojin2 commented on issue #11631: Fix batchnorm problem with sparse matrices when fix_gamma=True
haojin2 commented on issue #11631: Fix batchnorm problem with sparse matrices when fix_gamma=True URL: https://github.com/apache/incubator-mxnet/pull/11631#issuecomment-404319992 @marcoabreu @anirudh2290 I'll be creating another PR for this with the same changes as there's no way for me to re-trigger the build due to the CI bug. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
