36 replies to this topic

[syrus]

Hmmm... Any chance you could post your VI saved as 7.1?
Thanks,
Gary

Hi again Gary,
I can save as far back as 7.0 using "Save for previous..." under 7.1.1. I'm attaching all three versions of the 1.0.0 release to this message.

Download File:post-3106-1161639025.zipDownload File:post-3106-1161639046.zipDownload File:post-3106-1161639058.zip

[Michael Aivaliotis]

Hi again Gary,
I can save as far back as 7.0 using "Save for previous..." under 7.1.1. I'm attaching all three versions of the 1.0.0 release to this message.

Admin Note: For the next release, perhaps you can include the older labview versions in the zip file. Another option is to develop in LV7.0 or 7.1 and release it in that version only. People can then upconvert. Just some suggestions to streamline the process.

[Gary Rubin]

I can save as far back as 7.0 using "Save for previous..." under 7.1.1. I'm attaching all three versions of the 1.0.0 release to this message.

Thanks, I look forward to playing with it tomorrow.
Gary

[syrus]

Admin Note: For the next release, perhaps you can include the older labview versions in the zip file. Another option is to develop in LV7.0 or 7.1 and release it in that version only. People can then upconvert. Just some suggestions to streamline the process.

Thanks Michael. I'll improve my process as you suggest for the 1.0.1 release. --Syrus

Edit: I have uploaded a 1.1.0 release in response to the discussion today. I updated the minor version number because this is not a bugfix release. The following changes were made:

1.1.0:
Added input validation, error handling, and the option to use "MATLAB mode" and generate a permutation of the integers from 1 to n instead of 0 to n-1, where n is the value wired to the size input. Added a "convert to I32" before feeding the random index to the array functions to eliminate two coercion dots. Updated description to reflect these changes. Changed wiring pattern to 4-2-2-4 and changed icon to accomodate additional terminals.

[Gary Rubin]

Syrus,
There are a couple ways that it seems that you can squeeze out a few more microseconds. I ran some benchmarks for size=1000, and on my 2.4GHz P4, I was able to trim the execution time from ~0.76ms to ~0.70ms.
First, get rid of the coercion dots by converting those two coerced wires to dbl.
Second, I read somewhere (probably one of the Labview App notes, which I can no longer find), that case structures have a fair amount of overhead associated with them, so for simple things like your Matlab switch, it's better to use a Selector node.
Gary

[syrus]

Syrus,
There are a couple ways that it seems that you can squeeze out a few more microseconds. I ran some benchmarks for size=1000, and on my 2.4GHz P4, I was able to trim the execution time from ~0.76ms to ~0.70ms.
First, get rid of the coercion dots by converting those two coerced wires to dbl.
Second, I read somewhere (probably one of the Labview App notes, which I can no longer find), that case structures have a fair amount of overhead associated with them, so for simple things like your Matlab switch, it's better to use a Selector node.
Gary

Hi Gary,

When I decided to add the MATLAB switch, I was no longer woried about a few microseconds--users who are that pressed for performance can extract the portion of the diagram they need and remove all case structures. Regarding coercion dots, I don't believe replacing the automatic coercion with an explicit coercion should make a difference in performance (although I'm not disputing that it does in your version of LabVIEW).

Regarding the selector instead of case structure, I would like to know whether the selector computes all inputs before evaluation or if it smartly evaluates the condition first. It may indeed be smart, but it is not obvious from a dataflow point-of-view. I therefore would err on the side of code clarity to use the case structure instead of the selector.

When I decided to add error handling and input validation, it was because I realized that I had performed premature optimization.

[Gary Rubin]

Regarding the selector instead of case structure, I would like to know whether the selector computes all inputs before evaluation or if it smartly evaluates the condition first. It may indeed be smart, but it is not obvious from a dataflow point-of-view. I therefore would err on the side of code clarity to use the case structure instead of the selector.

I wish I could find that App Note...
My understanding was that Labview will evaluate both paths. It just happens that for simple things like incrementing vs. not incrementing, performing an unecessary addition is faster than the overhead associated with using a case structure to not performing the operation.

