error loading lvanlys.dll in Labview 64 bits

[rolfk]

---

@obarriel wrote:

When I use the dependency Walker on this dll I get many dependency errors. I guess it is not normal.

---

Unfortunately it is. Dependency Walker has never been updated to deal properly with 32/64 bit DLL issues. So most of those errors are just bogus.

[BoKnows · Accepted solution]

As a troubleshooting step, let's try setting an environmental variable.  Create the following:

MKL_DEBUG_CPU_TYPE=4

Once you've done that, restart LabVIEW and see if the behavior continues.  If that clears up the behavior, I've got a pretty good idea of what we're looking at.  If not, it'll likely require more work.  In that case, you'll probably want to open a service request to get more focused help.

[altenbach]

I am curious what you  think the problem could be. The Intel MKL did have problems  with high core CPUs, but 8/16 is not that high an that was fixed 8 years ago.

I am following all this with great interest. 🙂

Also note that not everyone knows how to create env. Vars in windows. This is probably not a LabVIEW.ini entry, right?

[obarriel]

Thank you BoKnows! Setting this enviromental variable fixed the problem (apparently)

But I am getting a strange side effect...

Some operations are not completed and Labview is stuck there. For example  with a  simple matrix multiplication with complex numbers. Labview never finishes it and it needs to be reset.

[obarriel]

Sorry the side effect I mentioned seems unrelated to this. So disregard it.

Keeping the enviromental variable has any downside?

[BoKnows]

You're (altenbach) correct, it's not a LabVIEW entry.  As a general rule, I try to avoid providing instructions on non-NI processes in case those change later and the answer is documented here incorrectly.  For environment variables, I doubt that's the case.  But, I err on this side.

I'll share what the environment variable does as I think that both answers the "what's your theory" question as well as the downside question.

The Intel Math Kernal Library (MKL) chooses a way to handle SSE/AVX depending on processor.  By setting the variable, you're bypassing the automatic selection and telling it explicitly which way you want this handled.  The value of 4 selects AVX, which is AMD's most recent SSE implementation.  It's important to note this works for the newest AMD processors at the time of this posting.  This isn't something that is expected to work with any processor that isn't using AVX (so pretty please future readers, don't assume this is a catch all).

We've got the behavior you're seeing documented as Bug 578071.  I'll add your notes to it so that can help provide more context.  In the meantime, the only way I'm personally aware of to use those functions with the newer AMD processor is to set that variable to force the OS to use AVX.

[altenbach]

Great info. So the question is why the Intel MKL does not detect that processor correctly. 

I've been running a Ryzen1700X (8/16 cores, i.e. similar but a bit older and listed as supporting AVX) for quite a while with several LabVIEW versions and never had such a problem... So what's different here. Could probably be anything from the BIOS to the OS.

(A conspiracy theorist would suspect that Intel is trying to sabotage AMD. Just kidding....

... or maybe true. See also here... :()

[obarriel]

To complete the information:

With the setting MKL_DEBUG_CPU_TYPE=5 it works too

I have read in some matlab forums that this setting increases the performance for this amd cpu, but I have not checked it myself.

[BoKnows]

It appears 5 sets it to AVX2.  I won't try to pretend I know enough about these things to know the difference between AVX and AVX2.  But if you're curious, it appears your processor works with both and that's why either work.  

[altenbach]

Thinking about this a little more, it is not clear why the dll does not load without the tweak. Shouldn't it run just fine, but less optimized? What else comes into play here?