Lightweight, Portable, Flexible Distributed/Mobile Deep Learning with Dynamic, Mutation-aware Dataflow Dep Scheduler; for Python, R, Julia, Scala, Go, Javascript and more


banner

Apache MXNet (incubating) for Deep Learning

GitHub release (latest SemVer) GitHub stars GitHub forks GitHub contributors GitHub issues good first issue GitHub pull requests by-label GitHub license Twitter Twitter Follow

Apache MXNet is a deep learning framework designed for both efficiency and flexibility. It allows you to mix symbolic and imperative programming to maximize efficiency and productivity. At its core, MXNet contains a dynamic dependency scheduler that automatically parallelizes both symbolic and imperative operations on the fly. A graph optimization layer on top of that makes symbolic execution fast and memory efficient. MXNet is portable and lightweight, scalable to many GPUs and machines.

MXNet is more than a deep learning project. It is a community on a mission of democratizing AI. It is a collection of blue prints and guidelines for building deep learning systems, and interesting insights of DL systems for hackers.

Licensed under an Apache-2.0 license.

Branch Build Status
master CentOS CPU Build Status CentOS GPU Build Status Clang Build Status
Edge Build Status Miscellaneous Build Status Sanity Build Status
Unix CPU Build Status Unix GPU Build Status Website Build Status
Windows CPU Build Status Windows GPU Build Status Documentation Status
v1.x CentOS CPU Build Status CentOS GPU Build Status Clang Build Status
Edge Build Status Miscellaneous Build Status Sanity Build Status
Unix CPU Build Status Unix GPU Build Status Website Build Status
Windows CPU Build Status Windows GPU Build Status Documentation Status

Features

  • NumPy-like programming interface, and is integrated with the new, easy-to-use Gluon 2.0 interface. NumPy users can easily adopt MXNet and start in deep learning.
  • Automatic hybridization provides imperative programming with the performance of traditional symbolic programming.
  • Lightweight, memory-efficient, and portable to smart devices through native cross-compilation support on ARM, and through ecosystem projects such as TVM, TensorRT, OpenVINO.
  • Scales up to multi GPUs and distributed setting with auto parallelism through ps-lite, Horovod, and BytePS.
  • Extensible backend that supports full customization, allowing integration with custom accelerator libraries and in-house hardware without the need to maintain a fork.
  • Support for Python, Java, C++, R, Scala, Clojure, Go, Javascript, Perl, and Julia
  • Cloud-friendly and directly compatible with AWS and Azure.

Contents

What's New

Ecosystem News

Stay Connected

Channel Purpose
Follow MXNet Development on Github See what's going on in the MXNet project.
MXNet Confluence Wiki for Developers MXNet developer wiki for information related to project development, maintained by contributors and developers. To request write access, send an email to send request to the dev list .
[email protected] mailing list The "dev list". Discussions about the development of MXNet. To subscribe, send an email to [email protected] .
discuss.mxnet.io Asking & answering MXNet usage questions.
Apache Slack #mxnet Channel Connect with MXNet and other Apache developers. To join the MXNet slack channel send request to the dev list .
Follow MXNet on Social Media Get updates about new features and events.

Social Media

Keep connected with the latest MXNet news and updates.

Apache MXNet on Twitter

Contributor and user blogs about MXNet

reddit Discuss MXNet on r/mxnet

Apache MXNet YouTube channel

Apache MXNet on LinkedIn

History

MXNet emerged from a collaboration by the authors of cxxnet, minerva, and purine2. The project reflects what we have learned from the past projects. MXNet combines aspects of each of these projects to achieve flexibility, speed, and memory efficiency.

Tianqi Chen, Mu Li, Yutian Li, Min Lin, Naiyan Wang, Minjie Wang, Tianjun Xiao, Bing Xu, Chiyuan Zhang, and Zheng Zhang. MXNet: A Flexible and Efficient Machine Learning Library for Heterogeneous Distributed Systems. In Neural Information Processing Systems, Workshop on Machine Learning Systems, 2015

