LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Global Variables Are Better than Functional Globals - So There! :-)

Solved!
Go to solution

 


@SteveChandler wrote:

 Globals in and of themselves are not the problem.

 


You are correct.

 

I don't think anyone would want to argue that point.

 

 

______________________________________________________________________
0 Kudos
Message 11 of 51
(1,526 Views)

I did start to do a benchmark using a large data set. The global failed so severly, I didn't continue.

Benchmark.PNG

This code took >5000 ms to complete.

The same with an Action Engine was below resolution (returning 0 or 1 ms).

 

Benchmarking was done in 7.1. Code is attached in the zip file.

 

Felix

Message 12 of 51
(1,468 Views)

Globals provide memory space for writing reading data. Should you drop two or globals down that do writes or reads or write-read or read-write question is what the order performed.

 

The use of a sequence structure on your block diagram gives exclusive processing to the sequence structure (no other Block Diagram code run till that sequence structure completes (try it and see). Put more and more Globals in sequence structure and your code get slower and waste processing defeating the concept of data dependancy.

 

Well maybe Global aren't bad but sequence structure to handle globals, well there's a multitask multithread... speed hit.

0 Kudos
Message 13 of 51
(1,459 Views)

@richjoh: I think you completely miss the point. The sequence is just for isolating the 'Index Array' section of code to do some benchmarking. This would never be code of an app, it's just benchmarking (see this of Damien's Developments or this community nugget by tst). If you are still not convinced, please use the code attached on my previous post and notice that the code for the AE is identically using the sequence structure, but more than 1000x times faster.

 

Now I'd like to scientifically discuss the results of this benchmark, which in fact did surprise my by the huge (magnitudes) the AE did win against the global.

 

Concerning my benchmark, I reasonend that the one rule to follow when asking for good performance is to keep data on the wire.

One might ask, why the global is put outside the foor loop. But this is intentional for two reasons:

  • The idea of a 'global' (including FGV and AE) is to access it at different sections of the code.
  • Having it outside, I would benchmark the performance of the wire and not the global.

A second objection against the benchmarking code would be, that I might get the same bad result if the AE would return the full data set and the indexing would take place outside the AE (a simple data access FGV with get/set). But this would imply to force a bad coding practice! AEs allow for encapsulation (a concept known in OOP with strict accessors like in LVOOP).

 

Doing some more reasoning about this, the codes output would change in the situation where some code would write at the global in the meantime. Yes, we all know this is the very bad situation of a race-condition. But this disallows any compiler optimization similar to 'constant folding'.

So in fact, every loop iteration, using a global I need a full copy of the approximately 4MB data that is stored in the global (so in the meantime, any other process can use the global safely). So I need to move around 4GB of data. Using an AE, the contrary happens, the subVI boundary prevents any code to access the same data (it's on the wire), so the compiler can optimize and reuse the buffer. In this situation, only 4KB need to be allocated (would mean a theoretical performance improvement of E+6).

So to summarize, to mechanisms work in favour of the AE:

  • the native protection at the subVI boundary (semaphore/mutex) against parallel data access
  • (and thus allowing compiler optimizations) a buffer reuse

This all can be condensed into points:

  • Keep data on the wire
  • AEs are natively keeping it on the wire

I leave the LVOOP benchmark as a homework, but here is my predictions:

Additional penalties might happen when there is other data (like a string) on the objects private data cluster forcing a buffer reallocation. The general OOP-penalty of overhead due to ynamic dispatching is absolutely neglectible.

In basic situations (like the benchmark code), we will find a very similar performance as with the AE, as all data is kept on one wire. Using LVOOP in a large scale app, this won't be true as in all the code the class wire is running through, we need to eliminated all branching that kills performance. In an AE, the data wire is encapsulated as well, so only the AE must be improved, tested and only the AE coder must know about performance strategies. The very last point (only the AE coder must know about performance implications) would push any good LV architect on using AEs for large data sets only.

 

 

Felix

Message 14 of 51
(1,441 Views)

Oh I forgot to mention who my response is directed too, SteveChandler not F Schubert.

 

Schubert look at the initial post from SteveChandler. I only read the first line of your resonse and see myself addressed.... my post if for SteveChandler code only, I only glanced at your code in the pic. I could comment about your code too, but this is not the discussion.

 

And as I read more of your response Schubert, I see we are in total agreement, no need to say more.... this is SteveChandler code discussion.

0 Kudos
Message 15 of 51
(1,437 Views)

I didn't do any benchmarking. I got the information that globals were faster from this post. In fact it was that discussion that inspired this one.

=====================
LabVIEW 2012


0 Kudos
Message 16 of 51
(1,422 Views)

Do globals require the UI thread?

=====================
LabVIEW 2012


0 Kudos
Message 17 of 51
(1,409 Views)

If you move the global outside the for loop you will get much better numbers. Almost comparible to the FG. Edit: Still waiting with duct tape for Ben or Christian Smiley Happy

 

global.png

=====================
LabVIEW 2012


0 Kudos
Message 18 of 51
(1,408 Views)

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.

0 Kudos
Message 19 of 51
(1,405 Views)

 


@SteveChandler wrote:

Do globals require the UI thread?


 

In What Thread Do Local and Global Variables Execute?

Message 20 of 51
(1,401 Views)