vbai quad core cpu runs 25% cpu load

[Andrey_Dmitriev]

---

As far as i know its not possible to use multicore on a windows system in combination with the VBAI.

---

Its not true.

VBAI based on IMAQ Vision. Vision (since 8.6) is partially optimized for multicore, and VBAI uses this optimized library. By default optimized function will utilize multiple CPUs (if this not suppressed with IMAQ Multi-Core Options.vi).

Create simple inspection with two steps: Simulate Acquisition and Filter Image (Filter Type - Median), then run it.

With dual core you can get up to 95-98% cpu load if kernel big enough. (My test with kernel size = 15 running for approx 500 ms)

Then turn off second CPU (via Task Manager) - you will get 50-60% with almost double execution time (I've got 800 ms).

(Median Filter based on IMAQ NthOrder.vi, and this function is optimized for Multi CPU).

Another problem, that IMAQ GrayMorphology is NOT optimized for multi cpu as mentioned above, and this is the problem.

Just checked it in LabVIEW- there are no any differences for single or dual CPU.

Andrey.

[Andrey_Dmitriev]

---

DOC-doc wrote:

In order to test what you are saying,  I made a vbai script which is only calling a vision assistant "script". This script is performing grey morphology only, a big number of time to load enough the cpu.

Result : cpu load 25%, even for multicore optimized functions.

---

So, it means that you needed to add some own programming work for getting power of multi CPUs.

Here is pretty simple technique - you need split your image into multiple parts, then perform processing parallel, then join results back. Something like that:

This will give you shorter execution time (but not always, because overhead added by split/join operations).

Starting point in attachment.

In given example Gray Morph was reduced from 75 to 50 ms on dual core PC.

Andrey.

Message Edited by Andrey Dmitriev on 04-08-2009 02:12 PM

[Elmar_NI]

Hello Andrey,

thanks for the info. I know that some functions are optimized for dualcore in the latest vdm.

For example the data matrix or ocr function use multicore. But you are not able to choose the core like in LabVIEW with the timed loop.

Kind regards,

Elmar

[BullDozier]

Doc Doc,

 
I've done some testing on my PC here (tri-core).  I found results similar to you when I was using smaller images.  The reason for this is that even if I'm using multi-core optimized functions, there is still some overhead in both non-multicore operations and memory juggling that has to go on behind the scenes while VBAI is running.  I've found that for large images and complex algorithms, you are indeed able to max out a processor.  Please observe my screenshot below:

 

 I basically used a large image (12.8k X 9.6k) and did a straight edge detection (it's multi-core optimized) with rakes spaced close together and I was able to max out my processor.  

Just to clarify something else, VBAI and Vision are partially optimized for multi-core, not just dual-core.

Let me know if any of that isn't clear Doc Doc.  The main reason you're probably not seeing 100% processor utilization on your app is that the amount of time that your inspection takes on the multi-core optimized functions is trivial vs. the amount of time it takes on the non-multi-core functions and background management.

Cheers,

Message Edited by BullDozier on 04-09-2009 05:18 PM

[DOC-doc]

So from your tests we can conclude that except a few functions called on very large images, vbai is not optimized at all for multicore systems... bad news for us and all the people who are buying multicore systems.

What takes a lot of time in our script is a vision assistant script running automatic thresholding (ni-black and background correction).

If I make a specific vi and call it in my script instead of the vision assistant script that runs these two specific functionnalities (ni-black and background correction) in parallel on 4 different images, would I get better result on the cpu usage?

I ask the question because I know that some functions don't support parallel calling

Message Edité par DOC-doc le 04-15-2009 11:04 AM

[BullDozier]

Hey Doc Doc,

So as far as splitting up the threshold to where it will do 4 in parallel, that is completely possible.  Another possibility is that even if you combine these functions to operate in parallel, you might not see any CPU speedup.  This would be because the processor wasn't the bottleneck in the system.  On a lot of the simpler vision functions, the bottleneck is actually memory management and pulling images out of memory to perform operations on them.  I've done a little test on my side and I did see speedup when I parallelized them, so it is promising that you might see an increase.  

I just wanted to make you aware of the memory management limitation that can sometimes play a big factor in program speed and execution.

Cheers, 

[DOC-doc]

Thanks BullDozier for your answer.

What we actually did is a specific vi that reproduces the functionnality of the Vision Assistant Script. We implemented the 4 NI-Black Threshold in parallel (we have 4 cpu) and the running time for this function is divided by 3.3.

And now we are facing the problem that all other Vision Builder AI steps seems to have an overhead of 1ms or so, and it seems more or less constant and impossible to spread on multiple cpus