execution speed of numeric array operations

[jrpe]

Hi, I tried to write a vi to compare the speed of two different methods of doing numeric array operations, but I couldnt get the timer to time properly. I am trying to figure out whether it is faster to

a) Use the polymorphic characteristics of the numeric operators to simply wire an array to the operators in sequence, or
b) write my own for loop that does the same thing, but combines the multiple operations into one for loop.

(The attached image shows these two methods)

For example: Say I have an array of 100,000 elements, and I want to take the reciprocal of every element and then sum the array. Is it faster to just wire the array to the numeric reciprocal operator and then wire the array output from that to the Sum Array operator? Or is it faster to make a for loop that indexes the array, takes each reciprocal and sums them (in that single for loop)?

Basically, is labview smart enough to know that it can combine sequential numeric operations on arrays, or does it loop through the array each time?

If looks nicer on the block diagram to just use the numeric array operators, and it is more understandable, but I want to make sure I am not sacrificing performance.

Does anyone know the answer to this?

[altenbach]

In this case the top will most likely be faster.

The LabVIEW compiler is quite optimized and will do both operations "in place" (but always check for buffer allocations to be sure!)

In real life, you should always do a benchmark because often the situation is not that simple. 🙂

[Steve.Briggs]

Once again, I agree with altenbach..

The top approach is almost instaneous...and so is the second approach.  However, in my time analysis it took 0.200292 seconds for the loop iterations to execute.

Not much time sacrifice in either approach.

[jrpe]

Alright, thanks a lot! I become more impressed with the things that labview does for me every day!

[Ben]

Ditto the above!

I have preformed those benchmarks many times and the primatives ALWAYS are faster.

If I find that this is not true, I would be calling to reoprt a bug ASAP!

Ben

[altenbach]

OK, some number for LabVIEW 8.5:

Don't forget that enabling debugging (the default) has a proportionally higher impact on the loop version.

Here are the times for a 10M element DBL array.

Debugging enabled: atomic 185ms, loop 195ms ---> loop looses by 5%!

Debugging disabled: atomic 185ms, loop  165ms ---> loop wins by 11%!!!

As you can see, the differences are minimal and not worth bothering. But it can go either way!

There is no guarantee that these differences are representative for all array sizes, because there are many other factors that could play a role. (cache size, etc.)

Message Edited by altenbach on 10-31-2007 08:03 AM

[jrpe]

Interesting,

I agree that the difference is so small it is irrelevant, on the other hand, I am surprised that the loop would be faster in either case. If labview is smart enough to realize that sequential operations can be performed in a single loop, and it obviously is (if it wasn't the difference would be much greater than 11%), Im curious about why the loop would ever be faster than the primitives.

Anyway, thanks for checking that out for me!

[Ben]

I wonder if scheduling a re-use of the buffer is involved.

In LV 7.0 this benchmark shows

primatives 0 ms

For loop #1 467 ms

For loop #2 664 ms

I used 10Meg arrays

THe two For loops show that the top input to an "add" can re-use its input buffer.

What kind of numbers do we get with different version of LV?

Christian can you try this on your machine and commnet?

In all our years of working togther you have never failed to surpass my examples. I must be doing something wrong.

Ben

Message Edited by Ben on 10-31-2007 10:45 AM

Message Edited by Ben on 10-31-2007 10:49 AM

[altenbach]

Ben, in 8.5 this is a silly example, because everything is folded into a constant and pre-computed at compile time. It take relatively long to open the VI (because it precalcualted everything!), but then at runtime all times are exactly zero milliseconds!!

You need to e.g. convert the array size constant to a control to avoid that!.

After that the times are (top to bottom) 168, 185, 169 (debugging disabled)..

[altenbach]

More specifically, it seems that 7.0 folds the primitives only. Folding of structures came in later versions.