"Required" terminals are more efficient?

[Grampa_of_Oliva_n_Eden]

QUOTE(crelf @ Jun 11 2007, 07:43 AM)

Thanks Aristos - do you, or anyone else you can find at NI, have anything to add about the "required" vs "recommended" terminal debate? I think, without inside knowledge, the rest of us are just guessing at this point...

I have not thought this through all of the way (coffee no work yet).

Does this info about the "required vs" really make any difference?

If I am already marking required inputs as required then is it really practical to mark optional inputs or recomended as required?

Ben

[crelf]

QUOTE(Ben @ Jun 11 2007, 10:41 PM)

Does this info about the "required vs" really make any difference?

That's what I'm trying work out

[Yair]

QUOTE(Aristos Queue @ Jun 11 2007, 06:58 AM)

No. I'm not sure why Rolf thinks the assembly code isn't in there somewhere.

Not that I would want to argue with the all-mighty LV R&D, but that is not exactly what Rolf said.

I don't know how the disassembler works, but what Rolf said was that it finds the pre-built assembly code which is responsible for loading the RTE, etc. and that it can not actually find the machine code included in the VIs.

This would seem to be supported by Jeff's second experiment and would make some sense, because we know that LV generates the actual machine code when compiling the VIs and that putting the VIs into the exe is basically the same process with some optimizations (removing FPs, BDs, debug code, etc.).

I do find it weird that the disassembler does not go through the entire binary executable, but as I said, I don't know how it works, so I will just assume that what Rolf meant was that it knows how to find the basic executable code, because that's in a standard location and it doesn't look for the rest of the machine code because as far as it's concerned the rest of the exe is not machine code.

[Aristos Queue]

QUOTE(crelf @ Jun 11 2007, 06:43 AM)

Thanks Aristos - do you, or anyone else you can find at NI, have anything to add about the "required" vs "recommended" terminal debate?

I don't.

[Rolf Kalbermatter]

QUOTE(Aristos Queue @ Jun 10 2007, 10:58 PM)

