Suggestion: open a ref to Actor.vi only on first call

[drjdpowell]

AristosQueue wrote:

From the ACBR node developer:

1) Open VI Reference only requires root loop if you wire in a path. Name requires UI thread but not root loop. So it can run while a [pop up/drop down] menu is open.

2) What I actually want is 0x80, which allows me to open the reference and close it, but will not create the "1 clone per core" that we have today, which is wasteful. Don't want to leak the reference if I can avoid it, if only because that will show up as a leak in the Desktop Trace Toolkit which many people use to debug the Actor Framework.

May post more later.

I've walked down this path ahead of you.   Strictly-typed references require root loop even if one supplies the name, I'm afraid, and ACBR requires a strictly-typed reference.  I tried, but I could not find a way to launch a dynamically called VI without going through root loop.  It's a troubling issue. 

Personally, I have no problem allowing LabVIEW to handle the reference.   Protected by a "First Call" node it is functionally identical to any on-diagram subVI with "Load and retain on first call" set.  It is not a "leak", even if it looks superficially like what might be a leak.

-- James

[AristosQueue (NI)]

drjdpowell wrote:

I've walked down this path ahead of you.  

I'm stalking more developers. Please hold... 🙂

[AristosQueue (NI)]

drjdpowell wrote:

kegghead wrote:

though it is a very minor one since the dataspace for the VI is pretty trivial.

Till one reads up on other actor-focused languages, like Akka, where the overhead is 300 bytes per actor(!) and they can talk of systems using many thousands of actors.   "Actor.vi" is code+data=10k in size.

One question here: The code size isn't cloned per actor, only the dataspace. And that should get even smaller if you were to use appbuilder to strip the front panels. If we do switch to 0x80, so that we get just one clone per Open VI Ref,  I'm not claiming we'll be at 300 bytes, but based on other benchmarks I've seen, it is actually conceivable that we could be within an order of magnitude of that. Or we might still be off by a lot more. 😉 I'm more curious than anything. Have you got any numbers in this area?

[AristosQueue (NI)]

AristosQueue wrote:

I'm stalking more developers. Please hold... 🙂

And we're back...

"The customer is correct. I completely forgot about that. I'm so used to saying open by string does not require root loop but that is not true for strict VI refs."

*head bang*

Ok. So, leak the reference is the way to go? I suspect this is definitely going to have to wait for LV 2012 SP1. The Powers That Be were leary of the constant value changing this late in the game. Changing the resource accounting is never going to fly for anything less than a severe showstopper.

[kegghead]

And we're back...

"The customer is correct. I completely forgot about that. I'm so used to saying open by string does not require root loop but that is not true for strict VI refs."

*head bang*

Hehe, good to know.

Out of curiosity, is the 1 clone per core thing even on the radar at NI?

I shudder to think about the implications on server class workstations. I wasn't aware of this and our main application using my framework is often bundled with a high-end GPU systems with I think 4 or 8 CPU cores. I shutter to think of how many clones I'm spawning there if an 8 core system turns into say 16 logical cores to the OS.

Guess I ought to do more testing outside of virtual machines with only a single logical core...

-m

[drjdpowell]

AristosQueue wrote:

I'm more curious than anything. Have you got any numbers in this area?

Today, I've been trying out actor "rings" (my actor design); a long chain of simple actors that pass a message along a chain.  My crude measure of memory use (by LabVIEW in the windows XP Task Manager) gives these numbers when I run different numbers of actors:

1000 --> 233 MB

2000 --> 308 MB

3000 --> 406 MB

4000 --> 631 MB

5000 --> 795 MB

Not good.  I would be interested if someone could do the same with the actor framework.

[AristosQueue (NI)]

kegghead: I think you misunderstand... it's the 0x40 flag that says to create all those clones. That's the point of that flag, so that they're already created for doing big parallel jobs. Without the 0x40 flag, there's only one clone.

The current thinking -- thanks to powell -- is that AF will start using 0x40 because then those clones will be available as each of the actors comes online, and we don't need to go to root loop to create more when the current pool runs out. It's a perfect solution except for the leak of the original main reference, but we'll just have to accept that as a static system resource allocation.

[drjdpowell]

Hey, my first Actor Framework suggestion to be accepted! 

Re the "root loop" issue, preallocating any VI one might want to dynamically call is not an ideal general solution.  Is there any chance of a future LabVIEW version doing away with this requirement?  Alternately, this would not be an issue if User interactions like pull-down menus didn't block the root loop (whatever "root loop" is, I don't really know); any chance of changing that?  Even having the ability to programmatically abort the User's root-loop-blocking action would be a crude workaround.

-- James

[AristosQueue (NI)]

This is the result of our contemplation of your recomendation. I believe that this solution avoids the root loop dependency except on the very first call, propagates the errors AND upstream warnings correctly, avoids any "Is Valid" checks on the refnum on every invocation, and avoids triggering my paranoia about state-based race conditions.

Any tweaks before I put this into LabVIEW 2013? And, before you grow sad that you won't get this change until 2013, I am going to make patches to AF available online. The first one, including this change, will go up a few hours after LV 2012 releases.

<< this is what the error case looks like

<< this is what the False frame of the inner case structure looks like

[kegghead]

That ought to work. Any reason you don't just check for Not A Refnum, and open the ref if necessary?

I'm just curious, because it seems to me you've gone out of your way to handle "launch failures" of the VI. Can a VI refnum go bad? Or can the start async primitive return an error that would otherwise be solvable by getting a new refnum and trying again?