Aristos Queue

QUOTE(eaolson @ Jun 4 2007, 01:42 PM)

No, because I remember the same thing. In fact, I the example it used is pretty similar to the attached one, with no contants involved. As I recall, the difference in speed was explained as being because LV was able to reuse a buffer in the array case, but had to reallocate it each loop in the For case.

I think you're thinking of a *while* loop.

In a For Loop, since we know at the start how many elements will be needed, the output array can be allocated right away.

With a while loop, it gets reallocated on each iteration to grow as needed.

QUOTE(Gary Rubin @ Jun 4 2007, 09:44 AM)

You are correct.

I need to stop trying to think on Monday mornings. It just isn't working out well...

That means my previous question still applies. Am I just imagining a past App Note that recommended operating on arrays rather than on each element inside a for loop?

Try putting the random number generation node *outside* the loop and then wire it through the loop tunnel. That should give comperable results to wiring the array directly.

QUOTE(Tomi Maila @ Jun 1 2007, 01:27 AM)

Hmm.. So you are not using any intermediate language?

We are not using any intermediate language.

QUOTE(eaolson @ May 31 2007, 09:53 AM)

Aristos Queue once said that the Get Queue Status VI "generates no code" if a particular wire was left unconnected. Ever since then I've wondered if much of LabVIEW is a front-end for connecting bits of pre-compliled code.

Just like any compiler for any computer language, the source code of LabVIEW (the block diagram) is translated to assembly instructions that the computer can actually execute. The Add primitive generates machine code instructions to load values into registers, add them and store the result back to memory. The Queue prims generate considerably more complex assembly code. Ultimately, machine code is the only language the computer understands. Some routines in LV are prewritten. An example would be the Scan From String primitive, which generates assembly code needed to call an already written section of machine code stored in either labview.exe or lvrt.dll. But if all we did was string together prewritten functions, the code would be pretty slow to execute. The compiler translates the nodes/wires on the block diagram into code that is as optimal as the compiler can figure out to make it.

Of course, when we compile a VI for a target like PDA or FPGA all of the code has to be generated. There are no prewritten routines on those platforms.

QUOTE(eaolson @ May 31 2007, 10:01 AM)

And whoever has heard of The Knights Who Say National Instruments?

One of our intern T-shirts says this...

There's also another intern T-shirt that says "The End of the World is NI". ;-)

QUOTE(Ben @ May 31 2007, 10:13 AM)

Should I assume a response of "mu" to that Q as well?

*grin*

The algorithm has many specifications for what it has to do. But how it does them... well... if you come to NI HQ on Samhain/All Souls Night, when the barriers to the spirit world are thinnest, you can hear the whispers in the wind that tell us lines of code to change. Some developers hear better than others, and they enter a sort of trance that allows them to change obscure lines of code. At any other time of the year, staring at those lines of code is much like staring at a Rorshach ink blot.

QUOTE(Mike Ashe @ May 31 2007, 09:37 AM)

It used to be that speed/performance was a very valid reason. You could implement the example you give above in G and in a CIN or DLL in C and the performance difference was pretty large. I know that NI has made a lot of optimizations in how LabVIEW handles arrays in recent versions. I was wondering if you have any up to date benchmarks on the relative difference between G and C"whatever the flavor of choice" array performance today?

I don't. Maybe NI does somewhere.

Zen Koans teach that certain yes/no questions can only be answered with "mu". The classic example:

Question: "Have you stopped beating your wife yet?"

Answer: "Mu."

"Mu" unasks a question that is based on false assumptions. The above question not only presumes that you have a wife, but also that at some point you started beating her. If you don't have a wife or never started beating her, then both yes and no would both be misleading answers.

QUOTE(Ben @ May 30 2007, 02:43 PM)

"Could you please pass me a copy of and include me in the distribution of changes to the specifactions for the "in-placeness" algorithm?"

The answer to your question is "mu." Can you puzzle out the incorrect assumptions built into the question?

QUOTE(Gary Rubin @ May 31 2007, 07:45 AM)

I could clearly write subvis to replicate this behavior but I don't see any way to do it without some sort of looping, which would be slower than a native capability.

