04-22-2011 01:05 PM - edited 04-22-2011 01:08 PM
@richjoh wrote:
Uhhh? did you say faster, what line impies that... cus I read this from the link you provide.
"Status: Declined
A quick conversion tool would imply that switching from global variables to functional global variables are better (e.g. reduce code overhead, race conditions) when they are not specifically."
appear to me not better maybe specifically.... Try something whenever possible, write code using your described globals methods, see if it runs faster, multithreads, multiprocess faster and your code debugs faster.
See the footnote in the first reply from Aristos Queue
* actually, the functional global will perform worse. It has higher overhead in that case.
04-22-2011 01:10 PM
@richjoh: Thanks for the clarification. Then I just hope these links will provide some value for the occasional reader.
@Steve: As far as I know, globals do not need the UI thread (as long as they are not opened). I think there was a thread where AQ did explain the inner workings on LAVA, where he did also state that globals do require some buffer less than whatever, hence they'd be faster.
Your lastest post does prove my predictions, however I made the assumtion:
One might ask, why the global is put outside the foor loop. But this is intentional for two reasons:
It's sad that this idea is declined now. I'd advice to vote for it because the very reasons I explained in my previous posts.
Felix
04-22-2011 01:28 PM
@f. Schubert wrote:
It's sad that this idea is declined now. I'd advice to vote for it because the very reasons I explained in my previous posts.
Felix
I might try to implement that via scripting and the right-click framework. But I don't have any experience with either.
04-22-2011 01:44 PM
Scripting is easy. Just make a template for a Get/Set AE. Then just replace (use one of the replace methods) the data-control/indicator of the AE template with the one of the global.
I was thinking the same (do it on our own). I could get that part tomorrow coded in 7.1, so working for everyone. Integration into RCF is up to you unless someone else is volunteering. Please let's do this on LAVA so we can put it under BSD license (or other if you prefer). Give me a PM if you'd like assistance either using NI account or LAVA (Blackpearl).
Felix
04-22-2011 02:49 PM - edited 04-22-2011 02:54 PM
SteveChandler, oh you mean this quote "
* actually, the functional global will perform worse. It has higher overhead in that case.
". No wonder I missed it, its so small. hey ever ask Aristos Queue to prove his statement. I never take someone's word it must be conherent at least in my mind.
F Shubert, I think you might have missed the point though on my original post. SteveChandler code uses sequence structure and error cluster to attempt to replace his FG. OK OK. Not sure your code help this discussion, no need to digress off topic, talking about your code...and not....SteveChandler issue.
Again repeat, in case of no error cluster wired to sequence, using lots of sequence structures on the same BD and they don't run at the same time (the OS/cpu determines what sequence structure get run first). Any LV veteran will tell you use sequence structure only when needed...but first understand what they are used for and functionality... from the NI LV sequence structure help
"To avoid overusing Flat Sequence structures, attempt to control the data flow of your VI by establishing data dependency or using flow-through parameters.
"
So two or more sequence structure without a wire to or from there is no data flow. When a sequence runs the rest of your block diagram halts till the sequence finishes 🙂 Write code this way (globals inside a sequence) well is no longer LV.
04-22-2011 03:00 PM
@richjoh wrote:
SteveChandler, oh you mean this quote "
* actually, the functional global will perform worse. It has higher overhead in that case.
". No wonder I missed it, its so small. hey ever ask Aristos Queue to prove his statement. I never take someone's word it must be conherent at least in my mind.
I tend to not take peoples word for anything. But there are certain people that include Stephen Mercer that when they say something I do take their word for it. But he did qualify it by saying "in that case".
04-22-2011 03:00 PM
@richjoh wrote:
"
When a sequence runs the rest of your block diagram halts till the sequence finishes 🙂
Maybe I'm not clear on what you are trying to say.
But the sequence structure does not cause "the rest of your block diagram" to halt until the sequence finishes. If there is no data dependency or anything else causing a forced order of execution, the sequence structure will run in parallel with any non-dependent code pieces.
04-22-2011 03:26 PM
@richjoh wrote:
Again repeat, in case of no error cluster wired to sequence, using lots of sequence structures on the same BD and they don't run at the same time (the OS/cpu determines what sequence structure get run first). Any LV veteran will tell you use sequence structure only when needed...but first understand what they are used for and functionality... from the NI LV sequence structure help
The point of the example was to show that global variables in and of themselves do not cause race conditions. Thanks for the link to the documentation but I think I understand sequence structures pretty well . The example I used is one where you really do need them.
04-22-2011 04:55 PM
Steve,
The issue of race conditions is of but one. Everything you proposed can be done, obviously, but Felix's example is far more telling of the inherent issues. I can't reproduce anything AQ stated where I could get better performance form a Global, but I am sure there is a case to be made that it's tru in some conditions.
Of all the reasons to not use globals, the race condition reason is probably one of the lowest on my list. Even with eorr clusters or sequence structures, etc., you can still easily get into race conditions. the overly simple example you provided is not the way the real world works. Obviously, of someone presented your example, we would say connect the wires and drop the globals. Typicallly, our race conditions come from two parallel tasks and connecting them via error wires to force order of execution is not an option.
04-22-2011 05:59 PM
@Matthew Kelton wrote:
Steve,
Scalability/the "oh crap" factor. In a lot of cases, globals are probably fine. It is certainly faster to go through and drop new globals than try to create new functional globals. Any lost performance will be minimal and unnoticeable. There will not be any race conditions. There is no need to lock globals. Then you find out that you do indeed have an issue and you need to implement something a bit more robust. Now you are spending time trying to figure out what is going on and more time going back updating your globals to functional globals to address the issue. Sometimes it's better to just do it "right" from the beginning.
Preaching to the choir. I inherited a very large application that uses global variables everywhere. I converted them all to functional globals and then added a Generate User-Defined Trace Event to the vi to do some debugging. This post was inspired by Aristos's response to an idea I posted on the idea exchange that would have made this easier for me. The idea was declined the very next day. I think this is a record. Was this really the worst idea ever posted?
One thing I constantly hear on the forums is that globals and locals cause race conditions. This post was simply to show that they do not - it is how they are used. Oh and I had to figure out how to create a global variable for my example on the idea exchange since I had never used one.