LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

one or two separate in-place element

Hi everyone, I have a question about In-Place Element Structure.

 

I should use this structure into a time loop and in my application there are many cycles...so they compete with each other

 

I'm not sure if it's better to write the code like this:

 

Untitled2.png

 

or in this way:

Untitled3.png

from a logical point of view I think the first version is better. Is there a difference between the two uses? or is it the same? 

 

 

0 Kudos
Message 1 of 13
(1,807 Views)

As always, it depends really!

 

Are you doing anything significant between the different IPEs? And I mean with significant something that takes more than a few CPU cycles! An add would hardly fall into this category unless it is on a large array. A single multiply neither, but many of them or on an array might actually be significant. A trigonometric function or any other non-linear function quickly could mean significant computation that could benefit from separating it out of the IPE.

 

Using multiple IPEs has some extra overhead as LabVIEW needs to acquire (and potentially arbitrate for) and release the semaphore protecting the DVR. But if you do any significant work between those IPEs, it gives other parts of your application a chance to access that DVR, so it may in the end result in a more responsive and performant application.

 

If there is no significant work being done between those IPEs or there is no concurrent access to the DVR however, multiple IPEs would only cause performance degradation.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 2 of 13
(1,796 Views)

I'll chime in with questions about determining the "Depends" Rolf alluded to.

 

In many cases an IPE might be unnecessary in @2010 and later.  Since 2010 the compiler has gotten smarter and smarter about optimizing out unnecessary buffer allocations.  ( search "magic pattern" and "Compiler Optomizations")

 

In the case of a DVR you do still need to access the data values in an IPE.  However,  the point of a DVR is not to optimize code execution but, to reduce data copies.  This begs the question of: "what data is protected by your DVR such that multiple independant methods could be desired?"  Perhaps you have overcoupled the data and need multiple DVRs?  Maybe you need a class or action engine instead?

 

So what's the data and what do you want to do with the values?


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 13
(1,765 Views)

thanks for the replies. I reply in one message

 

My operations are simple and not complex: cascade linear operations (at most some division)

 

from the answers I believe it doesn't need separate IPEs. I thought of separating them because some values that I modify I use them in other VIs

 

should I try to see the time it takes to run in two different way? I could try one of two ways

 

- https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P839SAC&l

- Tools->Profile->Performance and Memory

0 Kudos
Message 4 of 13
(1,752 Views)

Your question is not really about IPEs in general, but very specifically about DVR IPEs.

 

If they have sequential data dependency as shown, they cannot "compete with each other", whatever that even means.

 

To answer your question, we need to know where else you are accessing that DVR. Are some of these accesses "read only"? (This can be configured to allow parallel access!) Do all of them modify the DVR data?

 

The main purpose of the DVR IPE is to protect from concurrent write access, so while one is executing, access from all other parallel code (e.g. in other loops running in parallel) is blocked and these other code sections need to wait. Of course the locking mechanism is not "free", so if you lock and unlock three times in a row, there will be more overhead and if some other code section would grab access to the DVR between any of your successive structures, the code might stall for a while. It really depends on the overall program architecture.

 

If you constantly reading the DVR data elsewhere (read only mode), the upper code will have access to the intermediary values that exist between the three instances. Not sure if that is even desired. Performance wise, the lower code will be better. (1) only one access to the DVR. (2) all processing code in one structure allows more compiler optimizations by eliminating the artificial synchronization boundaries that exist if you have three isolated code islands.

 

Once you give a much more detailed description and even attach a simplified version of your code, we can give more specific advice. Is there a reason you are even using DVRs? How big are the contents?

0 Kudos
Message 5 of 13
(1,746 Views)

@undique wrote:

thanks for the replies. I reply in one message

 

My operations are simple and not complex: cascade linear operations (at most some division)

 

from the answers I believe it doesn't need separate IPEs. I thought of separating them because some values that I modify I use them in other VIs

 

should I try to see the time it takes to run in two different way? I could try one of two ways

 

- https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P839SAC&l

- Tools->Profile->Performance and Memory


In general. You can optimize for either processing speed or memory cost once you have reduced the avoidable garbage code.


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 13
(1,745 Views)

I'll repeat


@JÞB wrote

 

So what's the data and what do you want to do with the values?


You have the attention of multiple Knights!  That should mean that you have presented an interesting thread.

 

Please respond. 

 

Edit @CA I am not convinced that the OP has  necessarily restricted the IDE usage to DVRs exclusively because of the reasoning I presented on data over coupling before.  One or the other, code smell ...God Object... is funking up my olfactory sense.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 13
(1,728 Views)

My M DVR consists of 22 clusters. In general, clusters are numbers and arrays.

 

the following VI modifies only one cluster (simplified version):

 

Untitled.png

when I write "in another vi" it means that there are more than one VI

 

from what I understand it's not worth separating the IPEs because the overhead cost is higher than only one. in my case the array is very small (15 elements) even if the linear functions i think last more than a few clocks

 

I would put everything in one IPE. perhaps a read-only optimization could be done but not sure about the overhead cost

0 Kudos
Message 8 of 13
(1,625 Views)

My M DVR consists of 22 clusters. In general, clusters are numbers and arrays.

 

the following VI modifies only one cluster (simplified version):

 

Untitled.png

when I write "in another vi" it means that there are more than one VI

 

from what I understand it's not worth separating the IPEs because the overhead cost is higher than only one. in my case the array is very small (15 elements) even if the linear functions i think last more than a few clocks

 

I would put everything in one IPE. perhaps a read-only optimization could be done but not sure about the overhead cost

0 Kudos
Message 9 of 13
(1,683 Views)

One glaring problem I see are also some sort of race conditions. For example if the "Temp" is modified elsewhere while the "linear function" executes, the cluster will have inconsistent values, with Temp(new) and [Tavg, Tmax, Tmin] based on Temp(old).

 

altenbach_0-1672327460665.png

 

Maybe you should implement the linear function as a subVI (possibly in-lined) with only the DVR as input/output? Maybe not?

It is difficult to give advice based on tunnel vision of a single picture.

 

Message 10 of 13
(1,662 Views)