Re: [Announcement] New Committer - Hao Jin
Congrats Hao! On Tue, Apr 30, 2019 at 10:53 PM Steffen Rochel wrote: > congratulation Hao! > > On Tue, Apr 30, 2019 at 8:05 AM MiraiWK WKCN wrote: > > > Congrats Hao! Welcome! > > > > > > From: Lv, Tao A > > Sent: Tuesday, April 30, 2019 11:00:33 PM > > To: dev@mxnet.incubator.apache.org > > Subject: RE: [Announcement] New Committer - Hao Jin > > > > Congratulations Hao! > > > > -Original Message- > > From: Jun Wu [mailto:wujun@gmail.com] > > Sent: Tuesday, April 30, 2019 12:29 PM > > To: dev@mxnet.incubator.apache.org > > Subject: [Announcement] New Committer - Hao Jin > > > > Please join me in welcoming Hao Jin (https://github.com/haojin2) from > AWS > > as a new committer. > > > > Hao has designed and implemented many sophisticated algorithms for tensor > > operations. His work has greatly expanded the coverage of MXNet operator > > inventory and enhanced the performance of many operators that are hard to > > be optimized. Not only that, Hao has been active in advocating MXNet > > through providing high-quality translation service for quite a few > > technical articles and blog posts. > > >
Re: [Announcement] New Committer - Alex Zai
Thanks everyone. Looking forward to helping mxnet continue to grow. Best,Alex On Mon, Apr 1, 2019 1:38 AM, Lin Yuan apefor...@gmail.com wrote: Congrats, Alex! Hope your book is going well :) Lin On Sun, Mar 31, 2019 at 6:18 PM Zhao, Patric wrote: Congratulation, Alex. Thank you to your helps for MKLDNN backend including tests, coverage, CI :) Looking forward more cooperation together. > -Original Message- > From: Steffen Rochel [mailto:steffenroc...@gmail.com] > Sent: Monday, April 1, 2019 8:56 AM > To: dev@mxnet.incubator.apache.org > Cc: Alex Zai > Subject: Re: [Announcement] New Committer - Alex Zai > > Congratulation Alex! > > On Sun, Mar 31, 2019 at 4:17 PM Carin Meier > wrote: > > > Welcome and congrats! > > > > On Sun, Mar 31, 2019 at 12:48 PM Anirudh Subramanian < > > anirudh2...@gmail.com> > > wrote: > > > > > Hi all, > > > > > > Please join me to welcome Alex Zai as a new committer of Apache > > > (incubating) MXNet! > > > > > > Alex has been instrumental in brining MKLDNN from experimental to > > > making > > it > > > default on MXNet master. This involved adding Python and C++ unit > > > tests, improving CI coverage for MKLDNN, testing MKLDNN on different > > > platforms > > and > > > working on issues related to MKLDNN. > > > > > > PRs: > > > > > > > > https://github.com/apache/incubator- > mxnet/pulls?utf8=%E2%9C%93=is%3A > > pr+author%3Aazai91+ > > > > > > Issues: > > > > > > > > https://github.com/apache/incubator- > mxnet/issues?utf8=%E2%9C%93=is%3 > > Aissue+involves%3Aazai91 > > > > > > Reviews: > > > > > > > > https://github.com/apache/incubator- > mxnet/pulls?page=1=is%3Apr+revie > > wed-by%3Aazai91=%E2%9C%93 > > > > > > Dev: > > > https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:azai9 > > > 1 > > > > > > Thanks, > > > > > > Anirudh > > > > >
Re: [Annoucement] New Committer -- Da Zheng
Congrats Da. On Mon, Dec 17, 2018, 7:20 PM Emani, Ashok Congratulations Da, well deserved! > > On 12/17/18, 9:02 AM, "Tianqi Chen" wrote: > > Dear Community: > > Please join me to welcome Da Zheng as a new committer of the MXNet. > > Da is the main author of MKL-DNN integration and recently he champions > the > control flow support. He is one of the few "explorer style" > contributors of > the community, who we desperately need in this fast change environment > of > the deep learning system landscape. > > PRs https://github.com/apache/incubator-mxnet/commits?author=zheng-da > reviews * > https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Azheng-da+ > < > https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Azheng-da+ > >* > dev@ > https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:da- > zheng > > Tianqi > > >
Julia CI Package
Is anyone familiar with the Julia build and can help debug an issue where the Julia stage in the CI just hangs? I have made a change where I am making mkldnn default on the master branch. This means that the julia package now is being build with a version of mxnet that is linking to mkldnn). The julia stage on the CI just hangs without any error message and gets killed after the 2 hour timeout ( http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-13464/40/pipeline ). Alex
Include MKLDNN into default mxnet pip package
Continuation from the following thread: https://lists.apache.org/thread.html/bcb1bd5046ff51049a0556098e756578f6fa6564831d77fddb56432f@%3Cdev.mxnet.apache.org%3E I am also +1 for making it on master and testing until 1.5.0. We can decide later on (before 1.5.0) to enable mkldnn as default for the nightly build (pip install --pre build) to try to get more feedback if needed. - What the story is like when there's no AVX instructions present on CPUs. Do we get an illegal instruction error, or does it fallback gracefully? According to this issue ( https://github.com/apache/incubator-mxnet/issues/11911), AVX2 is the minimum requirement for pre-build binaries. - Are there any outstanding issues when MKLDNN is enabled? -There is one issues with quantization int8 of mkldnn (will create issue about it when team gives me reproducible code snippet). Additionally, we are waiting to merge the PR to build mkldnn statically with mac/linux when building from source after MKL is added to the CI. - MKLDNN is a submodule dependency, are we pulling the latest commit or releases? If not we should move to releases before we make it a default I agree. We should tag mxnet only to releases from now on. Currently it is tagged to 0.17.1 Please let me know if there any other outstanding issues, else we are going to make mkldnn / cmake default in the Make/CMakefile. Alex
Re: v1.4.0 status 11/29
PR is here https://github.com/apache/incubator-mxnet/pull/13497. On Thu, Nov 29, 2018 at 8:56 PM Lv, Tao A wrote: > Credit belongs to Alex. > > Hi Alex, would you mind porting your fix to the v1.4.x branch? > > Thanks, > -Tao > > -Original Message- > From: Steffen Rochel [mailto:steffenroc...@gmail.com] > Sent: Friday, November 30, 2018 12:48 PM > To: dev@mxnet.incubator.apache.org > Subject: Re: v1.4.0 status 11/29 > > Hi Tao - thanks for fixing the crash. Please create PR on v1.4.x branch > with [v1.4.x] in title and add me to the PR. > Steffen > > On Thu, Nov 29, 2018 at 8:44 PM Lv, Tao A wrote: > > > Hi Steffen, I would like to have > > https://github.com/apache/incubator-mxnet/pull/13433 into the coming > > 1.4.0 release. It fixed a crash of deconvolution with certain input > > size for MKL-DNN backend. This PR is well reviewed and already merged > > into the master branch. New test case is also included there. > > > > Please find the corresponding issue here: > > https://github.com/apache/incubator-mxnet/issues/13421 . > > > > Thanks, > > -Tao > > > > -Original Message- > > From: Steffen Rochel [mailto:steffenroc...@gmail.com] > > Sent: Friday, November 30, 2018 12:05 PM > > To: dev@mxnet.incubator.apache.org > > Subject: v1.4.0 status 11/29 > > > > Dear MXNet community - > > I would like to provide update on v1.4.0 status, details will be > > tracked here < > > https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incu > > bating%29+1.4.0+Release+Plan+and+Status > > > > > . > > > > 1. Sergey created v1.4.x branch > > 2. As expected, additional requests have been made for inclusion in > > v1.4.0 release. Critical PR are tracked here < > > https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incu > > bating%29+1.4.0+Release+Plan+and+Status#ApacheMXNet(incubating)1.4.0Re > > leasePlanandStatus-OpenPRstotrack > > > > > . > > 3. PR to update README.md is blocked by flaky test failures, > > retriggered check. > > 4. PR to upgrade version on master to v1.5.0 has been submitted. > > 5. CI is setup and first run passed. > > > > Note: if you want to add selected fixes or enhancements, please reply > > to this email. Please provide justification, add me as approver to the > > v1.4.x PR and make sure your changes have tests included in PR and get > > properly reviewed. > > > > Regards, > > Steffen > > >
MKLDNN dynamically linked
Created new thread for this as my email were not sending through my work email. Original thread can be found here ( https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=1M:dynamically) There seems to be an issue linking static libraries (MKLDNN) on windows as not all VS compilers support statically linking ( https://stackoverflow.com/questions/18901128/link-static-library-using-cmake ) PR can be tracked here ( https://github.com/apache/incubator-mxnet/pull/13197). Jenkins fails on windows build. There are two routes I see here (both non-ideal): 1. Keep mkldnn as a dynamically linked library. This will cause issues, especially since the mkldnn version has been incremented to 0.17 and soon to be 0.17.1. 2. Change build file such that mkldnn is statically linked in linux/mac but remains dynamically linked on windows. This will complicate our build files (cmakelistfile and makefile) but it may be easier to resolve mkldnn issues on mac/linux since we'll know what version of mkldnn they are using.
Adding AMD CPU to CI
What are people's thoughts on having AMD machines tested on the CI? AMD machines are now available on AWS. Best, Alex
MKLDNN dynamically linked
Currently in mxnet-mkl the libmxnet.so is dynamically linked to to libmkldnn.so.0. This is known to cause some issues if the wrong version of mkldnn is linked. Can we static link this file instead? Alex
Remove MKLML as dependency
On our build from source page we have a list of blas libraries that are recommended: https://mxnet.incubator.apache.org/install/build_from_source.html MKL-DNN MKL MKLML Apple Accelerate OpenBlas MKLML is a subset of MKL (https://github.com/intel/mkl-dnn/issues/102) and therefore MKLML users can just use MKL instead. Does anyone see an issue with me removing this? It would simplify out doc page and build file. Alex
multiple installation guides?
Why do we have two sets of installation guides? http://mxnet.incubator.apache.org/test/get_started/install.html https://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU The /test domain is also not secure. If this is not suppose to be public we should remove this as it is confusing.
Re: Make cmake default
Just realized that the email lists strips aways all hyperlinks. Attached is a copy of my previous email with links pasted in. What are peoples' thought on requiring cmake when building from source? Currently we have to maintain two independent build files (CMakeLists and Makefile) which makes it more difficult to develop (each are 600+ lines). Also, our current build system (in Makefile) requires that 3rdparty dependencies have binaries present (or a Makefile to generate binaries) in the repo, which is not always the case. Generating a makefile with cmake will make our Makefile very simple like PyTorch'sMakefile (20 lines of code - https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not all 3rdparty dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake (https://github.com/apache/incubator-mxnet/blob/master/prepare_mkldnn.sh#L96) to generate binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is OFF by default). If we encounter any library in the future that requires us to generate artifacts with cmake, it would be better to make the switch now. Lastly, we already require cmake as a dependency forwindows' developers (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot%202018-06-01%2013.43.08.png?dl=0) so this would only affect linux / mac developers who do not have cmake already. I currently have a pendingPR (https://github.com/apache/incubator-mxnet/pull/8/) that depends on this change. The library does not have a Makefile or binaries present. Unlike mkldnn, we would want this library included by default so I cannot generate artifacts with cmake. The alternative would be to strip out only the relevant parts of the code we need from the library. I did this in a previous version of myPR (https://github.com/apache/incubator-mxnet/compare/dfdfd1ad15de8bb1b899effb0860a4e834093cfc...a4267eb80488804a7f74ff01f5627c47dd46bd78) but it is incredible messy. Please let me know your thoughts. Best, Alex On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: What are peoples' thought on requiring cmake when building from source? Currently we have to maintain two independent build files (CMakeLists and Makefile) which makes it more difficult to develop (each are 600+ lines). Also, our current build system (in Makefile) requires that 3rdparty dependencies have binaries present (or a Makefile to generate binaries) in the repo, which is not always the case. Generating a makefile with cmake will make our Makefile very simple like PyTorch's Makefile (20 lines of code). Also, not all 3rdparty dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to generate binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is OFF by default). If we encounter any library in the future that requires us to generate artifacts with cmake, it would be better to make the switch now. Lastly, we already require cmake as a dependency for windows' developers so this would only affect linux / mac developers who do not have cmake already. I currently have a pending PR that depends on this change. The library does not have a Makefile or binaries present. Unlike mkldnn, we would want this library included by default so I cannot generate artifacts with cmake. The alternative would be to strip out only the relevant parts of the code we need from the library. I did this in a previous version of my PR but it is incredible messy. Please let me know your thoughts. Best, Alex
Make cmake default
What are peoples' thought on requiring cmake when building from source? Currently we have to maintain two independent build files (CMakeLists and Makefile) which makes it more difficult to develop (each are 600+ lines). Also, our current build system (in Makefile) requires that 3rdparty dependencies have binaries present (or a Makefile to generate binaries) in the repo, which is not always the case. Generating a makefile with cmake will make our Makefile very simple like PyTorch's Makefile (20 lines of code). Also, not all 3rdparty dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to generate binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is OFF by default). If we encounter any library in the future that requires us to generate artifacts with cmake, it would be better to make the switch now. Lastly, we already require cmake as a dependency for windows' developers so this would only affect linux / mac developers who do not have cmake already. I currently have a pending PR that depends on this change. The library does not have a Makefile or binaries present. Unlike mkldnn, we would want this library included by default so I cannot generate artifacts with cmake. The alternative would be to strip out only the relevant parts of the code we need from the library. I did this in a previous version of my PR but it is incredible messy. Please let me know your thoughts. Best, Alex
Permission to delete tasks on MXNET Jira
Hello, I recently created a few tasks (Task MXNET-461 to MXNET-469) in the MXNet Jira page ( https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=211=MXNET). It was intended to be created as a subtask under MXNET-425. I do not have permission to change the status of these tasks or to delete them. Could someone convert these tasks to subtasks or delete them? Best, Alex
Slack Channel
I would like to join the mxnet slack channel. My email address is aza...@gmail.com. Alex
