execution speed of numeric array operations

[altenbach]

---

@Ben wrote:
The two For loops show that the top input to an "add" can re-use its input buffer.

---

No, the timing difference between the loops stays the same, even if youy swap the inputs (remember ctrl+click swaps the inputs;)). The later loop is always faster.

I don't know why... 😮

[Ben]

In LV 7.0 the input to the adder does make a difference.

It looks like they have enhanced the adder to be ambidextrous.

They used to touch on the top input being more efficient back in the LV 5.0 version of LV Advanced.

Ben

[jrpe]

Hi Ben,

I originally remade your vi and put it in a loop to test it (mainly since Im not used to .vi attachments being in 7.0!), and my results were inconsistent between loops.

Then I discovered your vi was actually in 7.0!

When I ran your vi first, I found that

Primitive:           0ms
SR top:       6623ms

Invers top: 32588ms

but that seemed very wrong, so I restarted my computer and ran it again, with that being the only open program and I got

Primitive:           0ms
SR top:      18932ms

Invers top: 14034ms

...which also seems wrong. haha So I checked my CPU while it is running and the CPU never goes above 20%.

A third time gave

Primitive:          0ms
SR top:       8471ms

Invers top:  6298ms

Im not really sure why I get such strange numbers. Anyway, I guess I can't give you a third perspective on this haha

Maybe this is something wrong with either this computer or this installation of labview, I will try again later on a much faster computer.

[altenbach]

Maybe it was slow after the reboot because windows or your antivirus was checking fur updates in the background. Make sure windows if fully loaded and CPU is zero for a while before starting to test.

How much RAM do you have? What kind of CPU? Can you monitor the swap file usage?

Have you resaved the VI locally before running it to make sure it is correct for your OS and exact LabVIEW version? What is your OS?

[altenbach]

---

@altenbach wrote:

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

---

Sorry, I thought you were predictable and would place the timing indicators in the same top-to-bottom order as the algorithms. 😉 I did not look close enough. These numbers are in the order of the FP (top to bottom).

So.... Yes, the primitive is slightly slower and the two loops are exactly the same (within error). Now things make sense. 🙂 There shouldn't be any difference between the loops.

[parthabe]

---

@altenbach wrote:

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

---

Yes, Folding of Structures came from 8.x, I think...

But what does it exactly do?

[jrpe]

So I have the following system

Intel P4 2.40GHz

Windows XP SP2

I checked again, this time saving to the local hard drive, closing all programs and waiting for CPU to sit at 0%, According to the Task Manager I had 522MB(??) RAM total and 139MB free.

The values I got were

SR Top 2064

Inverse Top 12916

Primative 0

Oh well, Im not really sure whats wrong, at this stage it doesnt make a large difference since this computer is only being used for development.

Thanks for your help!

[parthabe]

Sr Top - 314

Primitive - 0

Inverse Top - 604

LV 7.1, Win XP, SP2, P4, 2.8GHz, 1 GB RAM

Drops down to 260's, 0, 560's in the later runs.

[altenbach]

---

@parthabe wrote:
But what does it exactly do?

---

See the section "constant folding" at the following link:

http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/block_diagram_objects/

Basically, if a an operation has all constants as inputs, it is sufficient  to store the end result, because it can never change. The actual code can be optimizede away.

Here's one example:

See: http://forums.ni.com/ni/board/message?board.id=170&message.id=202657#M202657