Performance issues when operating on arrays in clusters when using in-place structures and inlining?

[Intaris]

Again, Can anyone please save for LV 2012?  I had a recent spate of IPE performance issues on my RT systems and would like to have a look to see if I can recognise any of my problameatic patters from there.

[Mads]

Here is the code saved in LabVIEW 2012.

I have kept it without the suggested parallelization just to keep the same reference performance, but the Get Neighbours VI is updated with a slightly faster code.

[JÞB]

mads

After playing with your code a bit I was able to get @16dB more out of it 

What was reall really killing you was get neighbors.vi

Do the logic before the loop 

Sorry for leaving it a mess and 

EDIT: I messed up some logic there..... back in a bit

ah The top less than is miss wired!

[JÞB]

OK so not quite as dramtic with the wiring fixed but still noticable.  You can also wrangle a bit by auto-indexing these arrays the areas that have less than 8 neighbors wont execute 8 times

Although moving the logic outside the loop here does not improve performance 

All in all I wound up with a @ 4x reduction (or almost half the speed of your C routine)

I imagine thereare a few other places you could tweak especially in the Solve Quadratic.vi  (Thast was the next biggest time hit with the profiler on) 

[Mads]

Jeff. I did try having the logic outside the loop in the Get Neighbours VI as I too expect that to be faster, but the result (in LV2014) was that it ran a bit slower.

I'll retry it tomorrow and see if I missed something though. Thanks for the help so far

[JÞB]

---

@Mads wrote:

Jeff. I did try having the logic outside the loop in the Get Neighbours VI as I too expect that to be faster, but the result (in LV2014) was that it ran a bit slower.

I'll retry it tomorrow and see if I missed something though. Thanks for the help so far

---

That would explain why my 2013SP1F2 code ran much slower than your benchmark.  That optomizer gets smarter every year.  I would not be surprised if that code migration was native to 2014 and not 2013.  

Of course, Christian is likely to come along and show you how to get it 100X faster and embarass us all. 

Just for giggles-  Try various values for the C (Clumper) terminal on that outermost loop.  Also, I did note a slight (almost in the mud) improvement between "Select" and boolean driven cases where all values are computed anyway.  I would be interested if you can observe the same.

Is there any chance of seeing the C code?  Or at least the relative benchmarks?

[Mads]

I did manage to squeeze out an 8% improvement by changing the Get Neighbours.Vi now, but not by operating on arrays outside the loop.

Instead I replaced the parallell comparisons with a sequence of case structures...(thinking that this would reduce the total number of operations needed in any case where the conclusion is that the coordinate is not a neighbour).

I have attached the latest version that has that change. With this I'm now down from 1,65 to 1,52 seconds without the parallalization (0,41 seconds with) in LV2014 on my machine.