single core

[altenbach]

---

@nano_era wrote:

Like I said, the UI is slow to start and to make rapid updates.

---

What is your definition of "rapid updates"? How much data? Graphs? Charts?

Also make sure that you don't set a high execution priority for any of the VIs.

That would give the UI interactions a lower priority, making it appear sluggish.

[nano_era]

The execution priorities are set to normal. I don't think that is an issue.

I am displaying regular numeric indicators, bars, a graph. But there are many controls which are used to calculate the values of those indicators. I guess those calculations and the UI are struggling with only one core.

Is there an example of a program that has 2 versions, a multi core version and a single core version that I could refer to? Is that something that is even common in LabVIEW?

[altenbach]

---

nano_era wrote:

I am displaying regular numeric indicators, bars, a graph. But there are many controls which are used to calculate the values of those indicators. I guess those calculations and the UI are struggling with only one core.

---

Are all these controls needed and operated by the user or are most of these used as local variables?

Also look for over-use of property nodes (some programmers abuse e.g. value property nodes as "variables"). They are synchronous and force thread swaps, so they are very demanding on the system.

[altenbach]

---

nano_era wrote:

Is there an example of a program that has 2 versions, a multi core version and a single core version that I could refer to? Is that something that is even common in LabVIEW?

---

LabVIEW is typically smart enough to recruit all possible cores if sections can be done in parallel. Unless your program is highly optimized for multicore (and I don't think it is), leave it to LabVIEW to figure things out.

There should be no difference in code. You cannot optimize for single core.

[nano_era]

Yes, they are all needed. The user may or may not use them all, but the purpose of this program is to simulate all of these controls and indicators. The program does not use local variables, but only global variables. These variables are used in several different VIs for different calculations, with some of them being read in 2-4 different instances. Right now I am not aware of another way of doing this without using globals. I know how to pass these values into sub VIs without using globals, but not into other VIs that are not sub VIs.

[Ben]

See this Nugget on Action Engines to learn how they can be used in place of globals and the benefits of using them instead of globals.

Ben

[nano_era]

Thanks for the link. That seems very interesting, but I am still not exactly sure if that can serve my purpose. Can I use them to write a value in one VI and then read that value in several other VIs? And does it do it better or faster than using global variables? Because global variables do work for what I am doing.

[Mark_Yedinak]

Yes, you can. Global variables are not the speediest because of their underlying implementation. In addition, they are not good to use because if you are not VERY careful it is very easy to have race conditions in your code. This can very easily create bugs and unexpected behavior in your code. They are also very difficult to debug. Action Engines help to protect against this since they create a single interface into your "global" data. LabVIEW will take care of race conditions by only allowing one piece of code to access the single AE VI at a time, even if it is being called from multiple places at the same time. You can still get into a situation where you may not read the correct value since you could be writing to this in multiple places. A better way to pass data is using queues. AE are very good though if your data is very large.

[Ben]

Mark hit on some of the highlights in that linked Nugget. (Thanks Mark! )

Globals have amny other draw backs in addition to the possilbe race conditions.

1) Globals can not be updated "in-place" and data copies are required >>> slow performance >>> memory pigs

2) Every instance of a global requires its own memory location so if you read the global in 20 places, 20 copies.

3) Indeterminent performance. I never got a good answer as to why they sometimes stall a thread but they do (did) and I still avoid them like the plague.

If you want to read more about globals both good (ahem cough cough)  and bad then check out this thread where we discussed globals to death.

Ben

[nano_era]

That looks like a good thread. From reading some of it, I see that globals can be useful. I am still not sure if I need to replace mine.

For example, if I have one global write in one VI, which is connected to a knob on that front panel, which is read into lets say 2 other VIs. The read globals on those VIs are used for separate calculations, from which the results are displayed on their respective front panels. So if I have all three front panels open and running, I can adjust the knob for the write global variable, and see the change on all three front panels. Also keep in mind that the knob is not just to used write to the variable but is also used in a calculation and then displayed in its own front panel. So one knob is causing indicators on 3 front panels to update. Suppose I must have it done that way and do not want to just put them all in one VI and indicator.

Is this a good reason to use global variables? Would there be a better solution?