Comments
  • Windows GPU accuracy extremely bad

    Windows GPU accuracy extremely bad

    Hey i'm quite new to mxnet, I followed the installation instructions and succeeded in installing it on windows 8.1 64 bit, I then ran the train_mnist.py --network lenet without a problem, quite slow but the accuracy at the end is good at around 99.2, but when I run it as --network lenet --gpus 0 to use my gpu its definitely a lot faster but the accuracy never gets above 10% which is terrible, there must be something wrong theoretically it should be the same accuracy right? I installed cuda 7.5 and also extracted cuddn v3 just as indicated, everything runs without a problem except the accuracy is terrible, i'm running on a laptop with a nvidia 660m graphics card, it has compute capability 3.0.

    After running the file I get Train-accuracy=0.098825

  • [Discussion] Sharing Operators between DL Frameworks

    [Discussion] Sharing Operators between DL Frameworks

    See This Link for discussion repo

    This discussion started from https://github.com/dmlc/minpy/issues/129, with @soumith THC is a tensor library that backs torch. I open this issue in MXNet repo so more developers can see it.

    First of all, it is possible reuse operator libraries between frameworks, for example

    • Support for THC and Torch Module was done in Torch Plugin, with interfacing to torch's lua library.
    • MXNet supports reuse operators from caffe

    It is always interesting to see interchangeability happen. For example, schedule pytorch operations in mxnet's async engine, or run mxnet's declarative API to directly share data with pytorch's array.

    However, there is some engineering obstacles in doing so, which I would like to explain what these obstacles are, and hopefully this can motivate the community to move forward, and make this easier.

    Coupled Operator Data Structure Components

    An operator can mean many things, here are some basic components on what the operators are:

    • Data structure that holds(shape) pointers to the array
    • Possible memory allocator to handle run-time memory allocation
    • Resource handles, if external resources is needed
    • Scheduling related objects if array support synchronize execution

    Why such coupling prevents reuse? There are two reasons

    • Many systems have their own memory allocator and ways of resource handling code.
    • While having memory allocator enables runtime memory allocations, sometimes memory allocation is not preferred at all(e.g. BLAS calls where all memory are pre-allocated)

    To resolve this problem, an operator library design should enable operators that accept user managed memory resources, when possible, not introduce allocator or resource management, but give hints to the user(CuDNN's workspace requirement eliminates the need to internal memory allocator).

    From this point of view, CuDNN an cuBLAS are good examples. THC is nice, but still encapsulate memory allocator(which is needed sometimes for dynamic operators).

    Lack of Unified Operator Interface

    The second obstacle is mainly lack of common operator interface. This is a problem of CUDNN and THC that prevents reusing. Take CuDNN for example, each CuDNN API is a C function, with its own interface, to adopt the operator, there need to be one(or multiple) adapting function per operator.

    Consider instead, if there is an unified operator interface(the following is a mock design), where each TBlob is a reference to the data fields and shape, and every function gets registered to the registry with their name

    using FCompute = std::function<void (
       array_view<TBlob> ins, array_view<TBlob> outs, map kwargs, stream stream)>
    

    Then it only takes one function to extract, and reuse all operators and automatically expose them to front end. In MXNet, it even directly generates the symbolic counterpart from the same imperative operator, if gradient is provided.

    Problem of One Unified Operator Interface

    There is always a flip side of the coin. Assume that we go with a unified operator interface. As a matter of fact, that is what MXNet, TensorFlow and Caffe have done. The problem now becomes what the interface should look like? One trap that framework designer always falls into is that we need one interface that rules them all.

    Since one interface rules them all, we want to support all possible operators, what about the ones that need runtime memory allocations? Maybe add memory allocator to it, what about the ones that is asynchronize? In the end, the interface have to include memory-allocator, scheduling module in some way, and that introduces the "Coupled Operator Data Structure Components" problem. The operator interface become deeply coupled with the rest of the framework and not reusable.

    A Better Solution: A Few Unified Interfaces

    Can we get the best of both worlds, having as few data structures and interfaces as possible, while still not introducing coupling to allocator and scheduling as much as possible? I think the answer is yes and we need to jump out from the ideal of one interface that rules all the operators.

    I can categorize the operators roughly in three categories

    • type1: Basic operators: The ones that can do shape inference based on input shape, can take memory pointer, stream and go
    • type2: Basic+ operators: Same as basic operator, but also need to declare some additional resources(workspace)
    • type3: Complicated operators: The ones that requires runtime memory allocator, its output shape depends on content of the data.

    If we design for general operator interface, the answer will usually looks like type3. However, type 1 and 2 dominates 90%+ of the major operators we are using. If we design one operator interfaces for each type, this problem is solved. So that frameworks can pull and interact with each type in their own way. It is much easier to do things like static memory planning if type1 and type2 are explicitly introduced. This is one additional layer of wrapping on top of THC and CuDNN is is lacking so far.

    A registry system like NNVM could come very handy to easily resgister these informations, and get pull out by the libraries.

    The Hope

    I have always hopped that there is a minimum set of operator interface standard in C++, that can be shared across libraries. I think we have a good idea on what the solution looks like. While most system tends to become opague and coupled, I think this kind of transparent way can help evolve the community in a healthy way. This being said, there is always effort to make these happen. This involves a open discussion on what the interfaces should be and commitment from framework builders. I would really love to see this happen, and that is why I spend more than one hour writing this.

    Unfortunately, most frameworks already have kinda of "enough collection of operators", so having a unified operator interface will contribute little to each framework in terms of usability in short term. Naturally this would be given lower priority. That is why commitment is needed to bring this out for longer term benefit

  • [Discussion] MXNet 2.0 Roadmap (was: APIs that might be a good idea to break in 2.0)

    [Discussion] MXNet 2.0 Roadmap (was: APIs that might be a good idea to break in 2.0)

    Let's start a discussion here about the roadmap towards MXNet 2.0. We are looking for:

    • New features that are useful to your research and development.
    • Improvements and patches to existing features.
    • APIs that should be fixed.

    If you have any item that you'd like to propose to have in the roadmap, please do:

    • Create (or locate existing) issue for the item, note the issue number.
    • Comment in this issue: 1) the above issue number, 2) one sentence of what the item is about and why it's useful to you.
    • Indicate whether you'd be willing to help out on the item.

    Given that this would be a major release, we'd have the opportunity to make backward incompatible changes. This would allow us to visit some topics that require large changes such as dropping support for python2, transitioning fully to cmake, making the tensor library numpy-compatible, or even new programming models.


    Now that we decided to follow semantic versioning for releases, it would be a good idea to coordinate features and API changes to make the best use of the next major release. Thus, I propose that we use this issue to track the APIs we'd like to change in the next major version.

    The candidates I've collected so far:

    1. remove legacy ops such as batch-norm v1
    2. reorganizing namespace for utility functions such as download in #9671
    3. transform argument in the constructor of existing vision dataset API.

    Once there are more of such requests, I will try to organize these API-breaking requests better.

  • [FEATURE] Enable dynamic linking with MKL and compiler based OpenMP

    [FEATURE] Enable dynamic linking with MKL and compiler based OpenMP

    OneMKL 2021.3 fixed linking OpenMP while using SDL and MKL_THREADING_LAYER set to GNU.

    Description

    OneMKL 2021.3 fixes the issue described here. Thus, it enables linking with MKL dynamic libraries without having multiple OneMPs in a single process. It is possible due to linking MxNET with oneMKL Single Dynamic Library (SDL) and then setting the appropriate threading layer at run time in a function mkl_threading_layer() (or through environment variable MKL_THREADING_LAYER).

    Connected with: [#19610], [#18255] and [#17794].

    Changes

    1. Add oneMKL 2021.3 to ubuntu docker images.
    2. Enable MKL SDL (MKL_USE_SINGLE_DYNAMIC_LIBRARY) as the default linking when MKL version is grower than 2021.2 and static linking is turned off. (Bug no: MKLD-11109, OneMKL release notes) .
    3. Otherwise, MKL static libraries are taken into account and used to build MxNET library.
    4. Add support of the new oneMKL file structure in the FindBLAS.cmake file (fix comes from the cmake 3.20: #6210 ).

    Comments

    Does using oneMKL 2021.3 as the recommended one should be mentioned in the documentation?

  • [RFC] Build with MKL-DNN (or DNNL)

    [RFC] Build with MKL-DNN (or DNNL)

    From https://github.com/apache/incubator-mxnet/issues/19610:

    Intel MKL-DNN was renamed with DNNL in its v1.1 release. Since then, the MXNet community has been working on the transition to DNNL to leverage the latest features and optimizations from the library. That includes using the string “DNNL” or “dnnl” for future development and communication. We propose to promote the flag “USE_DNNL” since MXNet 2.0 and start deprecating “USE_MKLDNN” at the same time. DNNL source code resides in the 3rdparty/mkldnn folder of the MXNet repository and is released and distributed along with MXNet source code. If one wants to build MXNet with DNNL to accelerate the execution on Intel CPU, she/he needs to enable -DUSE_DNNL=ON in CMake. However, this flag has been set to ON by default for all platforms except edge devices. On the contrary, to disable the DNNL acceleration, one needs to set -DUSE_DNNL=OFF explicitly in the CMake command line or the CMake configuration file. As both MXNet and DNNL are under quick development with different release cadence, we decide to link the DNNL library into MXNet statically to avoid mis-linking in the user's environment. Given this, we need to set DNNL_LIBRARY_TYPE to STATIC when building DNNL. Some additional flags to build DNNL:

    DNNl_CPU_RUNTIME: Need set it to SEQ explicitly when USE_OPENMP=OFF; DNNL_ARCH_OPT_FLAGS: Need pass compiler options to this build flag in string. Eg. -march or -mtune for GCC. MKLDNN_BUILD_TESTS and MKLDNN_BUILD_EXAMPLES: We set these two flags to OFF to speed up the compilation. One thing that needs to be taken care of is that the header dnnl_config.h and dnnl_version.h will be generated dynamically during compilation and will be copied to the installation destination when calling make install. That means these two headers are not distributed with DNNL source code. For downstream projects which are including these headers need to find them in the installation path rather than the source code path.

    I prepared three commits regarding this point of main RFC:

    1. changing USE_MKLDNN flag name to USE_ONEDNN to make it consistent with actual library name I believe that this commit is complete and if there is such a will can be merged into master.

    2. changing MXNET_USE_MKLDNN* flags names to MXNET_USE_ONEDNN* also for consistency reasons This commit regards changing inner MXNET flag so that it will be consistent with the actual lib name. To avoid creating even bigger mixture of mkldnn/dnnl/onednn acronyms I believe it should be accompanied with another commit changing acronyms used in mxnet function names and comments regarding this particular lib to oneDNN.

    3. changing the 3rdparty/mkldnn folder name to 3rdparty/onednn for consistency.

  • [MXNET-500]Test cases improvement for MKLDNN on Gluon

    [MXNET-500]Test cases improvement for MKLDNN on Gluon

    Description

    This PR is a "follow-up" of previously merged #10764 . In this PR, the followings are covered:

    1. Refine the cases on nn.Conv2D and change the input shape to hit the MKLDNN code path;
    2. Adding more test cases cover other gluon layers, like BN, Dense/FC, Pooling, Deconv etc. from the "MKLDNN-specialty" perspective;
    3. Data coverage cases for some gluon layers, such as Conv2D, BN, Concat etc.

    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 created (except PRs with tiny changes)
    • [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)
    • [ ] 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

    All the changes is reflected by tests/python/mkl/test_mkldnn.py

    Comments

    1. For the correctness check on gluon computation, it follows the design used by tests/python/unittest/test_gluon.py, and therefore, the helper functions defined in tests/python/unitest/common.py is also used.
  • import Julia binding

    import Julia binding

    I imported it via git subtree to keep all git history. About the ci, I added a entry in runtime_function.sh: unittest_ubuntu_cpu_julia06. Please check it in commit b7d9731 .

    See also #8727.

    cc @marcoabreu, @pluskid, @vchuravy

    TODO

    • [x] add license header to .jl file: 63ffca39
    • [ ] add releasing instruction to wiki
    • [ ] Jenkins doc build
  • Port convolutions to cuDNN v8 API

    Port convolutions to cuDNN v8 API

    Description

    This change ports Convolution and Deconvolution operations to cuDNN v8 API. Legacy API support is dropped, as per this RFC: https://github.com/apache/incubator-mxnet/issues/20618.

    The change also includes some cuDNN v8 API general support stuff, to be re-used later when more operations are ported to the v8 API.

    Finally, auto-tuning functionality is moved from cuDNN into MXNet, hence some memory management changes were required.

    Checklist

    Essentials

    • [X] Changes are complete (i.e. I finished coding on this PR)
    • [X] All changes have test coverage
    • [X] Code is well-documented
  • OpenMP Error

    OpenMP Error

    Description

    Compiled MxNet has duplicate OpenMP library link to both libomp and libiomp.

    Error Message

    (Paste the complete error message. Please also include stack trace by setting environment variable DMLC_LOG_STACK_TRACE_DEPTH=10 before running your script.)

    OMP: Error #15: Initializing libiomp5.so, but found libomp.so already initialized.
    OMP: Hint This means that multiple copies of the OpenMP runtime have been linked
    into the program. That is dangerous, since it can degrade performance or cause
    incorrect results. The best thing to do is to ensure that only a single OpenMP
    runtime is linked into the process, e.g. by avoiding static linking of the
    OpenMP runtime in any library. As an unsafe, unsupported, undocumented
    workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to
    allow the program to continue to execute, but that may cause crashes or silently
    produce incorrect results. For more information, please see
    http://www.intel.com/software/products/support/.
    

    To Reproduce

    I have both Intel MKL and MKLDNN library installed on Ubuntu 18.04. Use the following config to compile MxNet will lead the error shown above.

    cmake -DUSE_CUDA=0 -DUSE_CUDNN=0 -DUSE_MKLDNN=1 -DCMAKE_BUILD_TYPE=Release -GNinja ..
    ninja -v
    

    What have you tried to solve it?

    After I deleted 3rdparty/openmp, and recompiled mxnet, this error no longer occurs.

    Environment

    Ubuntu 18.04, installed with Intel MKL and MKLDNN library.

  • [Discussion] 1.5.1 Patch Release

    [Discussion] 1.5.1 Patch Release

    Let's start a discussion here about the known issues with 1.5.0 to put into a patch release.

    Create (or locate existing) issue/pull request for the item, note the issue/pull request number. Comment in this issue: 1) the above issue number, 2) one sentence of what the item is about and why it's important. Indicate whether you'd be willing to help out on the item. Share the ETA if you're driving the item and have an guesstimate on when it will be done.

    cc @apache/mxnet-committers

  • [v0.9.3] Amalgamation for Android broken

    [v0.9.3] Amalgamation for Android broken

    Amalgamation for Android still breaking in the recent release:

    from mxnet_predict0.cc:3:
    [...]/mxnet/mxnet/amalgamation/../dmlc-core/include/dmlc/logging.h:18:22: fatal error: execinfo.h: No such file or directory
     #include <execinfo.h>
                          ^
    compilation terminated.
    make: *** [mxnet_predict0.d] Error 1
    

    Commenting out that #include <execinfo.h> creates the further error:

    In file included from mxnet_predict0.cc:4:0:
    [...]/mxnet/amalgamation/../src/ndarray/ndarray.cc:16:30: fatal error: opencv2/opencv.hpp: No such file or directory
     #include <opencv2/opencv.hpp>
                                  ^
    compilation terminated.
    make: *** [mxnet_predict0.d] Error 1
    

    It looks like the USE_OPENCV = 0 is being ignored?

  • Refactor SupportDNNL functions

    Refactor SupportDNNL functions

    Description

    For any oneDNN primitive use for MXNet operator it is necessary to check if operators' inputs, parameters and sometimes outputs are compatible with primitive's boundaries. Almost every operator had its SupportDNNL function that was checking those conditions. Goal of this PR is to systematize those functions by making universal SupportDNNL<>() function with multiple use cases possible

    Checklist

    Essentials

    • [x] Changes are complete (i.e. I finished coding on this PR)
    • [x] All changes have test coverage
    • [x] Code is well-documented

    Changes

    • [x] Create universal SupportDNNL function
    • [x] Refactor SupportDNNLOp functions using new function
  • [FEATURE] Put every class in training set

    [FEATURE] Put every class in training set

    Description

    To make sure training set image list contains at least one image of each class.Having all images of some class in val set makes a mess doing inference with resulting model (and synset).

    Checklist

    Essentials

    • [x] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
    • [x] Changes are complete (i.e. I finished coding on this PR)
    • [ ] All changes have test coverage
    • [x] Code is well-documented

    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
  • Installation Guide for MXNet RTX 30 Series GPU

    Installation Guide for MXNet RTX 30 Series GPU

    Description

    Hello all, I am new to MXNet, so I am trying to have it installed and run on GPU. I am trying to install mxnet-cu101 to run on an RTX 3060. However, as soon as run the lines below, the code stalls. Nothing happens after that.

    from mxnet import nd, gpu, gluon, autograd from mxnet.gluon import nn from mxnet.gluon.data.vision import datasets, transforms import time

    x = nd.ones((3,4), ctx=gpu())

    Note that if I take out ctx=gpu(), it works just fine.

    x = nd.ones((3,4)) x

    [[1. 1. 1. 1.] [1. 1. 1. 1.] [1. 1. 1. 1.]] <NDArray 3x4 @cpu(0)>

    Also, it seems MXNet recognize there is a GPU

    import mxnet as mx mx.context.num_gpus() 1 from mxnet.runtime import feature_list feature_list() [✔ CUDA, ✔ CUDNN, ✖ NCCL, ✔ CUDA_RTC, ✖ TENSORRT, ✖ CPU_SSE, ✖ CPU_SSE2, ✖ CPU_SSE3, ✖ CPU_SSE4_1, ✖ CPU_SSE4_2, ✖ CPU_SSE4A, ✖ CPU_AVX, ✖ CPU_AVX2, ✔ OPENMP, ✖ SSE, ✖ F16C, ✖ JEMALLOC, ✔ BLAS_OPEN, ✖ BLAS_ATLAS, ✖ BLAS_MKL, ✖ BLAS_APPLE, ✔ LAPACK, ✖ MKLDNN, ✔ OPENCV, ✖ CAFFE, ✖ PROFILER, ✖ DIST_KVSTORE, ✖ CXX14, ✖ INT64_TENSOR_SIZE, ✔ SIGNAL_HANDLER, ✖ DEBUG]

    Question: 1/ What am I doing wrong? 2/ Is there a comprehensive guide on how to install mxnet for 30 series gpu on Windows in conda?

    Below is my specs

    CUDA 10.1 and CuDNN 8.0.5.39 mxnet-cu101 Geforce Game Ready Driver: Version 512.77

    Device name MyPC Processor AMD Ryzen 9 5900X 12-Core Processor 3.70 GHz Installed RAM 32.0 GB System type 64-bit operating system, x64-based processor Pen and touch Pen support

    Edition Windows 11 Pro Version 21H2 Installed on ‎1/‎2/‎2022 OS build 22000.675 Experience Windows Feature Experience Pack 1000.22000.675.0

  • [FEATURE] Refactor SwapAxis operator.

    [FEATURE] Refactor SwapAxis operator.

    Description

    SwapAxis operator was implemented without use of NNVM_REGISTER_OP. Refactoring with new API would enable integrating oneDNN's reorder primitive support which would speed up gpt2 model.

    Checklist

    Essentials

    • [x] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
    • [x] Changes are complete (i.e. I finished coding on this PR)
    • [x] All changes have test coverage

    Changes

    • [x] Refactor SwapAxis operator with NNVM_REGISTER_OP.
  • [v1.9.x] Update year in notice

    [v1.9.x] Update year in notice

    Description

    Update year in notice

    Checklist

    Essentials

    • [ ] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
    • [ ] Changes are complete (i.e. I finished coding on this PR)
    • [ ] All changes have test coverage
    • [ ] Code is well-documented

    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
  • Update year in notice

    Update year in notice

    Description

    Update year in notice

    Checklist

    Essentials

    • [ ] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
    • [ ] Changes are complete (i.e. I finished coding on this PR)
    • [ ] All changes have test coverage
    • [ ] Code is well-documented

    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
