How to average a 3D array into a 2D array in the fastest way?

[Wiebe@CARYA]

Altenbach,

I'm pretty sure the benchmark was done before LabVIEW did any constant
folding... So, IMHO, it's valid, although doing the benchmark again in LV
8.x would be meaningless (don't tell me you did it anyway?).

Regards,

Wiebe.

[arvmenon]

Hey,
I dont mean to butt my head into your little exchange here, but I just have to say that altenbach's code is just ingenious.

[Wiebe@CARYA]

I'd use your solution as well, Altenbach.

I couldn't resist to give it a few more tries...

The only improvement that makes a difference it this (it saves about 5%).
Don't devide by N, but multiply by 1/N... But it's such a small margin, that
even when using the PerformaceCounter, the noise is almost higher then the
signal and the order of the test cases makes a difference.

Regards,

Wiebe.

[altenbach]

---

Wiebe@CARYA wrote:
I'm pretty sure the benchmark was done before LabVIEW did any constant
folding... So, IMHO, it's valid, although doing the benchmark again in LV
8.x would be meaningless (don't tell me you did it anyway?).

---

Constant folding was done well before LabVIEW 8.0 and the extend and details varied a bit between versions. One thing that got introduced in LabVIEW 8.2 was the capability to show where folding occurs (fuzzy wires, fuzzy structures, see image). I have this always enabled, it is of great help analyzing code. 😉

I no longer have any pre-8.0 version installed, but it would be easy to check if there is any timing difference between a version with all diagram constants and one with some of them changed to controls.

Using a constant of 100 on the outer loop gives 0ms and changed to a control gives about 188ms in LabVIEW 8.2.1.

There are some weird things between Matts and my version, for example mine slows down if I swap the inputs to the ADD node or add an innocent explicit ToDBL conversion right before the "add" to avoid the coercion dot. This is one of the very few cases I encountered where an implicit conversion is significantly faster than an explicit conversion(!!!). It almost seems that the implicit conversion can avoid the extra buffer allocation for the DBL array right before the add node. (I still need one in the "0" case to enforce DBL type, but that's cheap because it occurs only once).

Matts solution is 50% slower in some runs for no obvious reason at all. I haven't really studied all that....

Message Edited by altenbach on 07-25-2008 08:26 AM

[Wiebe@CARYA]

> Constant folding was done well before LabVIEW 8.0 and the extend and
details varied a bit between versions. One thing that got introduced in
LabVIEW 8.2 was the capability to show where folding occurs (<a
href="http://zone.ni.com/devzone/cda/pub/p/id/347" target="_blank">fuzzy
wires, fuzzy structures</a>, see image). I have this always enabled, it is
of great help analyzing code. 😉

I thought it was very primitive before 8. I never noticed it (any speed
increase caused by it)...

> I no longer have any pre-8.0 version installed, but it would be easy to
check if there is any timing difference between a version with all diagram
constants and one with some of them changed to controls.

I might try that one day...

> Using a constant of&nbsp;100 on the outer loop gives 0ms and changed to a
control gives about 188ms in LabVIEW 8.2.1.

> There are some weird things between Matts and my version, for example mine
slows down if I swap the inputs to the ADD node or add an innocent explicit
ToDBL conversion right before the "add"&nbsp;to avoid the coercion dot. This
is one of the very&nbsp;few cases I encountered where an implicit conversion
is significantly faster than an explicit conversion(!!!).&nbsp;It almost
seems that the implicit conversion can avoid the extra buffer allocation for
the DBL array right before the add node. (I still need one in the "0" case
to enforce DBL type, but that's cheap because it occurs only once).

The speed of the explicit conversion weird indeed...

I've also noticed that the order in which the tests are performed matters.
At my PC, the last case is always a bit faster, even if all test execute the
same case (or copies of the same code).


One other thing that amazes me is that avoiding the case doesn't make much
difference. I tried this. Get the first 2D element. To make the entire array
0, I used the growable math function, with a dbl 0, the array, and the
inverted array (0+2d-2d). This results in a 2d array of dbls, with value 0.
The case can go now, and we have a nice array to initialise the shift
register. You would expect that this is faster, at least when the for loop
is executed often enough. But I can't even measure any difference! Probably
the add inside the loop is much much more significant then the case...

Have a good weekend,

Wiebe.