LabVIEW
Why aren't most vi.lib VIs reentrant?
What would you perceive to be the advantage?
These typically don't store data just process some input to create an output. If you have 20 mean.vi on your diagram would you really prefer to have each one seperately in memory. Seems like a waste of resources. Also, you cannot debug reentrant VIs with the typical tools.
Please explain your reasoning. 🙂
These typically don't store data just process some input to create an output. If you have 20 mean.vi on your diagram would you really prefer to have each one seperately in memory. Seems like a waste of resources. Also, you cannot debug reentrant VIs with the typical tools.
Please explain your reasoning. 🙂
@Ken Pietrzak wrote:
In the process of making some of our VIs reentrant, we discovered that most of the VIs in vi.lib are not reentrant. For example, mean.vi and it seems that all of the other analysis VIs are not reentrant. Is there a reason for this? Would there be any harm in making these VIs reentrant?
Why would you want to make them reentrant? Reentrancy has two advantages: If you have local data storage (shift registers) each instance will have its own data storage space. This can be a drawback too, since you can't share data between different calls to the same VI such as is used in LV2 style functional globals. Another advantage is that LabVIEW can call a reentrant VI multiple times in parallel.
There are however also definitively serious drawbacks to this. You can't debug reentrant VIs: no single stepping, no data probes, no nothing. A reentrant VI requires more resources in LabVIEW for its management as it has to be prepared for multiple parallel execution even if that never occurres. Last but not least as long as you have not multiple CPUs the seemingly parallel execution of reentrant calls to the same VI has little or no effect in the overal performance of your application. Even with multiple CPUs LabVIEW is already so highly capable of parellel execution that you still won't see any performance gain by reentrant VIs in most cases and even could loose performance due to the extra overhead of managing reentrant VIs.
Basically reentrant settings only make sense if you have a VI which needs to have its own instance local data or in the other case for VIs which for whatever reasons take a long amount of time with at least part of that time being about waiting for something to happen and you want to be able to call this VI from several places at the same time eventhough earlier executions haven't finished yet. A mean function is all about computations. No waiting whatsoever and no local data at all. Having LabVIEW to schedule between splitup calls to such a subVI for multiple callers is likely to end up slower than letting caller one finish the execution for this subVI before caller two can invoke it. After all the single CPU is mostly busy calculating stuff and having to switch between several data arrays because execution of the function is interleaved has a much higher chance of trashing the memory cache which is a costly operation.
Rolf Kalbermatter
Message Edited by rolfk on 06-09-2005 02:15 PM
You really should never change any of the VIs in vi.lib.
Since those are that's the standard set of VIs that ship with LabVIEW, any changes you make could have negitive effects on any VIs that use them as subVIs.
If you see a need or want to change a vi.lib VI, always save it elsewhere (user.lib) with a different name. Thias way you won't break anything that depends on the original VI.
Ed
Since those are that's the standard set of VIs that ship with LabVIEW, any changes you make could have negitive effects on any VIs that use them as subVIs.
If you see a need or want to change a vi.lib VI, always save it elsewhere (user.lib) with a different name. Thias way you won't break anything that depends on the original VI.
Ed
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
@Ed Dickens wrote:
If you see a need or want to change a vi.lib VI, always save it elsewhere (user.lib) with a different name. Thias way you won't break anything that depends on the original VI.
Good point ED. Not only that, but next time you upgrade LabVIEW or move your project to a different computer, things will be back to square one, breaking everything that depends on changed vi.lib VIs. 😞
The vi.lib is off-limits!
A better approach to calculate the mean in LabVIEW itself would be to use Add Array Elements and dividing the result by N. This sure enough should be about as fast as any C code you can come up with.
@Ken Pietrzak wrote:
Thanks folks for your responses. We generally use multiprocessor computers for our applications. We want to be able to run several processes in parallel to make use of those processors. I assumed that making any common subvi calls from parallel processes reentrant that execution time would drop since these subvis would be run in parallel especially when cranking on large amounts of data. So I also would have expected that NI VIs in vi.lib would be reentrant by default. I guess I was wrong. I did not realize the overhead in creating multiple instances of these VIs would outweigh the gain from parallelism. To verify what you folks were saying, I copied the mean.vi, made it reentrant, and placed it in parallel loops. I was surprised to find out that no matter how large the array size or how many loop iterations I used, the non-reentrant version of mean.vi was always faster than the reentrant version. So I guess we need to really think about which subvis to make reentrant in our code.
I also tried replacing mean.vi in each loop with my own code (just summing off a shift register in a loop and dividing by N after the loop) and found that to be exceedingly slow. It's got me thinking now that I may need to convert some of our processing intensive image processing code to C to be called by a dll from LabVIEW to speed execution of that code.
Rolf Kalbermatter
Message Edited by rolfk on 04-13-2006 05:05 PM
LabVIEw 8.5 has a new setting for reentrant VIs called "Share clones between instances". It is a middle thing between non-reentrant and reentrant and should suffice for most cases but uses less resources than reentrant. But unless you really really have multiple processors and are very cautios how you program your code, you won't see much of a speed improvement even with fully reentrant subVIs.
@Phamton wrote:
I'm running into a similar issue as Ken. There are several library VIs I use in data processing (1D polynomial evaluation, for example, to convert from binary to scaled data) that I would like to use in parallel to take advantage of multiple processors. If I make a copy of the library VI, make my copy reentrant, then run it in parallel paths everything should be all right? (i.e. is it safe to change the library VIs to reentrant?)
Rolf Kalbermatter
