12-28-2022 03:56 AM
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:
or in this way:
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?
12-28-2022 04:42 AM - edited 12-28-2022 04:48 AM
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.
12-28-2022 06:40 AM
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?
12-28-2022 09:18 AM
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
12-28-2022 09:50 AM - edited 12-28-2022 09:55 AM
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?
12-28-2022 09:50 AM
@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.
12-28-2022 05:11 PM - edited 12-28-2022 05:20 PM
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.
12-29-2022 04:33 AM - edited 12-29-2022 05:05 AM
My M DVR consists of 22 clusters. In general, clusters are numbers and arrays.
the following VI modifies only one cluster (simplified version):
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
12-29-2022 05:06 AM
My M DVR consists of 22 clusters. In general, clusters are numbers and arrays.
the following VI modifies only one cluster (simplified version):
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
12-29-2022 09:26 AM
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).
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.