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

[bartekkuncer]

From #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-bot]

Hey @bartekkuncer , Thanks for submitting the PR
All tests are already queued to run once. If tests fail, you can trigger one or more tests again with the following commands:

• To trigger all jobs: @mxnet-bot run ci [all]
• To trigger specific jobs: @mxnet-bot run ci [job1, job2]

---

CI supported jobs: [edge, unix-cpu, windows-gpu, centos-cpu, sanity, centos-gpu, miscellaneous, windows-cpu, unix-gpu, clang, website]

---

Note:
Only following 3 categories can trigger CI :PR Author, MXNet Committer, Jenkins Admin.
All CI tests must pass before the PR can be merged.

[bartekkuncer]

CC: @leezu, @TaoLv, @anko-intel, @szha, @akarbown

[bartekkuncer]

@mxnet-bot run ci [centos-gpu, windows-cpu]

[mxnet-bot]

Jenkins CI successfully triggered : [centos-gpu, windows-cpu]

[szha]

@mxnet-bot run ci [windows-gpu]

[mxnet-bot]

Jenkins CI successfully triggered : [windows-gpu]

[samskalicky]

There is also another idea to change the 3rdparty/mkldnn folder name to 3rdparty/onednn for consistency. The problem is that it will create unnecessary difference in directories names between branches.

since this is the master branch, and we're moving from 1.x to 2.0 shouldnt this be the time to make this change? Having a directory named "mkldnn" but using "onednn" everywhere will only cause confusion in the future for those who do not have the historical background.

[bartekkuncer]

There is also another idea to change the 3rdparty/mkldnn folder name to 3rdparty/onednn for consistency. The problem is that it will create unnecessary difference in directories names between branches.

since this is the master branch, and we're moving from 1.x to 2.0 shouldnt this be the time to make this change? Having a directory named "mkldnn" but using "onednn" everywhere will only cause confusion in the future for those who do not have the historical background.

@samskalicky Ok, will add it soon.

[bartekkuncer]

Added commit regarding changing name of the submodule directory.

[bartekkuncer]

I think that the commits regarding updating onednns old acronyms used in mxnet in different contexts can be added to separate PR and if there is no objection this one can be already merged into master to avoid creating code with deprecated versions of the flags.

[samskalicky]

I think that the commits regarding updating onednns old acronyms used in mxnet in different contexts can be added to separate PR and if there is no objection this one can be already merged into master to avoid creating code with deprecated versions of the flags.

Can you give an example, which acronyms are you referring to?

[bartekkuncer]

I think that the commits regarding updating onednns old acronyms used in mxnet in different contexts can be added to separate PR and if there is no objection this one can be already merged into master to avoid creating code with deprecated versions of the flags.

Can you give an example, which acronyms are you referring to?

Before v1.1 of oneDNN it was called MKLDNN, then dnnl up until some time ago. Due to that we have a mixture of different acronyms used in the code and unifying them using the most recent one can help avoid some unnecessary confusion.

[bartekkuncer]

@mxnet-bot run ci [unix-gpu]

[mxnet-bot]

Jenkins CI successfully triggered : [unix-gpu]

[bartekkuncer]

@mxnet-bot run ci [unix-gpu]

[mxnet-bot]

Jenkins CI successfully triggered : [unix-gpu]

[bartekkuncer]

@szha @leezu @samskalicky Please help with the merge.