For loop parallelism on single core

[Fyzikfyzik]

I use array of notifiers (let's say size n). There is a watchdog code which waits for every notifier from array with 10 seconds of timeout. If any of them times out, it runs a function. At this moment, i have no for loop and these notifier waits run simultaneously, so they all finish after 10 seconds max. I would like to do the readings programatically, so when I add new watchdog notifier, I don't have to add new branch of notifier waits. If I use for loop, there is no parallelism and it is finished after n * 10 seconds. On dualcore, if I turn parallelism on, it takes n * 10 / 2 seconds. I need something to run in parallel on single core, is there any option?

Thank you.

[Eric1977]

It would really help if you uploaded your VI. That way, we could see what is going on with anything else within your VI.

[altenbach]

You are not even using the "timed out?" output? How do you tell if a timeout has occurred?This all seems clumsy.

Why can't you run them with a shorter timeout and keep track if any of them time out e.g. 10x in a row and if so trigger the timeout code?

Yes, please show us more of the code.

[tyk007]

Your level of parallelism is dependent on a number of factors. It would be worth reading this (on the dark side) that will help fill in some gaps. It looks like the Wait on Notification is a blocking call, which means while a thread is calling this node it is not readily available to execute another Wait node.

Since you say you are locked to a single core CPU, possible improvements to overall time are:

• Maintain the "watchdog timeout" independently of the Waits - basically run the Notifiers with a small timeout (say 10ms) inside a loop and then keep track of the total expired time, resetting if needed when notifications come in. its a bit more work but it minimises the blocking behavior of the node and when run on a multi-core machine the overall resolution of detecting a timeout improves.
• Customising the number of threads LabVIEW allocates per Execution System per priority. The link I gave has information about this. This should allow you to programmatically increase the number of Notifications you wait on - however I don't know the "secret sauce" as to whether LabVIEW's parallel FOR loop will try and utilize all available threads in that Execution System / priority. You could benchmark it however to determine the improvement.
• Splitting your notifications into groups (via more than one typedef control) and wrapping groups in VIs that run in different Execution Systems (any except User Interface) and priorities. This will give you some immediate gains (since the threads in other execution systems will probably be idle) but you will need to re-evaluate this balancing act every time you increase the number of refs in the arrays. 

[mcduff]

@tyk007 off-topic but everybody at LAVA calls NI the dark side, first time I've seen the reverse.

[tyk007]

Haha I got into the habit of calling the other side from where I was posting the "dark side" Unfortunately our work proxy blocks LAVA otherwise I'd frequent it more often.

[Fyzikfyzik · Accepted solution]

So I've been studying parallelism and it seems all I needed to know is that if you wire the mysterious P terminal on for loop, LabVIEW makes parallel instances independently of number of cores, hopefully splitting it between the cores in the most efficient way. I've made a snippet below with Wait blocks, it makes no sense but works the same as with Wait on Notification. The solution on the right is the equivalent of the one on the left.

[Fyzikfyzik]

The timeout terminal is not connected but the notification terminal has the information of the timeout itself since it returns default value only when timeout occurs.

I am not sure if I understand your idea but I already found the solution, you can see it in this thread. Turning the parallelism on and wiring P and N terminal with number of iterations makes it fully parallel.

[Yamaeda]

As always, it's good to know how/why things work as they do. A parallel loop is automatically set to the number of cores (threads?) since it's safe and should yield benefits. Depending on what's happening inside that can of course vary greatly. With a simple Wait a single core can handle lots of 3 sec waits with decent precision. If you'd done some 2048 points FFT which is already parallel you'd simply lose performance due to overhead.

But yes, wiring P allows you to control the number of threads which can be great if performing slow commands, like opening 8 serial ports or something.

/Y

[altenbach]

Yes, you can define the number of parallel instances in a parallel FOR loop, but I wasn't sure how far you want to take this. It only scales in a limited range. The number of parallel instances is limited (default is 64, can be change to 256 hard max).

I am pretty sure there is a better, infinitely scalable solution. 😄