Why does priority of NON RUNNING vi affects execution time of subVI?

[CoastalMaineBird]

If I set the "wasteTime.VI" as sub-routine, the undesirable effect goes away!

Hmmm - that works for me too. In the real case, the "Object" has a subVI which has a subVI. I have to set those to subroutine as well, because a subroutine cannot call a non-subroutine priority VI. But I think that's OK, in my case.
If I do that, I get times of 8-9 mSec on the real object!

I didn't try subroutine because I thought it would be the same as the other above-normal priorities - guess I was wrong.

Still don't understand why, though.

Thanks for your eyes!

[Ben]

No Problem!

If it wasn't for the "Big Boys", I would have given up playing in this sandbox along time ago!

I'll try to rationalize this behaviour in the background.

I'll post if I think of something.

Ben

[Greg_McKaskle2]

> Hmmm - that works for me too. In the real case, the "Object" has a
> subVI which has a subVI. I have to set those to subroutine as well,
> because a subroutine cannot call a non-subroutine priority VI. But I
> think that's OK, in my case.
> If I do that, I get times of 8-9 mSec on the real object!
>
> I didn't try subroutine because I thought it would be the same as the
> other above-normal priorities - guess I was wrong.
>
> Still don't understand why, though.
>

I can explain why the subroutine will be faster than the other
priorities, so I'll do that first.

Subroutine VIs are compiled with less code. They are not debuggable,
their panel is totally ignored, even if open, they cannot be suspended,
and they do no scheduling (which is why they cannot contain or call
asynchronous functions). So subroutines are compiled more like a single
blob of code with most of the niceties turned off.

Priorities on the otherhand, have little to do with how the VI is
compiled, but with which OS thread os asked to execute. Priorities do
not speed things up, they just determine who takes cuts in line. They
don't work like an accelerator, they work like a horn.

Regular VIs are greatly affected by whether the panel is in memory and
whether the panel is open. I suspect that you have eliminated these
affects, but it is always worth restating. After any of these changes
to priorities, perform a Save All before taking any timings.

So, what happens when a VI is shared between multiple callers at
different priorities. The subVI can only be run by one of them at a
time, assuming it isn't reentrant, and if its preferred priority is set
lower than one of the callers, it will be boosted to match the higher of
the callers.

I'm not totally sure when the boosting takes place. If this hapens at
reserve time, then it shouldn't affect runtime performance like you
describe. If it happens on each subVI call, then it will have some
effect, though I wouldn't expect as much as you describe.

For now, it sounds like you might want a subroutine anyway, and I'll ask
around at work.

Greg McKaskle

[CoastalMaineBird]

Regular VIs are greatly affected by whether the panel is in memory and whether the panel is open.  I suspect that you have eliminated these effects, but it is always worth restating.  After any of these changes
to priorities, perform a Save All before taking any timings.
--- I understand that, and yes, I did save things and close the front panels.

The subVI can only be run by one of them at a time, assuming it isn't reentrant, and if its preferred priority is set lower than one of the callers, it will be boosted to match the higher of the callers.
--- The subVI was set to "normal" priority, excluding the experiments.
So, you're saying that the "object" subVI in question was boosted to above-normal prio
rity because one of it's callers was above-normal. Fine.
That doesn't explain why it then took LONGER to execute. Is there a penalty for calling a higher-priority VI from a lower one? Apparently so. Maybe some extra trips thru the scheduler?

I didn't test it, but I'd guess from what you're saying that if I boosted the priority of the tester, the penalty would have disappeared.

Regardless, I am working fine with subroutine priority, but I want to understand things better. I've read the app note (#114, I think), but I can't see a connection between the words there and my situation here.

[Ben]

I reviewed that note while talking to you yesterday and yes, there is not a clear explanation of what you are seeing.

I believe your guess re:setting the tester higher was one of the things I tried fast yesterday and I believe it did improve performance but you should verify.

I am leaning toward this being the OS related. It's almost as if the the OS is giving the higher prio queue a chance to "change its mind" about if it want to run. After a short (but measurable delay) it does not find anything to do with that queue and goes back to doing the less important stuff, i.e. your test.

That is about as far as i can go with explaining this behaviour. I gave up studying OS with VMS 4.X and I really do not miss it at al
l.

Ben

[CoastalMaineBird]

I am leaning toward this being the OS related.

For what it's worth, I DID verify that setting the priority of the tester to match the dummy caller restores the normal execution time.

Also for what it's worth, I ran the same tests on Mac OS X. The same behavior results, except that the difference is more extreme (10 mSec --> 55 mSec). But matching priorities works there as well.

More information:
The dummy caller is not even necessary to prove the point - like Greg said, it is boosting the priority of the VI it calls, even though it doesn't execute.
Without the dummy even loaded, if you set the priority of the time-waster VI to HIGHER than the tester, the penalty is imposed.


>The rule as I understand it:
A time penalty is imposed when a VI calls a higher-priority VI. (Subroutine priority excepted).

[Ben]

THat was what I needed to hear!

We maybe looking at "priority Inversion" as discussed in this link.

http://zone.ni.com/devzone/conceptd.nsf/webmain/3EF39F7BC420236B862569A80078B9ED?opendocument

BTW The OS is off the hook.

So the issue may not be the speed at which the sub-VI executes, but actually the overhead required in bumping your caller's priority to a high enough level to get at the the sub-VI and then dropping it back down again after the sub-VI completes!

What do you think?

Ben

[CoastalMaineBird]

Thanks for the link, though I'm not sure it applies.
1... I'm not using RT things - there's not an RT board present.
2... These shared resources include global variables, non-reentrant subVIs,... -- So a non-reentrant subVI is a "shared resource".

3... Priority inheritance allows the lower priority thread to temporarily �inherit� the time-critical priority setting, long enough to finish using the shared resource and to remove the protection. Once the protection is removed, the lower priority thread resumes its original lower priority setting and is taken off of the processor.
--- I suppose the subVI could be a "shared resource", even though one of the sharers is
not running. But if that's what is happening, then you are suggesting that the process of changing priorities up and back down adds 10 mSec to the execution time.

--- However, the tester calls the thing 1000 times, so I suppose the extra 10 mSec is divided by 1000, so it's 10 uSec per call - that seems believeable.

--- And since subroutine-priority avoids the scheduler altogether, it's not subject to this priority inversion.

--- And when I made the subVI re-entrant, it's no longer a "shared resource" and is not subject to this priority inversion.


--- OK, I'm convinced you're on the right track, assuming this note about RT applies to the plain LabVIEW as well.

[CoastalMaineBird]

The problem with this idea is that in the case where I don't load the dummy caller, the resource is not "shared" - there's only one call to it! Apparently the fact that the subVI is higher priority is enough to get it to be declared "shared", even though there's no competition for it.

Do you agree with that reasoning?

[Ben]

100% sir!

I think the observations you have made are consistant with your wrap-up.

The 2 guesses we are making are;
1) Priority inversion is not limited to LV-RT.

2) A VI calling a sub-VI with higher priority is enough kick in the priority promotion.

Now that you point it out, I did not stop to think about that link being targeted at RT. Aside from the "TC-Loop" feature of LV-RT and the way you have to handle memory, I have started to think of LV and LV-RT being the same thing!

I'll have to get myself assigned to one of those non-RT apps just to clear the cob-webs :<)).

Unless I hear other wise, "I think you've got it!" (Proffessor Higgin, My Fair Lady circa 1960).

B
en