What would make it slower than a native capability? Let's say we did make the Index Array have the behavior you request. The code under the hood would be something similar to the G code. For example, your array of int32s as indicies would be something like:

 outputArray.capacity(indexArray.size()); for (i = 0; i < indexArray.size(); ++i) {	outputArray.push_back(inputArray[indexArray[i]]); }

All the same stuff you'd do in G.

There may be other reasons to add this functionality to the Index Array primitive, but speed/performance isn't a valid reason (IMHO).

QUOTE(JanJorgensen @ May 24 2007, 02:56 PM)

Do you know if there's a "best object reference design" anywhere which most labviewers use?

Man, LVClasses have only been available since August! We'll have a "best design" for a lot of things ... in about three years. At the moment there's a scattershot of "things that R&D put together that seem to work well" and "things the early adopters (such as Tomi) have attempted when the R&D stuff failed to meet their needs".

What you see in the shipping examples and postings to LAVA is pretty much the extent of things at this point. If you do hit on a really clean implementation, post it --- and in a couple years we may be pointing to your design as the "best" recommedation.

QUOTE(Michael_Aivaliotis @ May 23 2007, 04:59 PM)

Well, I just finished upgrading an "old" 8.0.1 project to 8.2.1 so I don't have a need for 8.0.1 anymore. I'll uninstall this and see if it makes a difference.

Brainstorming ideas:

1) Did you change .ini files such that "load palettes in background" was changed to "load all palettes at launch"? That's an option in Tools>>Options>>Palettes.

2) Have you got a bunch of toolkits installed that aren't mass compiled? (Not that I can explain why those would be loading as part of launch.)

3) Is it at all possible that you installed 8.2.1 and then used an 8.2 on another computer to mass compile your 8.2.1 install? Or something bizzare like that?

I'm really at a loss to explain such a slowdown. Those are the only ideas that I can come up with.

This was reported to R&D (# 49MCUJJ1) for further investigation.

QUOTE(crelf @ May 23 2007, 10:20 AM)

There's also an NI event that afternoon: NI Community Block (Diagram) Party from 5:00-7:30pm, so, as usual, we can all enjoy a drink at that, and then head off on the bus at around 6ish.

What about dinner afterward at 8pm? Salt Lick is open late. (Yeah, I know, there's an 8am keynote, but that's 12 hours away...)

QUOTE(Michael_Aivaliotis @ May 22 2007, 01:53 AM)

I just want to revive this thread and say a big Booo! to NI for slowing LabVIEW down agian. After applying the new 8.2.1 patch my launch time sucks. Back to 8.0 startup speed.

Did you mass compile the directory <labview>\resource ?

Nevermind... 8.2.1 is a full installer so all the VIs ship mass compiled. I forgot about that.

I don't know what would be causing your slowdown. ... the failure to mass compile can affect my development build, but if I use a real install of 8.2.1, it's just as fast as 8.2.0.

QUOTE(Jim Kring @ May 17 2007, 09:08 PM)

It is a little know fact that the OpenG/LAVA BBQ started at NI Week 2002 when Richard Jennings invited me to join him and a few other people for BBQ at County Line. That was my first experience with Texas BBQ and the birth of a great tradition.

So... it sounds like County Line *does* have tradition on its side...

I'd back the County Line -- I've been there for a couple large gatherings and it can handle the crowd.

QUOTE(Jim Kring @ May 17 2007, 03:55 PM)

No!!!! I have entire software architectures based on exploiting this feature to create objects that are not garbage collected when the call chain goes idle!!!

Actually, I'm just kidding, but I'd really like to be able to have more subtle control over the lifetime of references

Simple! Create a LV2-style global that wraps around all "Open ..." and "Create ..." functions, returns the value to you in a variant (which you can then change to the specific data type). That VI should hold an FP reference to itself, intercept both the AppExit event and the PanelClose Event, and provide whatever clean up for the refnums. Disabling the Abort button is easy -- just have a loop in memory that polls for all open block diagrams/front panels in memory and clones a reentrant VI that itself doesn't show the abort button and have it float over the relative position of the abort button on each panel and diagram. Now all the holes should be plugged -- you can add ways to early dispose the refnums as needed by adding other actions to your LV2-style global.

Honestly, I can't believe OpenG hasn't already rolled out a tool to do all this.

QUOTE(Jacemdom @ May 17 2007, 12:24 PM)

Reply under construction...estimated delivery date 1 to 5 days...

As a short reply, let me know if there's another section that you want me to specifically comment on. As I read it, the rest seemed to be explanation of how you came to your suggestions and the advantages of those suggestions.

Yeah, I voted for "somewhere else". But after that I realized I didn't have a better suggestion, and seeing as how everyone else is good with Salt Lick, just pretend like my vote was for Salt Lick too.

Well, it took a while to dig into. But I (with help) found it.

Turns out to be a bug beyond just Notifiers. A refnum acquired by any VI or its subVIs is supposed to be released either by an explicit call to a primitive that closes the refnum or auto-closed by LV when the VI stops running. Well, for subroutine VIs, the auto-close just was never happening for all refnum types. The refnums were leaked. In the case of Notifiers, the problems you saw at exit was caused by trying to shutdown the notifier system with notifiers still in existence. Most refnums won't have the same crash behavior (in fact, Queues, which are tightly related to Notifiers, do not crash). But all of them leak.

Workarounds I can think of...

a) Call Release Notifier as part of your VI's execution so you don't rely on the auto-close

