Convolution.vi speed

[David_Ferster]

Convolution.vi is could be made much faster.

First, it does not seem to take advantage of the presence of multiple processor cores. Convolution could be parallelized by cutting one input array into pieces and performing the convolution on the different pieces in different cores. It would be nice if the vi did this automatically.

Second, the vi only works on floating point values (doubles). A polymorphic version that used integer arithmetic (using the "direct" method) instead of floating point would be faster when integer arrays are being convolved.

[AristosQueue (NI)]

David: I'll make sure math team sees this idea, but they are swamped, so it would likely be a long while before an idea like this gets acted upon. Do you already have a rewrite of these VIs that includes the performance improvments you're suggesting? If so, would you be willing to share them with NI for inclusion in the next version of LabVIEW? If not, that's fine, but I figured I'd ask.

[altenbach]

The NI LabVIEW Multicore Analysis and Sparse Matrix Toolkit has convolution (and much more!) optimized for multiple cores. As for integers, you can easily write your own, but you need to be very careful with overflow issues.

[David_Ferster]

Chris: I'm surprised that would have to pony up an extra $1,500, plus probably a license for each of my users, in order to take advantage of any modern processor. I would have thought that is something that was inherent to LabVIEW.

Aristos: No, I haven't got anything proper of my own. In my vi's, I split my arrays into 2 or 4 parts and send them into parallel instances of Convolution.vi. It almost doubles the speed, but it is rudimentary, and does not address the integer/float issue.

[altenbach]

If the regular convolution tools were fully parallelized, the compiler would need to be smart about it. For example if the code runs several convolutions in parallel (I sometimes do), the function itself probably should not.

[altenbach]

Are you talking about 1D or 2D convolution? How big are the arrays?

[David_Ferster]

2D arrays. About 10,000 elements.

I looked briefly at the Mathworks website. Matlab's math functions (linear algebra, FFTs, etc) are optimized for multicore.

[altenbach]

Is the convolution kernel relatively small or are both input arrays about the same size?

[David_Ferster]

The former. The convulution kernel is small relative to the input array.

[AristosQueue (NI)]

> I'm surprised that would have to pony up an extra $1,500, plus

> probably a license for each of my users, in order to take

> advantage of any modern processor

A) I wouldn't necessarily suspect a nefarious purpose... it's very easy for someone to build a toolkit that isn't part of LV and not think about just replacing the core VI when they write a new one for their toolkit.

B) But I can see us charging for the upgrade. "Taking advantage of a modern processor" is a loaded phrase. LabVIEW VIs take advantage of parallelism all over the place. But code that cannot be recognizably parallelized by a compiler require writing parallel algorithms, and that's some specialized training. Perhaps not in this particular case, but in general. We wouldn't be the first company to have a basic "it works" and a more expensive "it works better".

C) Regardless, unless something has changed and I missed the price change, there's no license for your users for our toolkits. Modules, sometimes yes, but not toolkits. When you build your EXE or DLL, there's no downstream revenue gathering from NI from your use of LabVIEW. (Note that I'm somewhat out of my depth talking about pricing, so I freely admit I may be wrong here.)

D) I'll mention to the team that we already own a convolution VI and see what feedback I get.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.