Which Math Library does LabVIEW use?

[Reds]

Does anyone know which math library LabVIEW uses to do the FFT and vector math operations? 

Has it been updated over the years to accomodate the latest Intel CPU extensions, or has it been static over time?

[Rolf Kalbermatter]

The Intel Math Kernel Library. NI occasionally updates the Intel MKL used but doesn't painstakingly follow the latest and greatest from Intel. And there might have been some licensing perils in recent years. NI got a license to distribute the MKL when it was still its own product and Intel was very keen to have as many people as possible adopt it. Nowadays it is part of the One API initiative and Intel is a lot more pushy about monetizing that, so they may have altered the license deal that NI had, and NI might or might not have accepted that.

Edited January 10 by Rolf Kalbermatter

[Reds]

Thanks Rolf.

i was actually looking at switching to the Intel MKL (instead of LabVIEW native) in a bid to improve multi core performance. But if LabVIEW is already using MKL, I wonder why it doesn’t seem to take advantage of multi core for FFT?

[GregSands]

Check out the LabVIEW Multicore Analysis and Sparse Matrix Toolkit which has multicore replacements for FFT and many other matrix functions.

[X___]

Check this thread though:

I wasn't able to take advantage of any multicore speed up and as for many NI toolkits, documentation is aspirational.

[Reds]

"Documentation is aspirational" is a great line that I'm totally stealing. 😂

I laid down the big bucks for the top-of-the-line 18-core PXIe-8881. I feel like the engineering gods are mocking me as 17 of the 18 cores are idle when I run my FFT. I mean, what is the point of an 18-core PXI CPU if NI's default math library can only use one of them? Is there any other T&M application besides math/analysis that would actually benefit from 18 cores? Maybe I need to use MatLab to access all 18 cores? The whole thing is kind of crazy if you ask me.

 

Edited January 11 by Reds

[Reds]

If anyone else is interested, here's some evidence from one of my machines, indicating that NI is installing various versions of the Intel MKL. They look reasonably up-to-date. So I'm still unsure why they're not taking advantage of multi-core...

[Reds]

But if I use Resource Monitor to look at the DLL's my LabVIEW-built EXE is calling, none of the DLL's have "MKL" in the filename. It seems to me like LabVIEW is using our old friend "lvanlys.dll" to perform FFT calculations. 

Can anyone confirm my suspicion??

[Rolf Kalbermatter]

Your suspicions are partly right! lvanlys.dll is for the most part the conversion layer from the LabVIEW AAL functions to the MKL. In old days lvanlys.dll was the NI implementation of the Advanced Analysis library. But when they changed to use the MKL they could (or did not want to) change the entire LabVIEW Call Library Nodes to adapt to the MKL entry points. Basically the MKL is NOT written with LabVIEW in mind but fully designed to be called by C(++) code. An intermediate translation layer written in C(++) that provides a LabVIEW friendly interface is the most easy thing to do in that case (no it's not easy at all but the alternatives are much worse in terms of effort and maintainability).

Also there were some specific assumptions in the LabVIEW AAL that are slightly different how the MKL library expects things, so the lvanlys.dll also takes care of such differences. Alternative would have been to change some of the conditions for callers of the LabVIEW functions, which would have been a very serious backwards compatibility problem.

Edited January 15 by Rolf Kalbermatter

[Reds]

Interesting, thanks Rolf! So then....I wonder if lvanlys.dll is not written to call the multi-core version of the FFT in MKL?

Intel vTune Profiler also provides the hard evidence:

 

And if this is not a failing grade for lvanlys.dll, I don't know what is:

 

Edited January 15 by Reds

[GregSands]

Reds, did you miss my earlier comment - while lvanlys.dll does not use multicore functions, the LabVIEW Multicore Analysis and Sparse Matrix Toolkit does. Despite X's comments on the lack of documentation, which are quite fair and accurate, I'm seeing huge speedups on my i7-12700F with 8P+4E cores (20 logical processors according to CPU Information).

For a 1499x1499 CDB 2D array, the inbuilt NI FFT takes ~270ms, the MASM FFT takes ~20ms, and the MASM FFT on the same array as CSG takes ~11ms (the built-in FFTs don't support single-precision, but MASM does, and it's often all that is needed).

 

Edited January 16 by GregSands
Added snippet

[mcduff]

The LabVIEW Multicore Analysis and Sparse Matrix Toolkit is definitely faster but it seems to have issues with the large number of points.  For example, on my laptop I cannot do a FFT of 20M points, but the built in FFT does 100M points no problem.

[Reds]

18 hours ago, GregSands said:

Reds, did you miss my earlier comment - while lvanlys.dll does not use multicore functions, the LabVIEW Multicore Analysis and Sparse Matrix Toolkit does. Despite X's comments on the lack of documentation, which are quite fair and accurate, I'm seeing huge speedups on my i7-12700F with 8P+4E cores (20 logical processors according to CPU Information).

Thanks Greg, appreciate it! I think I need to figure out how this MASM toolkit would be installed with our EXE on customer systems. If I can integrate the MASM installer into our LabVIEW installer package, this could work for us. I'll investigate...

You make a good point about single precision being all that's necessary also.

Edited January 17 by Reds