Deeplearning4j: beta6 seems to force OPENBLAS

[tc64]

Issue Description

After upgrading to beta6 from beta5, I see in logs:

org.nd4j.linalg.api.ops.executioner.DefaultOpsExecutioner || printEnvironmentInformation || Blas vendor: [OPENBLAS]

Previously I saw MKL in the brackets.

In addition I see the warning mentioned in #8585 - not sure if it could be related.

Also I noticed that in load testing the application that uses deeplearning4j models, which is a webapp running in tomcat, CPU usage was much lower after upgrading to beta6.

Version Information

• Deeplearning4j 1.0.0-beta6
• Platform information: Windows10 and RedHat 7.7 (same behavior on both platforms)

Additional info

I tried setting -Dorg.bytedeco.openblas.load=mkl_rt and restarting, but I still see OPENBLAS in the log statement shown above.

[saudet]

You'll need MKL to be able to use it! Details here: https://github.com/bytedeco/javacpp-presets/tree/master/openblas#documentation

[tc64]

@saudet I might be misunderstanding, but just to clarify, prior to upgrading to beta6 it seemed like MKL was being used (since logs said Blas vendor: [MKL]).

I did look at the link you sent. Do you mean to imply I will need to update my pom.xml after the upgrade from beta5 to beta6 to keep using MKL?

[saudet]

That or have MKL installed on the system, yes. I believe that was in the
release notes somewhere for beta6...

[saudet]

Nope, it's not: https://deeplearning4j.org/release-notes#onezerozerobeta6

[tc64]

@saudet thanks for the info.

If MKL (or MKL-DNN) is installed on the system, is there a VM argument I can use to provide a path to the installation?

[tc64]

ah ok i see, I guess it is -Djava.library.path, will try this

[tc64]

@saudet I tried pointing java.library.path to where I believe MKL files are. I confirmed it is properly set with JMX, looking at System properties. I'm running the app in tomcat, and the path I used is the WEB-INF\lib directory for this webapp. I also have org.bytedeco.openblas.load=mkl_rt set.

I can't post to github from the relevant computer but here is a screenshot of relevant part of that directory:

I confirmed that jnimkl_rt.dll is in that jar under org\bytedeco\mkl\windows-x86_64, not sure if that is what I need.

When I run the application I still see Blas vendor as OPENBLAS in the nd4j log.

Then I found a (older, like march 2018) mkl_rt.dll file in .javacpp\cache\lib and put it in the same folder (the WEB-INF\lib one), ran the java application, and it crashes right after the log statement about the AVX support warning (from createBlas method). By crash I mean the tomcat window just closes and i dont see any log anywhere with an exception.

In summary

• Setting java.library.path and org.bytedeco.openblas.load=mkl_rt doesn't appear to be effective, unless i put a mkl_rt.dll file in the lib dir, in which case tomcat suddenly crashes right after the AVX warning.
• Removing that mkl_rt.dll file, or omitting setting either java.library.path or org.bytedeco.openblas.load=mkl_rt results in no crash, but OPENBLAS is shown in logs as Blas vendor.

I tried adding the following info to my pom.

<dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>mkl-platform</artifactId>
            <version>2019.5-1.5.2</version>
</dependency>

I'm using a private maven repo and the latest version of mkl is old.
I see in my .m2\org\bytedeco\mkl-platform\2019.5-1.5.2 there is a jar, pom, and sha1 and _remote.repositories files.

Still I see the Blas vendor is OPENBLAS. I suspect I'm doing something wrong, was hoping you could shed some light. Thanks!

[saudet]

If you're looking for a simple solution, please use the -redist artifacts like this:
https://github.com/bytedeco/javacpp-presets/blob/master/mkl/README.md#the-pomxml-build-file

[tc64]

I added:

<dependency>
      <groupId>org.bytedeco.javacpp-presets</groupId>
      <artifactId>mkl-platform</artifactId>
      <version>2019.1-1.4.4</version>
    </dependency>


    <dependency>
       <groupId>org.bytedeco</groupId>
       <artifactId>mkl-platform-redist</artifactId>
       <version>2019.5-1.5.2</version>
    </dependency>

In order to get MKL to be used (evidenced by nd4j logs) I had to use flag -Dorg.bytedeco.openblas.load=mkl_rt