[syrus]

I wish I could find that App Note...
My understanding was that Labview will evaluate both paths. It just happens that for simple things like incrementing vs. not incrementing, performing an unecessary addition is faster than the overhead associated with using a case structure to not performing the operation.

In our VI, LabVIEW is modifying the whole array, not performing an addition on a scalar. And, since both branches must be preserved, LabVIEW will produce an extra copy of the array.

[Gary Rubin]

In our VI, LabVIEW is modifying the whole array, not performing an addition on a scalar. And, since both branches must be preserved, LabVIEW will produce an extra copy of the array.

Yeah, you're right. Now I really wish I could find whatever it was I had read to try to figure out what it was recommending.

[PJM_labview]

...Regarding coercion dots, I don't believe replacing the automatic coercion with an explicit coercion should make a difference in performance (although I'm not disputing that it does in your version of LabVIEW)...

It has been my experience that explicit coercion does improve performance.

PJM

[robijn]

The difference that I can see is that the submitted code runs 3-4 times faster than the Sort 1D Array approach.

-D

Hmm, only 1.6 times faster here, P4 1.7GHz, LV711
If you multiply the random number by 2^31-1 and store it as an I32 it is only 1.25 times faster.

The preallocation stuff is quite fast, and the speed of the sort function is amazing.
I like neat small diagrams more

Joris

[Kevin P]

It has been my experience that explicit coercion does improve performance.

Hmmm. The few times I was really trying to shave down the microseconds, I measured better speed with the coercion dot. As I recall, I was testing a histogram-like binning algorithm. The coercion in question was for an array index that was calculated in floating-point. For some reason, an explicit conversion to i32 ran very slightly, but quite consistently, slower than leaving the coercion dot.

Still, I almost always do my coercions explicitly anyway.

-Kevin P.

[JDave]

Hmmm. The few times I was really trying to shave down the microseconds, I measured better speed with the coercion dot. As I recall, I was testing a histogram-like binning algorithm. The coercion in question was for an array index that was calculated in floating-point. For some reason, an explicit conversion to i32 ran very slightly, but quite consistently, slower than leaving the coercion dot.

Still, I almost always do my coercions explicitly anyway.

I also benchmarked this some time ago and got varying results. Depending on the data I got better results with explicit or implicit coercion. However, the difference was minimal. So for most applications it would be better to do explicit coercion because it exposes what is happening a little more clearly (or more correctly if you fix any latent bugs ).

David

[crelf]

I also benchmarked this some time ago and got varying results. Depending on the data I got better results with explicit or implicit coercion.

The few times I was really trying to shave down the microseconds, I measured better speed with the coercion dot.

Can we please get a definative answer from NI on this one?

[Guillaume Lessard]

Forgive me if I'm being dense here, but how is that different from doing this?

As you found out, they both produce the same result. In terms of algorithm efficiency, though, using the 'sort' function is slower:

The 'sort' function scales in time with array size n as n*log(n)

This shuffling algorithm (the Knuth shuffle or Fisher-Yates shuffle) scales in time linearly with array size -- in addition to not requiring additional memory.

[PJM_labview]

Hmmm. The few times I was really trying to shave down the microseconds, I measured better speed with the coercion dot. As I recall, I was testing a histogram-like binning algorithm. The coercion in question was for an array index that was calculated in floating-point. For some reason, an explicit conversion to i32 ran very slightly, but quite consistently, slower than leaving the coercion dot.

Still, I almost always do my coercions explicitly anyway.

-Kevin P.

Hmm,

The last benchmark I run were either on LV 7.0 or LV 7.1. At the time I consistantly got better result (not by much though, I think it was in the order of a couple %) using the explicit coercion. It is possible that the implicit coercion has been improved in subsequent LV version.

PJM

[Gary Rubin]

Now I'm curious. In my 10 years or so of technical computing, I'm having trouble thinking of many times where I've come across a need for randomizing an array. A Labview implementation of Boggle that I did on a long flight, and a card shuffling exercise in college come to mind, and obviously those don't need to be really fast.
So, just out of curiosity, what type of real applications require such fast and efficient randomization?