LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Request: Make these VIs faster for large arrays

Solved!
Go to solution

 

 


 

For all typical inputs, all versions are "fast enough", so this exercise is mostly academic:smileywink:

 

 

 


Unfortunately for me everything i do using LabVIEW is purely academicSmiley Sad

 

------------------------------------------------------------------------------------------------------
"Everything should be made as simple as possible but no simpler"
0 Kudos
Message 51 of 59
(1,587 Views)

OK, just to wrap this up, here's a quick benchmarking application in LabVIEW 2009 that allows comparing the various algorithms discussed in this thread. It's not very polished, but works OK for as a demo.

 

As mentioned before, LabVIEW 2010, is a bit faster than 2009. The two images show he results of equivalent runs. Of course there is quite a bit of shot noise due to the small number of milliseconds for the default inputs. We should pick the shortest time for each run.

 

I am sure a faster algorithm could still be found ... 🙂

 

Note that my algorithm is fastes for the default inputs. For very sparse arrays, Lucither's code is faster because it can skip empty rows more efficiently.

 

 

Message 52 of 59
(1,576 Views)

Nice post. I like the use of the in-place element structure. Will have to remember that one.

 

Rgs,

 

Lucither.

------------------------------------------------------------------------------------------------------
"Everything should be made as simple as possible but no simpler"
0 Kudos
Message 53 of 59
(1,567 Views)

 

I've been continueing to monitor this thread, and I've learned quite a bit. Thanks you two!

@altenbach wrote:

 

Note that my algorithm is fastes for the default inputs. For very sparse arrays, Lucither's code is faster because it can skip empty rows more efficiently.


And that's exactly what I need! A happy medium between an array full of 1s and an input array full of 0s.

 

0 Kudos
Message 54 of 59
(1,550 Views)

A very interesting thing to note on my W7 64-bit is the followingBenchMarkModels.png

 

/Y:

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 55 of 59
(1,505 Views)

Also interesting to note is that if i use In place elements on basically all operations it's actually a little slower, i land at about 1,12.

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 56 of 59
(1,500 Views)

Yes, if you look at the buffer allocations, you can see that my code is fully "in place", so an in place element structure would not contribute anything new when used as a substitute for "replace array subset".

 

The in place structure probably does have slightly more overhead, because it does more and also provides the existing element as inner output, which is only needed for the increment operation where I use it. Just guessing....

0 Kudos
Message 57 of 59
(1,488 Views)

 


@Yamaeda wrote:

A very interesting thing to note on my W7 64-bit is the following


Oh, I am sure there will be subtle differences based on CPU architecture, cache levels, etc. What is the exact model of your CPU?

 

0 Kudos
Message 58 of 59
(1,484 Views)

Since just a couple of months, this rig is a AMD Phenom x6 1090T.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 59 of 59
(1,478 Views)