LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error loading lvanlys.dll in Labview 64 bits

Solved!
Go to solution

@obarriel wrote:

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

 

obarriel_0-1580840100057.png


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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 11 of 33
(10,430 Views)
Solution
Accepted by obarriel

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.

Message 12 of 33
(10,419 Views)

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?

0 Kudos
Message 13 of 33
(10,406 Views)

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.

0 Kudos
Message 14 of 33
(10,397 Views)

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

 

Keeping the enviromental variable has any downside?

0 Kudos
Message 15 of 33
(10,395 Views)

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.

Message 16 of 33
(10,387 Views)

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... :()

 

 

0 Kudos
Message 17 of 33
(10,365 Views)

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.

Message 18 of 33
(10,362 Views)

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.  

0 Kudos
Message 19 of 33
(10,356 Views)

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?

0 Kudos
Message 20 of 33
(10,340 Views)