Cmake blas

[edisongustavo]

Description

Eases the pain of linking with OpenBLAS using cmake.

This PR adds support to use the provided OpenBLASConfig.cmake.

Justification for the change

The standard way of linking with dependencies in CMake is via the find_package() mechanism (docs). This mechanism provides 2 ways of finding the dependencies:

• Config mode (uses a file named OpenBLASConfig.cmake (or openblas-config.cmake), which are provided by the dependency itself)
• Module mode (uses a file named FindOpenBLAS.cmake, which is provided by either cmake or the project compiling the dependency, mxnet in this case)

The preferred way to find a dependency is if they provide their "Config" file, since the authors of the dependency are the ones who know best about the structure of their code and how they should be linked.

When I tried to compile MXNet on Windows it didn't work well. My setup was:

• Visual studio 2017.
• OpenBLAS package from the SourceForge binaries package, as specified in the documentation to build MXNet on Windows from source.

It failed because this binary package is compiled with a Visual Studio version prior to 2015. So I would get the error unresolved external symbol __imp____iob_func. The reasons are explained here: https://stackoverflow.com/questions/30412951/unresolved-external-symbol-imp-fprintf-and-imp-iob-func-sdl2

Then I tried to use the conda-forge package. This almost worked.

On further inspection of the FindOpenBLAS.cmake and the conda-forge package, I noticed that MXNet didn't use the provided "cmake Config mode" files (OpenBLASConfig.cmake). It tried to find the library all by itself, which is an "anti-pattern" when using cmake. So I thought that this could be an opportunity to be able to contribute to the project by improving this module.

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)
• 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

• Add , tests, (and when applicable, API doc)

I have tested this by compiling it on Windows and Linux.

To provide OpenBLAS I have tried:

On Linux:

• compiled OpenBLAS from source with cmake and installed it
• compiled OpenBLAS from source with make and installed it

On Windows:

• used the compiled OpenBLAS package from conda-forge: https://anaconda.org/conda-forge/openblas

Comments

[vandanavk]

@mxnet-label-bot add [pr-awaiting-review, Build]

@marcoabreu for review

[edisongustavo]

This is still a WIP, I will fix it as soon as possible.

[lebeg]

looks good

[lebeg]

Actually, you can set the PREFIX instead.

[edisongustavo]

Yes, but the problem is that the utility getarch which is invoked by the Makefile fails to execute. That would be another rabbit hole that I didn't want to get into.

[perdasilva]

is this change also relevant for the other arm builds? ok seems to diverge from ther others. Did you figure out if this affects anything downstream? and is it worth moving this change to a different PR for PR atomicity, etc. ok - now I see from the cmake code why it matters. All good! Safe to ignore this.

[edisongustavo]

Did you figure out if this affects anything downstream?

What do you mean by that? If any other image is using this docker image? I didn't check that, but it shouldn't affect any downstreams, unless they're depending on this, which would be depending on an undocumented hack.

and is it worth moving this change to a different PR for PR atomicity, etc.

The problem is that this change is required for this PR to be merged. Without this change it won't work.

[perdasilva]

Yup - I saw that. All good! My bad, I didn't read to the end before commenting =P

[aaronmarkham]

Can you add what the user might need to do to use this? Maybe it would be good in these spots:
https://mxnet.incubator.apache.org/versions/master/install/build_from_source.html
ttps://mxnet.incubator.apache.org/versions/master/install/ubuntu_setup.html#build-the-shared-library

Option 1 step 8 seems relevant. https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html#build-from-source

https://mxnet.incubator.apache.org/versions/master/faq/env_var.html?highlight=environment

Or let us know needs updating and someone can loop through the docs to make sure setup references are updated.

[edisongustavo]

Good points @aaronmarkham! I will take a look at the docs to see what can be updated.

[anirudhacharya]

@edisongustavo ping to update the PR

[edisongustavo]

@anirudhacharya I will get back to this asap, probably tomorrow.

[karan6181]

@edisongustavo Thank you for your contributions! Can you please provide some updates in this PR? Thanks!

[larroy]

LGTM

[abhinavs95]

@mxnet-label-bot update [Build, pr-awaiting-response]

[abhinavs95]

@edisongustavo Could you please provide an update on the PR? Thanks

[edisongustavo]

@abhinavs95 Yes, I will do that tomorrow.

[piyushghai]

@edisongustavo Gentle ping...

[Roshrini]

@edisongustavo Can you address Aaron's comments so that we can move forward with this PR? Thanks

[roywei]

@mxnet-label-bot add [pr-work-in-progress]

[edisongustavo]

Hello all, sorry for taking so long to answer. Things have been very hectic at lately.

Anyway, I've looked at the docs and the place that I see that could use an update is this part here (https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html#build-from-source):

1. Download the OpenBlas package. Later versions of OpenBLAS are available, but you would need to build from source. v0.2.19 is the most recent version that ships with binaries. Contributions of more recent binaries would be appreciated.
2. Untar the file, rename it to OpenBLAS and put it under C:\utils. You can place the unzipped files and folders in another directory if you wish.

The problem is that the version of the OpenBLAS package compiled there is using Visual Studio 2008, which is not compatible with Visual Studio 2017.

I have looked at all releases at the OpenBLAS sourceforge page and didn't find any releases with binaries on it.

Problem

The problem is: "find compiled binaries of OpenBLAS (for Visual Studio 2017) available for download on the web".

Proposed solution 1

A solution I could think of is to use the compiled package from conda-forge: https://anaconda.org/conda-forge/openblas

In that page, the closest version 0.2.19 that have Windows releases is 0.2.20: win-64/openblas-0.2.20-vc14_8.tar.bz2. The newer versions all have Windows releases, so we could just use point to use version 0.3.6 instead.

The rewritten doc would look like this:

6. Download the [OpenBlas](https://anaconda.org/conda-forge/openblas/0.2.20/download/win-64/openblas-0.2.20-vc14_8.tar.bz2) package.
7. Untar the file. There will be a directory inside named `Library`, rename it to ```OpenBLAS``` and put it under `C:\utils`. You can place the unzipped files and folders in another directory if you wish.

Would this be good enough @aaronmarkham ?

[edisongustavo]

People, I accidentally deleted my incubator-mxnet fork while I was cleaning up my GitHub account...

I've recreated the PR here: #14871

[aaronmarkham]

Closing in favor of #14871.