b) Make the subVI not be subroutine priority.

c) With the functional global, you could have an input on the conpane for Notifier In. When you pass Not a Refnum as the input, the functional global would use the value last stored in the shift register. If you pass a value, then that value would be stored and passed out as the output. This allows you to initialize your Notifier outside.

This bug will be fixed in the next release of LV.

QUOTE(aka @ May 15 2007, 07:00 AM)

i thought i had to use:

Read BMP File.vi and Draw Flattened Pixmap.vi

but nothing happens. what am i doing wrong?

That should work. There are examples that ship with LV. Check those out.

Gray probes are probes where the type of the probe doesn't match the type of the wire.

This almost always happens from having a wire that is a typedef, putting a probe on the wire and then changing the type definition to be some other type. If the probe itself doesn't use the typedef'd type, then the dot on the wire will turn gray instead of yellow.

QUOTE(Aitor Solar @ May 15 2007, 05:49 AM)

Nothing special, in fact I also tried it with the xctl in the LV examples (dual thermomether I think it's called, is placed in examples/general/xcontrols) and the behavior is the same: crash boom bang. Did you tried with 8.20 or 8.2.1?

With thermometer example, I don't see a crash with either 8.2.0 or 8.2.1.

Dear Jacedom,

Only two sections of your document seem to need a reply.

5.3.2.3 is your idea of defining the entire class hierarchy in a single control of a cluster of clusters.

5.3.3.3 is your idea that all data would be public.

The 5.3.2.3 idea is similar to how the classes work under the hood. You, the user, create each class independently. Behind the scenes, each class is represented by a cluster of clusters -- all the clusters of the ancestors clustered together with the current level of data. As I said, it is similar, but we don't create the branching cluster structure that you propose. Something like that structure is being toyed with for getting classes onto targets that have to have fully preallocated data -- every object on those targets would be a composite of fields such that the whole was capable of containing all possible descendants (obviously no dynamic loading on those platforms).

The idea is a good one, but it doesn't really work for the editing environment. Problems with having them all in the same cluster up front:

1) You couldn't have multiple users creating child classes of a parent, since they'd both need to be editing the same file. Integration would be hell.

2) You couldn't dynamically load classes -- every descendant would always be in memory.

3) The parent implementations would be open and visible to the child implementations. You'd lose the independence of separating implementation from interface.

As far as "all data would be public"... you are hereby banned from using the word "encapsulation" ever again. The disadvantages of public data and the advantages of private data have been so thoroughly talked about in so many forums I'm not going to go into them here. We do need to make the process of creating accessor VIs simpler. But making public data would be a disservice in the extreme to developers (yes, that's my opinion, and yes, I just stated it as fact, and you're not going to make much headway with any counter argument).

The 8-dot-3 file names are there because they were required for some platforms and the printing code has never bothered to change. The system is in general a good idea, but you should consider picking more meaningful abbreviations for items since the option exists.

FYI, in LV8.2 and later, it is possible to replace the built-in icon editor with one of your own. To read about it, open the Icon Editor, click on the Help button and scroll to the bottom of the help topic.