No. I'm not sure why Rolf thinks the assembly code isn't in there somewhere. The assembly code for all the VIs is definitely in the EXE. The initial code is going to start the EXE, and then start executing "clumps" of assembly as they become available to the thread scheduler (the top-level VI schedules its initial clumps to run... as each clump's inputs become available, they join the list of clumps that can get executed). LV doesn't have a call stack for subroutines -- just the scheduler picking up a clump, executing it, then scheduling the next batch of clumps. Anyway, the long and short of it, there is assembly code in there for the VIs. I don't know why you're not seeing it.

This is probably the sort of information that you're not supposed to know -- because you're not supposed to be reverse engineering the assembly according to the license agreement -- but I figured I'd tell you because I don't want some rumor to start up that LV is somehow an intermediate interpreted language like JAVA. That sort of nonsense would just contribute to perceptions -- right or wrong -- of LV as not a real language and too slow for real work. LabVIEW is a compiled language.

Of course the machine code (not assembl(y)er code as that is what a disassembler will create or an assembler will use to generate the machine code!) is there but inside the VI that is inside the LLB and that is somewhere inside the executable. Any disassembler I know of will only find code that is located in segements specifically marked as code segments. And its disassembly starts at the normal executable entry point and goes from there. Code embedded in some ways in the resources or as in LabVIEW in some proprietary binary structures won't be found at all. So the output from disassembling a LabVIEW executable only shows the startup stub that launches the LabVIEW runtime library. Only the LabVIEW development environment (well not in 8.2 anymore it seems) and runtime system knows how to locate the VIs inside the executable and from there extract the machine code embedded in there.

QUOTE(Ben @ Jun 11 2007, 07:41 AM)

Does this info about the "required vs" really make any difference?

If I am already marking required inputs as required then is it really practical to mark optional inputs or recomended as required?

Well, as has been pointed out already, for required inputs the subVI won't need to check if the input was wired and provide a replacement default value if it wasn't, since it can savely assume that there is a value at all times (otherwise the VI couldn't have been called obviously). So I guess it is this little extra code that makes the difference in execution time and probably will also result in a few bytes less machine code for required inputs.

And no, making non-required inputs required just for the purpose of saving a few nanoseconds execution time won't be a useful thing to do as the convinience of not having to wire an input if it is usually not necessary makes a lot of sense to me.

Rolf Kalbermatter

[crelf]

QUOTE(rolfk @ Jun 12 2007, 05:10 PM)

And no, making non-required inputs required just for the purpose of saving a few nanoseconds execution time won't be a useful thing to do as the convinience of not having to wire an input if it is usually not necessary makes a lot of sense to me.

I agree, but I'd like to know whether it is nanoseconds, as you suggest...

[Rolf Kalbermatter]

QUOTE(crelf @ Jun 12 2007, 08:09 AM)

I agree, but I'd like to know whether it is nanoseconds, as you suggest...

Will with nowadays MultiGigaHz CPUs it is definitely more in the order of a few 100 ns than many us.

Rolf Kalbermatter

[crelf]

QUOTE(rolfk @ Jun 13 2007, 02:23 AM)

...it is definitely more in the order of a few 100 ns than many us.

I agree that the performnace improvement can't be particularly significant, so my questions become:

1. why was it mentioned in a NI Developer Days presentation?
   
2. Was it added as filler?
   
3. Is there a platform where it does make a significant difference that we're not thinking about?
   
4. Why was it mentioned at all?
   
5. Why does anyone care about Paris Hilton's jail time?
   

All true mysteries of life...

[Grampa_of_Oliva_n_Eden]

QUOTE(crelf @ Jun 13 2007, 08:24 AM)

I agree that the performnace improvement can't be particularly significant, so my questions become:

1. why was it mentioned in a NI Developer Days presentation?
   
2. Was it added as filler?
   
3. Is there a platform where it does make a significant difference that we're not thinking about?
   
4. Why was it mentioned at all?
   
5. Why does anyone care about Paris Hilton's jail time?
   

All true mysteries of life...

I have never been very good at "why" questions but I would guess that the answers to 1, 4, and 5 is answered in #2.

Ben

[crelf]

QUOTE(Ben @ Jun 13 2007, 10:56 PM)

I would guess that the answers to 1, 4, and 5 is answered in #2.

[Jeff B]

Hello all,

I presented the originally referenced Dev Days presentation. I have not read all of this discussion, but I followed-up on this topic. I'd suggest that the reasons it was presented is that the person who put together then slides had a false impression of the level of impact it would make.

It is true that, when marking inputs as required, in certain circumstances we save a little bit of time by not having to copy in the default value for that control. This amount of time is probably very small, and this technique could potentially be used to eek out just a little bit more performance. It will not likely have a big impact. Sorry for the confusion.

Take care,

Jeff

[Grampa_of_Oliva_n_Eden]

QUOTE(Jeff B @ Jun 13 2007, 11:29 AM)

Hello all,

I presented the originally referenced Dev Days presentation. I have not read all of this discussion, but I followed-up on this topic. I'd suggest that the reasons it was presented is that the person who put together then slides had a false impression of the level of impact it would make.

It is true that, when marking inputs as required, in certain circumstances we save a little bit of time by not having to copy in the default value for that control. This amount of time is probably very small, and this technique could potentially be used to eek out just a little bit more performance. It will not likely have a big impact. Sorry for the confusion.

Take care,

Jeff

Thank you Jeff!

Ben

[Tomi Maila]

QUOTE(Jeff B @ Jun 13 2007, 06:29 PM)

It is true that, when marking inputs as required, in certain circumstances we save a little bit of time by not having to copy in the default value for that control. This amount of time is probably very small, and this technique could potentially be used to eek out just a little bit more performance. It will not likely have a big impact. Sorry for the confusion.

Thanks Jeff for your answer. I'm still wondering if inplaceness algorithm works better if inputs are required....

[crelf]

QUOTE(Jeff B @ Jun 14 2007, 01:29 AM)

Sorry for the confusion.

No need to apologise at all Jeff - that's what LAVA is here for Thanks for the update.

[ohiofudu]

QUOTE(Jeff B @ Jun 13 2007, 10:29 AM)

Hello all,

I presented the originally referenced Dev Days presentation. I have not read all of this discussion, but I followed-up on this topic. I'd suggest that the reasons it was presented is that the person who put together then slides had a false impression of the level of impact it would make.

It is true that, when marking inputs as required, in certain circumstances we save a little bit of time by not having to copy in the default value for that control. This amount of time is probably very small, and this technique could potentially be used to eek out just a little bit more performance. It will not likely have a big impact. Sorry for the confusion.

Take care,

Jeff

Thanks Jeff for clearing this Required terminals issue.

[ragglefrock]

QUOTE(Tomi Maila @ Jun 13 2007, 11:26 AM)

Thanks Jeff for your answer. I'm still wondering if inplaceness algorithm works better if inputs are required....

I would doubt that. The inplaceness algorithm just determines if it's safe to reuse the input buffer for the output data. Whether that input buffer comes from a default value when unwired or a wired input value shouldn't make any difference. In any case, the Hide the Dots game would quickly verify whether there is a difference.

[Grampa_of_Oliva_n_Eden]

QUOTE(ragglefrock @ Jun 14 2007, 12:11 AM)

I would doubt that. The inplaceness algorithm just determines if it's safe to reuse the input buffer for the output data. Whether that input buffer comes from a default value when unwired or a wired input value shouldn't make any difference. In any case, the Hide the Dots game would quickly verify whether there is a difference.

I would think that a constant can NOT be a candidate for re-use. If the memory containing the contents of the on the constant was used for subsequnt manipulations "down the wire", it would no long contain the "constant" value and subsequent calls to the VI would find the results of the previous work were the "constant" should have been.

I think there was a bug involving clusters and case structures that did exactly that. In fact the modified constants value would actually work its way back in to the source if the VI was saved. THe good news was it was an odd construct that was seldom used.

Ben

[ragglefrock]

QUOTE(Ben @ Jun 14 2007, 06:20 AM)

I would think that a constant can NOT be a candidate for re-use. If the memory containing the contents of the on the constant was used for subsequnt manipulations "down the wire", it would no long contain the "constant" value and subsequent calls to the VI would find the results of the previous work were the "constant" should have been.

I think there was a bug involving clusters and case structures that did exactly that. In fact the modified constants value would actually work its way back in to the source if the VI was saved. THe good news was it was an odd construct that was seldom used.

Ben

I agree with that in principle, but I don't think the default value created by the VI with an unwired terminal would be a constant value. Maybe copied from a constant, but not a constant itself. Here I'm just guessing, but it's the basis of my original answer.

[Rolf Kalbermatter]

QUOTE(ragglefrock @ Jun 14 2007, 11:28 PM)

I agree with that in principle, but I don't think the default value created by the VI with an unwired terminal would be a constant value. Maybe copied from a constant, but not a constant itself. Here I'm just guessing, but it's the basis of my original answer.

I'm pretty much sure you are right here. Wouldn't make sense trying to use a constant value directly as default input value instead of allocating the necessary memory space and initializing it accordingly. As such it could of course have a serious impact if the controls default data was not one of LabVIEWs default default data but rather an 100 MB data array.

Rolf Kalbermatter

[LAVA 1.0 Content]

Re: Required terminals are more efficient?

I've got this crazy project happening that requires I bench-mark every little piece of code.

I'm using a PXI Xhassis running LabVIEW Real Time 8.5 that is full of top of the line clocks timers and counters.

I confirmed that the difference in Required vs Optional makes such a small differences, we could not measure any difference in performance.

What was suprising was.....

(drum roll)

The icon connector used!

A VI with spare terminals (like we have all learned that we should always have) takes longer to call than an identicle VI who's icon connector only has enough terminals for the data being passed!

I came to accept this after thinking that the function prototype (as defined by the icon conector) indicates how many items get pushed onto the stack when the sub-VI is called.

Take care!

Ben

[Tomi Maila]

QUOTE(neB @ Nov 7 2007, 09:54 PM)

A VI with spare terminals (like we have all learned that we should always have) takes longer to call than an identicle VI who's icon connector only has enough terminals for the data being passed!

Do you have any estimate how much longer does it take to call a VI with say two inputs and two outputs versus a VI with the default connector pane?

Tomi

[crelf]

QUOTE(neB @ Nov 8 2007, 05:54 AM)

I confirmed that the difference in Required vs Optional makes such a small differences, we could not measure any difference in performance. What was suprising was..... The icon connector used!

Got a quick example with benchmark data?

[JDave]

QUOTE(neB @ Nov 7 2007, 11:54 AM)

What was suprising was.....

(drum roll)

The icon connector used!

A VI with spare terminals (like we have all learned that we should always have) takes longer to call than an identicle VI who's icon connector only has enough terminals for the data being passed!

I came to accept this after thinking that the function prototype (as defined by the icon conector) indicates how many items get pushed onto the stack when the sub-VI is called.

So how big was this measurable speed increase?

[LAVA 1.0 Content]

QUOTE(crelf @ Nov 7 2007, 03:17 PM)

Got a quick example with benchmark data?

I'll try to remember to get back with some numbers.

We only found this out because "I asked the developer to change one thing, create new test".

In one case we were passing a single array.

In another we were passing two.

The "two array" version ran faster than the "one arrays" (We were using the icon on the root technique so our buffers were being reused so we were just passing pointers to the arrays).

After some head scratching, we tried the same test but with icon connectors that use the the min required in each test.

The "time" is very small but it is measurable (I'm using an 80 MHz clock driving a counter timer board. It looks like it take about 4.4 us to read from a counter. That part I wrote down).

I'll post what I can!

My motivation in posting this info was to share the fact that if you are trying to squeeze more performance out of sub-VI calls, forget about the "Required" and use a smaller icon pattern.

Ben

[Aristos Queue]

QUOTE(neB @ Nov 7 2007, 01:54 PM)

I came to accept this after thinking that the function prototype (as defined by the icon conector) indicates how many items get pushed onto the stack when the sub-VI is called.

I DISBELIEVE. Simply put, the conpane pattern isn't even known to the compiled code. There's no way that could make a difference. The gencode only knows about the terminals that are actually used. I mean, conpane isn't even in the LV runtime engine -- it *can't* be compiled into the code in any way shape or form. Oh, and LV doesn't have a call stack. The dataspaces are just patched together directly. There's no call overhead unless inputs have to be copied because the input has to be unshared to avoid stomping on the original input.