reshape array inline?

[Yuri33]

I come from a Matlab background, so vectorizing code by flattening\unflattening data is second nature to me.  That means my natural tendancy when writing LabVIEW code is to constantly reshape arrays so that I can do stuff in one dimension.  Howevever, using the "show buffer allocations" option, I always seem to see a new buffer allocation whenever reshape array is used.  Is the reshape array primative an inline operation if the number of elements do not change?  Is it simply faster to use nested loops and do operations one element at a time?

[mikeporter]

To begin with, it's never faster to index through an array. You always want to work with array data as an array as much of the time as possible. In other words, take advantage of LV's polymorphism as much as you can. You would be surprised how much you can do in arrays.

Likewise, don't reshape an array unless you absolutely have to - or the array is small. Reshaping a good-sized array is very costly in terms of memory and time.

Mike...

[altenbach]

Yes, if the size does not change, reshaping an array does not need to move the data in memory, so it should be very efficient.

In LabVIEW 8.0 and earlier, the help actually mentioned that "This function does not physically move the data in memory, but the memory is re-interpreted according to the reshaped array dimensions.". This sentence has been removed from the online help in 8.20. The problem might be that it can also be used to pad and truncate arrays, in which case an allocation might be needed.

So, Yes, in the most ideal case, the function should not need a new buffer allocation. I haven't studied if it is possible to achieve that.

---

@Yuri33 wrote:
 Is it simply faster to use nested loops and do operations one element at a time?

---

Remember that you can also do a hybrid approach where you would eliminate the innermost nested loop and operate on a 1D array for each iteration.

In general, don't trust your instincts if performance is very critical. Wire up a few alternatives and benchmark them to be sure. 😉

[Yuri33]

If it were up to me, I'd use as few loops as possible and stick to the LV primitives as often as I can, using Reshape Array when needed (and not changing the number of elements).  But this may not be the case in LabVIEW.

I'm referring specifically to this discussion.  There, they found that iterating each element and performing operations in a formula node was fastest of all methods (besides simply letting a CIN/DLL do it all), which is very counterintuitive to me.  They were using very basic examples, so I don't know if that extrapolates to the more complex algorithms I am coding.  I realize that I could wire up different possibilities, but I would have to do that at each step of the code, and that would take too much time (and too much hair pulling--there are endless ways to code even simple procedures!).  I'm just hoping there is a uniform, comprehensive set of  guidlines on these kinds of optimizations here, including the issue I have with Reshape Array.  I've looked through the application notes, and knowledgebase articles, as well as the LV help, but none of them answer some of the basic questions talked about in the thread I linked above.

Maybe I could pose the question a different way: if I continue to vectorize my code, will I be pretty close (say, 15%) to the optimal speed one could squeeze out of LabVIEW?  I think I could sleep well knowing that 🙂

Message Edited by Yuri33 on 07-13-2007 01:11 AM

[GerdW]

Hi Yuri,

look at post #9 in the thread you mentioned. There you have a picture of good optimized code - it's all done with LV primitives.
General rule: do as much as possible with LV primitives while avoiding new buffer allocations...

[altenbach]

---

@Yuri33 wrote:
I'm referring specifically to this discussion. 

---

Sorry, I haven't seen that thread yet, but just quickly glancing at it, there are a few things that stick out:

The Stock "2D Cartesian Coordinate rotate" is really optimized to rotate arrays of x and with with a single angle. Now we don't even need a loop and it is quite fast (If you disable debugging and set it ti subroutine, it is even faster, but I would not recommend that).

Of course, if we are dealing with 2D rotations and transformations, using complex numbers comes immediately to mind. We would  represent our two arrays (x and y) as a single complex number array.

A primitive, more explicit rotation attempt is shown (cmplx1 graph), but if we think about it a bit harder, rotation is a single complex multiplication that can be very fast (cmplx2 graph).

All three algoritms shown (2D rotate, cmplx1, complx2) produce the same result.

If we don't count the conversion time to complex (and we shouldn't need to if the program handles everything else natively in complex! :)), the last method (multiplication) seems very competitive to everything discussed in the thread mentioned above. (after some very casual testing).

So, overall we should always remember to think slightly out of the box and look for creative solutions. They're out there!

Back to the reshape issue. What kind of operations are you trying to do on your multidimensional arrays?

Message Edited by altenbach on 07-13-2007 07:58 AM

[Yuri33]

Yes, I see that complex numbers can be utilized for the type of operations they were benchmarking in that thread.  I'm not sure it provides a huge speed boost, but it certainly more readable, and I don't think it's far from the optimal solution.

As far as reshaping is concerned, my code utilizes sparse matricies, so indexing becomes very important in order to avoid lots of useless operations.  In matlab, you could index any n-dimensional array with a linear index (or work with sparse-native functions to begin with), so extracting and replacing components of these matricies is very straightforward and fast.  In LV, I tried to duplicate this behavior by flattening/unflattening matricies with Reshape Array, and using conditional auto-indexing to quickly access or replace elements.  This has worked pretty well, but speed concerns have led me to try and see where the bottlenecks are.  Since buffer allocations are key to performance, I noticed that all my Reshape Array operations were apparently not inline, as the profiler showed that each use of Reshape Array caused a buffer allocation even when the number of elements did not change.

I recoded a few small sections using nested loops instead (my Matlab eyes burned just looking at all those loops!), and I was surprised to find that some sections were as fast or even faster than their vectorized equivalents.  I don't have VI Analyzer or the Execution Trace Toolkit, so I can't (easily) isolate the source of the slowdown, as most of my code now spends its time in LV primatives.  But I suspect Reshape Array is at the heart of it.