Community Nugget 4/08/2007 Action Engines

[Ben]

See here for a thread where Christian posted an example of a progress bar that can be used in a parallel For loop.

Ben

[Ben]

Due to a failure of the Forums, the images used in this nugget may not be available.

I have posted copies of all of the original images in this albumn.

Thank you,

Ben

[danil33]

Hi Ben,

            Thankyou.This thread is highly informative.Detailed everything neatly.Intresting and informative for newbies like me.Thanks again.

[Ben]

---

@danil33 wrote:

Hi Ben,

            Thankyou.This thread is highly informative.Detailed everything neatly.Intresting and informative for newbies like me.Thanks again.

---

And thanks right back at you Danil33 ! I am plesed that this Nugget is still useful and the extra Kudos are always welcome.

Ben

[pierroil]

This nugget is wonderful. I just used an USR for my code and it's really awesome.

Thanks.

[Ben]

---

@pierroil wrote:

This nugget is wonderful. I just used an USR for my code and it's really awesome.

Thanks.

---

Thanks for the kind words Pieroil!

Yes to a large extent DVR can replace AEs. There is only one issue with DVR's and as long as you knowa about it, you can avoid. WHen using multiple DVR's there is a potential for a dead-lock condition where two threads each have access to a DVR but are dead-locked waiting fo rthe other DVR. The analogous situation using AEs could use one AE inside antoher AE. Since recursion of AEs is difficult (is it impossible?) the dead-locks can be avoided.

So watch out for dead-locks and DVR away!

Ben

[pierroil]

Well time to go look up DVRs I guess!

haha thanks!

[AristosQueue (NI)]

---

@Ben wrote:

Yes to a large extent DVR can replace AEs. There is only one issue with DVR's and as long as you knowa about it, you can avoid. WHen using multiple DVR's there is a potential for a dead-lock condition where two threads each have access to a DVR but are dead-locked waiting fo rthe other DVR. The analogous situation using AEs could use one AE inside antoher AE. Since recursion of AEs is difficult (is it impossible?) the dead-locks can be avoided.

So watch out for dead-locks and DVR away!

---

Just so you know, if you have two processes and two DVRs, as long as each process uses a single Inplace Element Structure to acquire both DVRs, LabVIEW has built in mechanism to avoid the deadlock known as the Dining Philosopher's Problem. The IPE will acquire the DVRs in refnum numerical order every time, thus guaranteeing that if a process gets one of the DVRs, it will get both of the DVRs, and no other process will get any of the DVRs until it can both of the DVRs. Any time you have multiple DVRs shared by the same two processes, and you are going to have the same subroutine using both of them, you should acquire both DVRs using a single IPE.

[Ben]

I know this is an old thread but I thought it would be a good time to update it now that Feedback nodes are available.

For pure number crunching AEs the FB node has shown itself to be up to 10X faster than the traditional form. I understood this as being atributed to the over-head required to check the stop conditon of the loop. Using FB nodes there are no checks required so pipelining in the CPU does not have to stall the instruction pre-fetch.

The benchmark I used for the test was a simple "Init" "Increment" Get" AE. The "Icrement was called repeatedly and timed. The benchmark was run in LV 2014.

I was suprised.

Ben

[crossrulz]

---

Ben wrote:

The benchmark I used for the test was a simple "Init" "Increment" Get" AE. The "Icrement was called repeatedly and timed. The benchmark was run in LV 2014.

---

Mind sharing your benchmarking code?  I would really like to look at this myself.  And we may even find some issues with your benchmarking.