Re: [DISCUSS] Make MXNet deploy it's own distribution
Hi, We've started working on something along these lines as part of the CD pipeline framework. The idea is to compile and test the libmxnet.so (both statically and dynamically linked) for the different variants (cpu, gpu, mkl, etc.) then have the different mxnet frontends (python, Julia, scala, etc) just wrap around the library. I've been on long term sick leave and haven't been able to move forward with this, although I have an open PR that kicks off this work: https://github.com/apache/incubator-mxnet/pull/15051 - I welcome everyone to take a look. It's the first of a series of PRs to automate the distribution of the python (pip and docker) packages. Instead of using maven, we have opted to use S3. But this decision can be revisited. We also want to distribute what we termed "runtime" docker images. Docker images containing the dynamically linked mxnet library and all of the runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime). This could facilitate the packaging and distribution of docker images for the different frontends. Cheers, Per On Wed., 3 Jul. 2019, 8:47 am Qing Lan, wrote: > In that case, the answer is yes. The Scala package will be published in > one version with a variaty of backend package choices. User can easily > attach and detach different MXNet versions. However, the Scala package > cannot run without a backend. > > Another key advantage of this design will be a broader support on > different implementations such as Java Cpp. User will be able to implement > their customized MXNet frontend to use the native library. > > Thanks, > Qing > > > From: Sheng Zha > Sent: Tuesday, July 2, 2019 22:14 > To: dev@mxnet.incubator.apache.org > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution > > Does it mean that the scala binding of mxnet will be an independent > package that doesn’t directly depend on the native package, and user > projects need to declare dependency on both the scala binding and one of > the native packages? > > -sz > > > On Jul 2, 2019, at 5:50 PM, Frank Liu wrote: > > > > Currently, MXNet were built along with different language bindings such > as > > Scala. > > > > The libmxnet.so files are bundled within scala jar package. > > > > It would be nice to distribute libmxnet.so library independently in > maven, > > and scala package can choose which native library to use. > > > > Here is the design document on cwiki: > > > https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution > > > > Thanks, > > > > Frank >
Re: [DISCUSS] Make MXNet deploy it's own distribution
>From the Clojure package perspective, since it is compatible with maven, this approach will work fine. It would also make it easier for developers to build on top of MXNet and share their libraries. - Carin On Wed, Jul 3, 2019 at 3:45 AM Per da Silva wrote: > Hi, > > We've started working on something along these lines as part of the CD > pipeline framework. The idea is to compile and test the libmxnet.so (both > statically and dynamically linked) for the different variants (cpu, gpu, > mkl, etc.) then have the different mxnet frontends (python, Julia, scala, > etc) just wrap around the library. > > I've been on long term sick leave and haven't been able to move forward > with this, although I have an open PR that kicks off this work: > https://github.com/apache/incubator-mxnet/pull/15051 - I welcome everyone > to take a look. It's the first of a series of PRs to automate the > distribution of the python (pip and docker) packages. Instead of using > maven, we have opted to use S3. But this decision can be revisited. > > We also want to distribute what we termed "runtime" docker images. Docker > images containing the dynamically linked mxnet library and all of the > runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime). > This could facilitate the packaging and distribution of docker images for > the different frontends. > > Cheers, > > Per > > On Wed., 3 Jul. 2019, 8:47 am Qing Lan, wrote: > > > In that case, the answer is yes. The Scala package will be published in > > one version with a variaty of backend package choices. User can easily > > attach and detach different MXNet versions. However, the Scala package > > cannot run without a backend. > > > > Another key advantage of this design will be a broader support on > > different implementations such as Java Cpp. User will be able to > implement > > their customized MXNet frontend to use the native library. > > > > Thanks, > > Qing > > > > > > From: Sheng Zha > > Sent: Tuesday, July 2, 2019 22:14 > > To: dev@mxnet.incubator.apache.org > > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution > > > > Does it mean that the scala binding of mxnet will be an independent > > package that doesn’t directly depend on the native package, and user > > projects need to declare dependency on both the scala binding and one of > > the native packages? > > > > -sz > > > > > On Jul 2, 2019, at 5:50 PM, Frank Liu wrote: > > > > > > Currently, MXNet were built along with different language bindings such > > as > > > Scala. > > > > > > The libmxnet.so files are bundled within scala jar package. > > > > > > It would be nice to distribute libmxnet.so library independently in > > maven, > > > and scala package can choose which native library to use. > > > > > > Here is the design document on cwiki: > > > > > > https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution > > > > > > Thanks, > > > > > > Frank > > >
Re: [DISCUSS] Make MXNet deploy it's own distribution
Will this be another repo under Apache repo? Is tensorflow java package in a separate repo? On Wed, Jul 3, 2019 at 12:46 AM Per da Silva wrote: > Hi, > > We've started working on something along these lines as part of the CD > pipeline framework. The idea is to compile and test the libmxnet.so (both > statically and dynamically linked) for the different variants (cpu, gpu, > mkl, etc.) then have the different mxnet frontends (python, Julia, scala, > etc) just wrap around the library. > > I've been on long term sick leave and haven't been able to move forward > with this, although I have an open PR that kicks off this work: > https://github.com/apache/incubator-mxnet/pull/15051 - I welcome everyone > to take a look. It's the first of a series of PRs to automate the > distribution of the python (pip and docker) packages. Instead of using > maven, we have opted to use S3. But this decision can be revisited. > > We also want to distribute what we termed "runtime" docker images. Docker > images containing the dynamically linked mxnet library and all of the > runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime). > This could facilitate the packaging and distribution of docker images for > the different frontends. > > Cheers, > > Per > > On Wed., 3 Jul. 2019, 8:47 am Qing Lan, wrote: > > > In that case, the answer is yes. The Scala package will be published in > > one version with a variaty of backend package choices. User can easily > > attach and detach different MXNet versions. However, the Scala package > > cannot run without a backend. > > > > Another key advantage of this design will be a broader support on > > different implementations such as Java Cpp. User will be able to > implement > > their customized MXNet frontend to use the native library. > > > > Thanks, > > Qing > > > > > > From: Sheng Zha > > Sent: Tuesday, July 2, 2019 22:14 > > To: dev@mxnet.incubator.apache.org > > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution > > > > Does it mean that the scala binding of mxnet will be an independent > > package that doesn’t directly depend on the native package, and user > > projects need to declare dependency on both the scala binding and one of > > the native packages? > > > > -sz > > > > > On Jul 2, 2019, at 5:50 PM, Frank Liu wrote: > > > > > > Currently, MXNet were built along with different language bindings such > > as > > > Scala. > > > > > > The libmxnet.so files are bundled within scala jar package. > > > > > > It would be nice to distribute libmxnet.so library independently in > > maven, > > > and scala package can choose which native library to use. > > > > > > Here is the design document on cwiki: > > > > > > https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution > > > > > > Thanks, > > > > > > Frank > > >
PR Merged: Custom Operator Profiling Enhancement
Dear MXNet Community, A couple of weeks ago I sent out my custom operator profiling enhancement project RFC (https://github.com/apache/incubator-mxnet/issues/15241) to the community and got positive feedbacks, and now, the PR ( https://github.com/apache/incubator-mxnet/pull/15210) has been merged. A new section on profiling custom operators has also been added to the profiler tutorial here: https://mxnet.incubator.apache.org/versions/master/tutorials/python/profiler.html#profiling-custom-operators. With that said, here I will have a brief introduction to the changes: Before, MXNet allowed user-defined custom operators, but their profiling was not well supported. More specifically, the custom operator events as we see in the dump file were way longer than the actual execution time of the operators. Also, custom operators consist of pure python code and NDArray operators (“sub-operators”), but at a particular point in a custom operator event, we were not able to tell which ones were executing. To allow for a more informative custom operator profiling, my project helps break a single custom operator call into several events: now, we have individual events for both the “pure python” code, namely the forward() and backward() functions, and the “sub-operators” , which are the NDArray operators we call within forward() and backward() of the custom operator. All the new, fine-grained events will fall under a new domain/category called “Custom Operator”. Also, each event there will have a prefix in its name, which is the name we give to the custom operator. Below is a sample dump file (opened in chome://tracing): [image: /var/folders/fb/wknbw2r95zs5vkwrz9r80bzjsgk_ng/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/cidimage001.png@01D52DA3.0A2F7860] Note that: we need to make sure “profile_imperative” is set to True even when we are using custom operators in symbolic mode. The reason is that within custom operators, even in symbolic mode, sub-operators (and pure python code) are still called imperatively. Should there be any issue using this new feature, please feel free to tag me. Additionally, any feedback is welcome! Thanks, Zhaoqi
Re: [DISCUSS] Make MXNet deploy it's own distribution
Nice! +1 To this approach, seems well thought. Thanks for including Android and linux-arm. Does Android and linux-arm use a different classifier? On Wed, Jul 3, 2019 at 6:46 AM Chris Olivier wrote: > > Will this be another repo under Apache repo? Is tensorflow java package in > a separate repo? > > On Wed, Jul 3, 2019 at 12:46 AM Per da Silva wrote: > > > Hi, > > > > We've started working on something along these lines as part of the CD > > pipeline framework. The idea is to compile and test the libmxnet.so (both > > statically and dynamically linked) for the different variants (cpu, gpu, > > mkl, etc.) then have the different mxnet frontends (python, Julia, scala, > > etc) just wrap around the library. > > > > I've been on long term sick leave and haven't been able to move forward > > with this, although I have an open PR that kicks off this work: > > https://github.com/apache/incubator-mxnet/pull/15051 - I welcome everyone > > to take a look. It's the first of a series of PRs to automate the > > distribution of the python (pip and docker) packages. Instead of using > > maven, we have opted to use S3. But this decision can be revisited. > > > > We also want to distribute what we termed "runtime" docker images. Docker > > images containing the dynamically linked mxnet library and all of the > > runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime). > > This could facilitate the packaging and distribution of docker images for > > the different frontends. > > > > Cheers, > > > > Per > > > > On Wed., 3 Jul. 2019, 8:47 am Qing Lan, wrote: > > > > > In that case, the answer is yes. The Scala package will be published in > > > one version with a variaty of backend package choices. User can easily > > > attach and detach different MXNet versions. However, the Scala package > > > cannot run without a backend. > > > > > > Another key advantage of this design will be a broader support on > > > different implementations such as Java Cpp. User will be able to > > implement > > > their customized MXNet frontend to use the native library. > > > > > > Thanks, > > > Qing > > > > > > > > > From: Sheng Zha > > > Sent: Tuesday, July 2, 2019 22:14 > > > To: dev@mxnet.incubator.apache.org > > > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution > > > > > > Does it mean that the scala binding of mxnet will be an independent > > > package that doesn’t directly depend on the native package, and user > > > projects need to declare dependency on both the scala binding and one of > > > the native packages? > > > > > > -sz > > > > > > > On Jul 2, 2019, at 5:50 PM, Frank Liu wrote: > > > > > > > > Currently, MXNet were built along with different language bindings such > > > as > > > > Scala. > > > > > > > > The libmxnet.so files are bundled within scala jar package. > > > > > > > > It would be nice to distribute libmxnet.so library independently in > > > maven, > > > > and scala package can choose which native library to use. > > > > > > > > Here is the design document on cwiki: > > > > > > > > > https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution > > > > > > > > Thanks, > > > > > > > > Frank > > > > >
Re: [DISCUSS] Make MXNet deploy it's own distribution
maven packages are crucial to JVM based language. This proposal can definitely benefit from your PR. Without your PR, maven publish can not be automated. It would be nice to automate maven publish as party of your CD pipeline. On Wed, Jul 3, 2019 at 12:45 AM Per da Silva wrote: > Hi, > > We've started working on something along these lines as part of the CD > pipeline framework. The idea is to compile and test the libmxnet.so (both > statically and dynamically linked) for the different variants (cpu, gpu, > mkl, etc.) then have the different mxnet frontends (python, Julia, scala, > etc) just wrap around the library. > > I've been on long term sick leave and haven't been able to move forward > with this, although I have an open PR that kicks off this work: > https://github.com/apache/incubator-mxnet/pull/15051 - I welcome everyone > to take a look. It's the first of a series of PRs to automate the > distribution of the python (pip and docker) packages. Instead of using > maven, we have opted to use S3. But this decision can be revisited. > > We also want to distribute what we termed "runtime" docker images. Docker > images containing the dynamically linked mxnet library and all of the > runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime). > This could facilitate the packaging and distribution of docker images for > the different frontends. > > Cheers, > > Per > > On Wed., 3 Jul. 2019, 8:47 am Qing Lan, wrote: > > > In that case, the answer is yes. The Scala package will be published in > > one version with a variaty of backend package choices. User can easily > > attach and detach different MXNet versions. However, the Scala package > > cannot run without a backend. > > > > Another key advantage of this design will be a broader support on > > different implementations such as Java Cpp. User will be able to > implement > > their customized MXNet frontend to use the native library. > > > > Thanks, > > Qing > > > > > > From: Sheng Zha > > Sent: Tuesday, July 2, 2019 22:14 > > To: dev@mxnet.incubator.apache.org > > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution > > > > Does it mean that the scala binding of mxnet will be an independent > > package that doesn’t directly depend on the native package, and user > > projects need to declare dependency on both the scala binding and one of > > the native packages? > > > > -sz > > > > > On Jul 2, 2019, at 5:50 PM, Frank Liu wrote: > > > > > > Currently, MXNet were built along with different language bindings such > > as > > > Scala. > > > > > > The libmxnet.so files are bundled within scala jar package. > > > > > > It would be nice to distribute libmxnet.so library independently in > > maven, > > > and scala package can choose which native library to use. > > > > > > Here is the design document on cwiki: > > > > > > https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution > > > > > > Thanks, > > > > > > Frank > > >
Re: [DISCUSS] Make MXNet deploy it's own distribution
No, This just a CD pipeline that publish a jar files contains libmxnet.so to maven central. We are publishing Scala package to maven central already. The issue with current Scala maven package is not flexible to developer who want's switch different version of libmxnet.so file. With this proposal, developer can easily choose different libmxnet.so file by auto detect the os type. On Wed, Jul 3, 2019 at 6:46 AM Chris Olivier wrote: > Will this be another repo under Apache repo? Is tensorflow java package in > a separate repo? > > On Wed, Jul 3, 2019 at 12:46 AM Per da Silva wrote: > > > Hi, > > > > We've started working on something along these lines as part of the CD > > pipeline framework. The idea is to compile and test the libmxnet.so > (both > > statically and dynamically linked) for the different variants (cpu, gpu, > > mkl, etc.) then have the different mxnet frontends (python, Julia, scala, > > etc) just wrap around the library. > > > > I've been on long term sick leave and haven't been able to move forward > > with this, although I have an open PR that kicks off this work: > > https://github.com/apache/incubator-mxnet/pull/15051 - I welcome > everyone > > to take a look. It's the first of a series of PRs to automate the > > distribution of the python (pip and docker) packages. Instead of using > > maven, we have opted to use S3. But this decision can be revisited. > > > > We also want to distribute what we termed "runtime" docker images. Docker > > images containing the dynamically linked mxnet library and all of the > > runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime). > > This could facilitate the packaging and distribution of docker images for > > the different frontends. > > > > Cheers, > > > > Per > > > > On Wed., 3 Jul. 2019, 8:47 am Qing Lan, wrote: > > > > > In that case, the answer is yes. The Scala package will be published in > > > one version with a variaty of backend package choices. User can easily > > > attach and detach different MXNet versions. However, the Scala package > > > cannot run without a backend. > > > > > > Another key advantage of this design will be a broader support on > > > different implementations such as Java Cpp. User will be able to > > implement > > > their customized MXNet frontend to use the native library. > > > > > > Thanks, > > > Qing > > > > > > > > > From: Sheng Zha > > > Sent: Tuesday, July 2, 2019 22:14 > > > To: dev@mxnet.incubator.apache.org > > > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution > > > > > > Does it mean that the scala binding of mxnet will be an independent > > > package that doesn’t directly depend on the native package, and user > > > projects need to declare dependency on both the scala binding and one > of > > > the native packages? > > > > > > -sz > > > > > > > On Jul 2, 2019, at 5:50 PM, Frank Liu > wrote: > > > > > > > > Currently, MXNet were built along with different language bindings > such > > > as > > > > Scala. > > > > > > > > The libmxnet.so files are bundled within scala jar package. > > > > > > > > It would be nice to distribute libmxnet.so library independently in > > > maven, > > > > and scala package can choose which native library to use. > > > > > > > > Here is the design document on cwiki: > > > > > > > > > > https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution > > > > > > > > Thanks, > > > > > > > > Frank > > > > > >
demise of dmlc.ml domain & new Julia docs hosting
Hi dev@, In case you missed the issues with the dmlc.ml domain, it was let go or sniped and now goes to a malware site. [1] Several assets like models and the Julia documentation were hosted there. I made some progress getting the Julia docs generated as part of the regular website build flow. [2] It'll work as long as you have Julia installed and configured with MXNet. I don't imagine you can use it to build the website natively on your mac or windows box at this point because all of the CI and related instructions appear to be only for Ubuntu. That being said, I added an option to dev_menu.py so you can build the Julia docs with docker on whatever host you're on. I tried to bring in the markdown files and have the website theme applied to them. Many things were then broken - in large part due to some bugs in the website code related to post processing and injection of dom elements. This would require a rewrite of the Julia docs to workaround the existing website bugs. Rather than do this, I just took the Julia site output, which has its own look and feel and nested in Julia's API directory. This is much like how the scala docs and the java docs are - using their own look and feel as a micro-site. I feel that this is the better approach for now. The PR for the Julia docs is here: https://github.com/apache/incubator-mxnet/pull/15454 Ivy and I created several new issues to cover the broken links that will need fixing. Models that need to be recovered or recreated and uploaded to a new location. I have an s3 bucket that I've been using for some public assets like this, but I can't make progress on fixing those links when the models just don't exist. And I don't have the bandwidth to regenerate the model zoo and validate the models. Any thoughts or suggestions are appreciated. Happy 4th of July! [1] https://github.com/apache/incubator-mxnet/issues/15410 [2] https://github.com/apache/incubator-mxnet/pull/15454
Re: PR Merged: Custom Operator Profiling Enhancement
Thank you Zhaoqi for all your contributions to MXNet community. This feature of capturing detailed information for a custom operator in MXNet profiler output will be very helpful for lot of MXNet users who has custom operators and want to know more about the bottlenecks. Best, Sandeep On Wed, Jul 3, 2019, 3:01 PM Zhu Zhaoqi wrote: > Sorry about the image. I re-uploaded it: > [image: Screen Shot 2019-06-11 at 1.15.48 PM.png] > > Zhu Zhaoqi 于2019年7月3日周三 下午2:58写道： > >> Dear MXNet Community, >> >> >> >> A couple of weeks ago I sent out my custom operator profiling enhancement >> project RFC (https://github.com/apache/incubator-mxnet/issues/15241) to >> the community and got positive feedbacks, and now, the PR ( >> https://github.com/apache/incubator-mxnet/pull/15210) has been merged. A >> new section on profiling custom operators has also been added to the >> profiler tutorial here: >> https://mxnet.incubator.apache.org/versions/master/tutorials/python/profiler.html#profiling-custom-operators. >> With that said, here I will have a brief introduction to the changes: >> >> >> >> Before, MXNet allowed user-defined custom operators, but their profiling >> was not well supported. More specifically, the custom operator events as we >> see in the dump file were way longer than the actual execution time of the >> operators. Also, custom operators consist of pure python code and NDArray >> operators (“sub-operators”), but at a particular point in a custom operator >> event, we were not able to tell which ones were executing. >> >> >> >> To allow for a more informative custom operator profiling, my project >> helps break a single custom operator call into several events: now, we have >> individual events for both the “pure python” code, namely the forward() and >> backward() functions, and the “sub-operators” , which are the NDArray >> operators we call within forward() and backward() of the custom operator. >> >> >> >> All the new, fine-grained events will fall under a new domain/category >> called “Custom Operator”. Also, each event there will have a prefix in its >> name, which is the name we give to the custom operator. Below is a sample >> dump file (opened in chome://tracing): >> >> >> >> [image: >> /var/folders/fb/wknbw2r95zs5vkwrz9r80bzjsgk_ng/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/cidimage001.png@01D52DA3.0A2F7860] >> >> >> >> Note that: we need to make sure “profile_imperative” is set to True even >> when we are using custom operators in symbolic mode. The reason is that >> within custom operators, even in symbolic mode, sub-operators (and pure >> python code) are still called imperatively. >> >> >> >> Should there be any issue using this new feature, please feel free to tag >> me. Additionally, any feedback is welcome! >> >> >> >> Thanks, >> >> Zhaoqi >> >> >> >
