ExpressionFlow is back

[Tomi Maila]

Since I founded Agile 4 in the beginning of the year, I have not had much time for LabVIEW development and my blog on ExpressionFlow. Recently I have had some time to get myself familiar with the new LabVIEW 2009 features and I really hope I will be able to again use LabVIEW as much as possible.

I just posted a new post Limits of for-loop parallelism to ExpressionFlow, for the first time after a short silent period. I try to keep up posting interesting stuff more regularly in the future.

Cheers,

Tomi

[Aristos Queue]

URL isn't quite right in the link. Here's the fixed link:

http://expressionflow.com/2009/09/15/limits-of-for-loop-parallelism-how-parallel-they-really-execute/

[Mellroth]

URL isn't quite right in the link. Here's the fixed link:

http://expressionflo...really-execute/

Hmm, fixed you say

Seems like a bug, that inserts <B></B> directly after the "exp", even when you add an explicit link.

/J

[Tomi Maila]

Hmm, fixed you say

Seems like a bug, that inserts <B></B> directly after the "exp", even when you add an explicit link.

/J

Seems like LAVA is censoring expressionflow content. So just type expressionflow.com on the URL bar.

[Anders Björk]

Seems like LAVA is censoring expressionflow content. So just type expressionflow.com on the URL bar.

Tomi can you comment on the rationale for wiring the constant 20 to the P-node on the for loops?

Edited September 16, 2009 by Anders Björk

[Tomi Maila]

Tomi can you comment on the rationale for wiring the constant 20 to the P-node on the for loops?

It is just a random number much enough greater than the number of development time specified loop instances, which in my example was 10. Practically I am requesting the 20 iterations of the for loops to be executed by 20 parallel workers. If the iterations would really be all parallel, then there would not be dead-lock. Please check the comments on the blog post for Marys more detailed insight.

[Tomi Maila]

Mary Fletcher from NI R&D explained the implementation of the parallel for-loops in more detail in the comments of the blog post.

The number of loop instances specified in the loop configuration dialog is the maximum number of workers that could work on parallel for executing the loop iterations. The actual number of workers is specified at runtime to be the value of P terminal, if it is smaller than the maximum number specified in the configuration dialog.If P is greater than the maximum number, then the maximum number of workers is used instead. If P is not connected, LabVIEW uses as many parallel workers as there are logical processors in the machine,however never exceeding the maximum number of workers specified at runtime. If there is a parallel loop within another parallel loop, only the outer parallel loop will be parallelized. This will change in LabVIEW 2009 SP 1 where LabVIEW will parallelize both loops resulting in P*P' workers for the inner loop. This limitation of parallel loop within another parallel loop does not apply to subVI calls within parallel loop subVIs having parallel code themselves. If the number of workers specified at configuration time and at runtime both are equal or grater than the number of iterations, all the loop iterations will then execute truly in parallel and you can safely use design patterns such as producer-consumer pattern between loop iterations.

Thank you Mary for this valuable information.