Execution System Oddness

[Gary Rubin]

I was once told here on LAVA (by rolfk?) that data transfer overhead is not dependent on Labview Preferred Execution Systems. In other words, if a caller is running in one execution system, it should not matter whether a subvi is running in a different execution system. At least, that's how I understood it. Given that,

I'm a little puzzled (and alarmed) but what I've just discovered. I was doing some experimentation to figure out whether any performance can be gained by tweaking the manner in which subVIs are called/configured. The subvi's are very simple, just summing an array with itself.

The toplevel vi is Time Critical Priority with debugging off.

The subvi in the 1st panel is always Normal Priority, Same a caller, with debug turned off.

I've varied the Preferred Execution system of the toplevel and the subvi in the second panel, and noted the ratio of the execution times for each of the test loops.

Here's what I've seen so far.

I also did a single test in which I set the toplevel priority to Normal (like the 2nd subvi), but still got the large disparity when crossing Execution Systems.

Can anyone duplicate?

What gives?

Gary

EDIT: Fixed embedding of attachments.

Benchmark2.zip

Edited July 16, 2009 by Gary Rubin

[Aristos Queue]

I don't think it has anything to do with data copies. I'll bet it is just the time needed to do the thread swapping. If you are "same as caller", then the same execution thread can run the subVI and you can just keep working. If you force a change of execution systems, the VI has to stop, put itself back on the run queue, and wait for a thread from the chosen execution system to come along to execute the subVI. Then it has to go back on to the execution queue to switch back when returning.

[Gary Rubin]

I don't think it has anything to do with data copies. I'll bet it is just the time needed to do the thread swapping. If you are "same as caller", then the same execution thread can run the subVI and you can just keep working. If you force a change of execution systems, the VI has to stop, put itself back on the run queue, and wait for a thread from the chosen execution system to come along to execute the subVI. Then it has to go back on to the execution queue to switch back when returning.

So, is the takeaway that a really fast, tight loop should only contain subvi's in the same execution system? What about the fact that "same as callers" seemed to be a little bit slower than explicitly setting the subvi to the same execution system as the caller?

[Gary Rubin]

Here's some more information.

Top Level Execution System: Instrument I/O

Panel1 SubVI: Same as Caller

Panel2 SubVI: Other 2

Profiler Off: Frame2/Frame1 Execution Time = 66.7

Profiler On: Frame2/Frame1 Execution Time = 8.3

Observation: Profiler slows down Frame1 more than it slows down Frame2?

Profiler Results (multiple tests)

Panel1 SubVI Total Time (ms): 406 515 547 640 422 453

Panel2 SubVI Total Time (ms): 781 765 875 844 765 937

Observation: According to Profiler (so take numbers with a grain of salt), the subvi running in the different execution system takes longer. AQ, is this consistent with your assumption that the added time is associated with thread swapping? Does the thread swapping time get attributed to the subvi by Profiler?

Question: What does this all mean (aside from the fact that we should be very careful with execution system settings for some cases)???

[ragglefrock]

Here's some more information.

Top Level Execution System: Instrument I/O

Panel1 SubVI: Same as Caller

Panel2 SubVI: Other 2

Profiler Off: Frame2/Frame1 Execution Time = 66.7

Profiler On: Frame2/Frame1 Execution Time = 8.3

Observation: Profiler slows down Frame1 more than it slows down Frame2?

Profiler Results (multiple tests)

Panel1 SubVI Total Time (ms): 406 515 547 640 422 453

Panel2 SubVI Total Time (ms): 781 765 875 844 765 937

Observation: According to Profiler (so take numbers with a grain of salt), the subvi running in the different execution system takes longer. AQ, is this consistent with your assumption that the added time is associated with thread swapping? Does the thread swapping time get attributed to the subvi by Profiler?

Question: What does this all mean (aside from the fact that we should be very careful with execution system settings for some cases)???

I would generally only select differenct execution systems for subVIs that will run continuously in parallel with other operations, not subVIs that simply process data and return immediately. If you, for instance, create a subVI out of a consumer loop in a producer/consumer architecture, that might be a good candidate for a separate execution system. But that's probably really only necessary once you start developing a very parallel system.

[Gary Rubin]

I would generally only select differenct execution systems for subVIs that will run continuously in parallel with other operations, not subVIs that simply process data and return immediately.

Of course, but unless that Subvi is called dynamically, someone's got to call it, and if they're calling two different subVI's one of them is going to be in a different executions system.

See figure 7. This is what I'm envisioning.