Related tags
Lightweight, Portable, Flexible Distributed/Mobile Deep Learning with Dynamic, Mutation-aware Dataflow Dep Scheduler; for Python, R, Julia, Scala, Go, Javascript and more
Lightweight, Portable, Flexible Distributed/Mobile Deep Learning with Dynamic, Mutation-aware Dataflow Dep Scheduler; for Python, R, Julia, Scala, Go, Javascript and more

Apache MXNet (incubating) for Deep Learning Apache MXNet is a deep learning framework designed for both efficiency and flexibility. It allows you to m

Feb 12, 2021
Lightweight, Portable, Flexible Distributed/Mobile Deep Learning with Dynamic, Mutation-aware Dataflow Dep Scheduler; for Python, R, Julia, Scala, Go, Javascript and more
Lightweight, Portable, Flexible Distributed/Mobile Deep Learning with Dynamic, Mutation-aware Dataflow Dep Scheduler; for Python, R, Julia, Scala, Go, Javascript and more

Apache MXNet (incubating) for Deep Learning Master Docs License Apache MXNet (incubating) is a deep learning framework designed for both efficiency an

Dec 23, 2020
Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library, for Python, R, Java, Scala, C++ and more. Runs on single machine, Hadoop, Spark, Dask, Flink and DataFlow
Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library,  for Python, R, Java, Scala, C++ and more. Runs on single machine, Hadoop, Spark, Dask, Flink and DataFlow

