multi thread dll

[xgatc]

Hi, there

I have a labview application where I need to use a user-built centroiding function.   I compiled this stand alone function usrCentroid.c to a dll, using a script:

  gcc -c -o %1.o  %1.c
  gcc -shared -o %1.dll %1.o 
 

the gcc is from a free version MinGW.

I then used CIN to call this dll, everything works.  However, when I wanted to use two of the dll simultaneously ( set re-entrant too),  I could not get the parallel performance in time. it always takes twice as long as a single call of the dll.

one of NI engineer tried this on his quad CPU machine ( I only have a dual CPU) with timed loop, it gave him the same result.  He suggseted me to build multithread dll for usrCentroid.c.  

Has anyone out there built dll for multithread?  I could not find any option for gcc to build multi-thread dll. 

I tried to have two totally different functions ( usrCentroid1.c and usrCentroid2.c nothing in common), and built two DLLs.  I asked the NI engineer to try on his quad CPU again.  Calling these two dlls, still gave him the same result as before. 

However, he told me that if he used IMAQCentroid function from Labview with the same parallel diagram, it took  the same time as a single call of the dll.

 is there something else here I need to consider for user buildt dll ?

 very appreciated any suggestion/advice.

Xiaofeng

[Andrey_Dmitriev]

Hi,

At the first, do not confuse with CIN (Code Interface Node) / DLL Call (Call Library Function). There are two different functions. Assumed that you have used regular DLL call instead of CIN.

But there are many possible reasons why two calls are not parallel...

Be sure that:

- DLL call marked as thread safe ("Run in any thread" option is selected)

- if DLL placed inside of SubVI, then SubVI marked as reentrant

- in parallel secions no any elements exists which caused switching to UI thread (property nodes, etc)

- inside of DLL all things are thread-safe (for example some IMAQ library functions may be blocked by internal semaphore)

Finaly show your code for DLL and VI if it possible.

Andrey.

[xgatc]

Hi, Andrey

thanks for the reply.

please see the attached zip file.  timed-test-readOneImage-usrCenDLL.vi is the main vi.

I have set all options you mentioned.

I wrote a simple C program to test on my window's command line:

  call calculateCantroid1 with algorithm =1, takes around 50msc.

inside the LabView, with all the option setting, a single call to calculateCantroid1 takes around 130mSc

if I select the parallel, the total time becomes around 400~500mSc.   my PC has a dual cpu. see attached. *png

 I may miss soemthing here,    any suggest is more than welcome.

cheers

Xiaofeng

[Andrey_Dmitriev]

Hi,

Your problem is not DLL, but ImageToArray conversion (and reshaping array from 2D to 1D). This caused most problems. The IMAQ functions itself (not all) are optimized for dual core, so when called parallel, then needed more time.

Replace array operation with pointer operation and you will get better speed (but be very careful with image geometry! - see help)

Also be sure that all SubVIs in "parallel" hierarchy are reenterant.

Usually you wil not get pure double speed on dual core. Ony my PC I have approx 40 ms for single call and 60 ms for double call which is not so bad.

Timed loop is not necessary in your case. LabVIEW can do all things parallel fully automatically.

Andrey.

[BlueCheese]

Starting and stopping a timed loop each iteration is going to be fairly wasteful because there is all sorts of synchronization that happens. Putting things in timed loops almost never makes it faster. The main purpose of timed loops is only to provide better determinism between when loop iterations happen for control algorithms that require this. By putting code in a timed loop you give up any parallelism on the LabVIEW diagram inside the loop, since multi-threading that code would cause extra jitter.

Also, you are likely still to get better results using Vision functions to  find the centroid. Even combining it with some thresholding operation first I'd wager that it would likely be faster than your custom code.  

Eric 

[Andrey_Dmitriev]

---

BlueCheese wrote:

...

Also, you are likely still to get better results using Vision functions to  find the centroid. Even combining it with some thresholding operation first I'd wager that it would likely be faster than your custom code...

---

... and you will lost this challenge with big probability!

Eric, would you wager personally with me that I will be able to realize Centroid which is faster than IMAQ Centroid on dual core cpu for image given above with +/- 0.5 pixel precision? Let's say - bottle of wine or beer? 😉

Andrey.

[xgatc]

Andrey

many thanks for the reply. 

I did tried your modified one, but got  different answer for centroid ( x=790.329 y=517.845) from my original ones( x=609.564, y=515.457).   My original one has been checked with IMAQCentroid ( applied IMAQthreshold, rang [500, 4096] keep original value before calling IMAQCentroid). 

I looked at the configuration of dll (in your usrCentroidOPt-sub.vi), noticed that pixelPointer out  is connected to data array of the function call.  and it passes as a value.    I am confused here.  the data array is a pointer,   can we pass a value to it? 

did I miss something here? 

cheers

Gao

[xgatc]

Eric

thanks.  I did try IMAQCentriod, see my reply to Andrey.  but we did find there are some difference between our own code and IMAQCentriod depending on IMAQthreshold rang setting, image intensity and shape etc.

we may often have unsymmetrical donut shaped images, and need to find out the offset of inner ring and adjust mirrror to correct it.

cheers

Xiaofeng

[Andrey_Dmitriev]

The answer is different, because alignment gaps are involved into calculation inside of DLL (I unable to change your DLL).

If you need fast image processing with your custom DLLs, then stay away from LabVIEW arrays! Pass image by pointer to your DLL - this is fastest way.

Again, be careful with image in memory, refer to help for IMAQ GetImagePixelPtr:

Also see example how to use pixel pointer properly:

The pointer passed as value, because in DLL will be interpreted as pointer to the image. If you will pass I32 as pointer, then it will be pointer to integer, and not pointer to the image!

Hope it helps.

By the way I checked IMAQ Centroid. It works correctly (and pretty fast).

Andrey.

[BlueCheese]

---

Andrey Dmitriev wrote:

---

BlueCheese wrote:

...

Also, you are likely still to get better results using Vision functions to  find the centroid. Even combining it with some thresholding operation first I'd wager that it would likely be faster than your custom code...

---

... and you will lost this challenge with big probability!

Eric, would you wager personally with me that I will be able to realize Centroid which is faster than IMAQ Centroid on dual core cpu for image given above with +/- 0.5 pixel precision? Let's say - bottle of wine or beer? 😉

Andrey.

---

Ha. I'll admit that if you want something "special" that the IMAQ code does not do, then if you can write it manually as a single-pass operation then it is of course likely going to be faster than having to do multiple less-specialized IMAQ operations. However, in general, the IMAQ functions are fairly optimized and many users that roll-their-own functions end up causing more overhead (such as with Image To Array seen here) than they save. You are likely not the average user! 🙂

A better discussion would be to identify what shortcomings you see in the current IMAQ Centroid (in terms of options, functionality, precision, performance, etc) and which ones you consistently find yourself rolling your own implementation of. If these are common, there is no reason why we couldn't add them to a future version of Vision Development Module. 

Eric