Welcome to LabVIEW High Performance Analysis Library

[duetcat]

The functionality previously provided by the High Performance Analysis Library (HPAL) on NI Labs will be included in an official LabVIEW software add-on in the near future. To request enrollment in the beta program, evaluate the software, and provide feedback, please contact Product Manager Casey Weltzin at casey.weltzin@ni.com.

Description:
LabVIEW High Performance Analysis Library provides parallel version of many mathematical and signal processing functions.

Software Requirements:

• Windows XP or later
• LabVIEW 2009 (32-bit)

Please feel free to ask questions here.

Thanks,

Qing

[preston_johnson]

What functions are in this High Performance Library? 

Will it work well in VxWorks on cRIO?

Preston Johnson

[duetcat]

There are some multi-threaded linear algebra and Fourier transform functions.

The current version only supports windows system.

Thanks,

Qing

[Andrey_Dmitriev]

Can you please provide download link?

The document http://decibel.ni.com/content/docs/DOC-9595# seems to be gone away.

Andrey.

[duetcat]

The home page of this library is coming soon. I will post the installer there.

Thanks,

Qing

[NatasaLingurovska]

The installer is available for download:

http://decibel.ni.com/content/docs/DOC-9645

Thanks,

Natasa

[GregSands]

Very nice - I've only looked at the FFT routines, but they're  definitely faster, even on my 2-core machine!  I've done some simple  benchmarking against the built-in FFT routines, with the following  results (1499x1499 element 2D CDB array):

1. Builtin  2D: 1500ms
   
2. Builtin  1D parallel: 800ms
   
3. HPAL  2D: 340ms
   
4. HPAL  1D by Row/Column: 390ms
   
5. HPAL  1D in a parallel loop: 320ms
   

So  for this test case, the fastest computation is to use the HPAL 1D FFT  inside a Parallel For-loop.  I presume the 1D FFT routine does not of  itself use multiple threads??

A couple of other questions:

• Would it be possible to incorporate a  3D FFT?  And perhaps a "1D by Row/Column/Page" equivalent?
• FFTs  are commonly used together with the Inverse, and in many cases, the  result (and sometimes even the FFT) could go back into the original  array (thereby saving memory for large arrays).  Would the call to the  MKL library support something like this?  The current design requires  allocating a new array for every FFT/Inverse call.

These questions would apply equally to the builtin code, but are perhaps more relevant for larger problems which are helped by efficient multi-threading.

I've attached the benchmarking code - plus also this is a duplicate of a comment on the library, I wasn't sure where to put it!

[duetcat]

Thank you for your attention. Very nice comments.

3D FFT is on our list. Actually, there are more functions are under development.They will be available in the next few months.

Please feel free to give us more suggestions. We'd love to hear feedback from users.

[Chringel]

Yesterday I downloaded the LabVIEW High Performance Analysis Library. I tested the FFT vi's, they're really faster than the Labview buildin FFT vi's. Thank you very much.

Suggestions for new vi's:

- add option to select a window (rectangular, hanning, hamming, blackman-harris, etc) to all FFT vi's

- add option to remove the mirror from the FFT output in case of real input

- add 2D FFT with both options above

- add fast dot product vi for arrays with complex numbers

- the vi's in the linear algebra group should accept arrays as input, it shouldn't force me to convert an array to a matrix first since this makes the vi in the end slower than the buildin multiplication vi.

What new functions will be available in the new release of the library? When will the updated library be available?

Regards,

Christiaan Lievers

[duetcat]

Thank you for your suggestions. They are very helpful to us.

The new release will be available in three or four months. There are a lot of new features, including more linear algebra and signal processing functions. A faster dot product is definitely in the list.

Furthermore, please do not worry too much about the matrix datatype. According to our benchmark, there is almost no overhead on converting array to matrix.

Please feel free to provide us more feedback. Thank you.