eXtreme Gradient Boosting Community | Documentation | Resources | Contributors | Release Notes XGBoost is an optimized distributed gradient boosting l

May 23, 2022
Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library, for Python, R, Java, Scala, C++ and more. Runs on single machine, Hadoop, Spark, Dask, Flink and DataFlow
Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library,  for Python, R, Java, Scala, C++ and more. Runs on single machine, Hadoop, Spark, Dask, Flink and DataFlow

eXtreme Gradient Boosting Community | Documentation | Resources | Contributors | Release Notes XGBoost is an optimized distributed gradient boosting l

Feb 13, 2021
Fuzzing JavaScript Engines with Aspect-preserving Mutation

DIE Repository for "Fuzzing JavaScript Engines with Aspect-preserving Mutation" (in S&P'20). You can check the paper for technical details. Environmen

Apr 14, 2022
Angora is a mutation-based fuzzer. The main goal of Angora is to increase branch coverage by solving path constraints without symbolic execution.

Angora Angora is a mutation-based coverage guided fuzzer. The main goal of Angora is to increase branch coverage by solving path constraints without s

May 14, 2022
MOpt-AFL provided by the paper "MOPT: Optimized Mutation Scheduling for Fuzzers"

MOpt-AFL 1. Description MOpt-AFL is a AFL-based fuzzer that utilizes a customized Particle Swarm Optimization (PSO) algorithm to find the optimal sele

Apr 30, 2022
Bagua is a flexible and performant distributed training algorithm development framework.
Bagua is a flexible and performant distributed training algorithm development framework.

Bagua is a flexible and performant distributed training algorithm development framework.

May 20, 2022
Based on Yolo's low-power, ultra-lightweight universal target detection algorithm, the parameter is only 250k, and the speed of the smart phone mobile terminal can reach ~300fps+
Based on Yolo's low-power, ultra-lightweight universal target detection algorithm, the parameter is only 250k, and the speed of the smart phone mobile terminal can reach ~300fps+

Based on Yolo's low-power, ultra-lightweight universal target detection algorithm, the parameter is only 250k, and the speed of the smart phone mobile terminal can reach ~300fps+

May 17, 2022
Code for Boundary-Aware Segmentation Network for Mobile and Web Applications

BASNet Boundary-Aware Segmentation Network for Mobile and Web Applications This repository contain implementation of BASNet in tensorflow/keras. comme

Sep 27, 2021
Source code of the paper Meta-learning with an Adaptive Task Scheduler.

ATS About Source code of the paper Meta-learning with an Adaptive Task Scheduler. If you find this repository useful in your research, please cite the

Apr 6, 2022
Dynamic View Synthesis from Dynamic Monocular Video

Towards Robust Monocular Depth Estimation: Mixing Datasets for Zero-shot Cross-dataset Transfer This repository contains code to compute depth from a

May 21, 2022
Dynamic View Synthesis from Dynamic Monocular Video
Dynamic View Synthesis from Dynamic Monocular Video

Dynamic View Synthesis from Dynamic Monocular Video Project Website | Video | Paper Dynamic View Synthesis from Dynamic Monocular Video Chen Gao, Ayus

May 13, 2022
Dynamic vae - Dynamic VAE algorithm is used for anomaly detection of battery data
Dynamic vae - Dynamic VAE algorithm is used for anomaly detection of battery data

Dynamic VAE frame Automatic feature extraction can be achieved by probability di

Apr 15, 2022
Image data augmentation scheduler for albumentations transforms

albu_scheduler Scheduler for albumentations transforms based on PyTorch schedulers interface Usage TransformMultiStepScheduler import albumentations a

Aug 4, 2021
DexterRedTool - Dexter's Red Team Tool that creates cronjob/task scheduler to consistently creates users

DexterRedTool Author: Dexter Delandro CSEC 473 - Spring 2022 This tool persisten

Feb 16, 2022
PyTorch Implementation of PortaSpeech: Portable and High-Quality Generative Text-to-Speech
PyTorch Implementation of PortaSpeech: Portable and High-Quality Generative Text-to-Speech

PortaSpeech - PyTorch Implementation PyTorch Implementation of PortaSpeech: Portable and High-Quality Generative Text-to-Speech. Model Size Module Nor

May 14, 2022
MACE is a deep learning inference framework optimized for mobile heterogeneous computing platforms.
MACE is a deep learning inference framework optimized for mobile heterogeneous computing platforms.

Documentation | FAQ | Release Notes | Roadmap | MACE Model Zoo | Demo | Join Us | 中文 Mobile AI Compute Engine (or MACE for short) is a deep learning i

May 18, 2022