How are LabVIEW functions are Faster than Custom sub VI 's

[lordsathish]

Hi Ppl,

I have been using the NI IMAQ functions to find the histogram(NI_Vision_Development_Module.lvlib:IMAQ Histogram)  of the images. I wrote my own program to compute the histogram from the 2D array of the image. When I compared the execution speed of both these VI's after creating a exe, I found that NI IMAQ VI is 3 times faster than my code. why is this happening. To my knowledge the code I wrote is a efficient according to LV coding standards. Why is this difference in execution speed ?

Thanks,

This is the code I wrote:

 

Message Edited by lordsathish on 01-07-2010 06:42 AM

[Norbert_B]

Do you have a multicore machine? If yes, the answer is that the IMAQ VIs are optimized for multicore environments, while your code is not.

hope this helps,

Norbert 

[lordsathish]

Is it possible to optimize the above code to run in both the codes ? And achieve the same execution time.

[Norbert_B]

I don't know if you manage to achieve the same results as IMAQ. This is at least one point why you are paying for it.....

You can prepare your code for multicore by splitting the image into equally sized "subarrays". The amount of subarrays should be the number of cores you want to use for analysis. Then make an histogram for each subarray and sum up the histograms afterword to get the histogram of the complete image.

hope this helps,

Norbert 

[JÞB]

One point where you can optomize.

You init an array of I32[256] so index the histogram with a U8 rather than casting each image pixel to an I32.  Casting the image pixel by pixel is also less effecient than casting the image array to I32 outside the loop.  However, as mentioned, you don't really need to type cast image at all.

I'd like to see what the improvement would be with each "fix"

Message Edited by Jeff Bohrer on 01-07-2010 08:50 AM

[JÞB]

And I get my Doooh! for the day.

Why is "Histogram" a signed int? the count can only be 0 or positive a U16 can contain all the same possible values as a I32 in this example and uses 1/2 the memory!

Also reshaping the Image to a 1d array saves you a whole for loop and should get you right up there on performance

Message Edited by Jeff Bohrer on 01-07-2010 09:02 AM

[dan_u]

---

Jeff Bohrer wrote:

And I get my Doooh! for the day.

Why is "Histogram" a signed int? the count can only be 0 or positive a U16 can contain all the same possible values as a I32 in this example and uses 1/2 the memory!

---

Now that's not true. I agree it can be unsigned, but use U32 instead of U16. U16 only goes to 65535 (so this might overflow) while I32 goes up to 2147483647.

[dan_u]

---

Jeff Bohrer wrote:

One point where you can optomize.

You init an array of I32[256] so index the histogram with a U8 rather than casting each image pixel to an I32.  Casting the image pixel by pixel is also less effecient than casting the image array to I32 outside the loop.  However, as mentioned, you don't really need to type cast image at all.

I'd like to see what the improvement would be with each "fix"

Message Edited by Jeff Bohrer on 01-07-2010 08:50 AM

---

Indices to arrays are coerced to I32 anyway, so wiring the U8 directly should not result in better performance. And converting the whole array to I32 would consume 4 times the memory, so I wouldn't suggest to do so.

[JÞB]

I assume a distrbution in the histogram.  Yet even if the image is monotonic and greater in size than 256^2 the code could section it into blocks and sum th u16 arrays to represent a true picturehistogram could be

[dan_u]

@lordsathish

As Norbert already mentioned, I think your code is pretty much the best you can get from LabVIEW when using a single core.

I also did some calculation in nested for loops recently and I wasn't happy with the performance achieved.

I then wrote a C dll to perform the same calculation and the dll runs significantly faster (VI takes about 4 times as long as dll call).

So it might be worth to write a simple dll for this calculation (or, of course, use the IMAQ function).