LabVIEW
Request: Make these VIs faster for large arrays
Solved!
And here are the OP Vis in 2009.
Both are broken! 😞
(There are two missing typedefs and the timing is done with openg tools, which you might, or might not have installed.)
For the timing, just use the "tick count" and a three-frame flat sequence like I did.
For the typdefs, just right-click and disconnect from the typedef to eliminate the error.
Good luck! 🙂
Well, for what its worth i had ago also:
To begin with the speed was comparable with Altenbachs so i upped the amount of data being input. Alas Altanbachs was faster. In the above configuration, both inputting 100x the given probe array Altenbachs processed in around 240ms and mine in around 313 ms. The only saving grace for mine is that i can actually understand what i have done 
After going through Altenbachs approach again i can see what he has done, great learning tool this website.
Rgs,
Lucither
@Lucither wrote:
Well, for what its worth i had ago also:
...
. The only saving grace for mine is that i can actually understand what i have done
After going through Altenbachs approach again i can see what he has done, great learning tool this website.
Rgs,
Lucither
Kudos for taking a cracking at beating Christian's code!
For about 3 years I repeatedly attempted to better his code and with one exception (it was a corner case) I could never come up with code that beat his performance. But boy did I learn alot while trying!
One note on the benchmark code posted early on...
Indicator updates will really screw with your numbers when you are trying to campare performance. Make sure that ONLY the code you are benchmarking is in the seq. Also watch for constant and loop folding and buffers being re-used if comparing two version at the same time.
Again, NICE TRY!
Ben
Thanks for the advice, i took all control/indicators out of the sequence stucture, i also removed the 'Array Size' function out of my loop and moved it to the outside, i re-tested and to my complete suprise ............. I still never beat near Altenbach, there was an improvement though, i am now down to an average of 305ms. Close but no cigar, have enjoyed the challenge though. I'm happy because in all honesty i never expected to beat Altenbach and that was never my intention (honest). Just always looking to improve performance, my wife does Sudoku, i do this. Quite funny actually because my wife just came into my room watching me modify my code and said "For once i'd like to catch you watching porn!". Anyway here is my final version after the comments:
Thanks again for your comments, always welcome.
Rgs,
Lucither
@dthor wrote:
Oh man, those work wonderfully! I'm sitting here and just saying "Wow!" over and over again. I guess I marked the solution a bit too soon though, eh altenbach?
A word of advice to everyone on this board. Never mark a solution until altenback has weighed in. EVER !!
I did not doubt that both methods should be similar in speed, you just do the same with X times more code and diagram real estate. 😉
More code makes it easier for bugs to hide. 😮
The speed differences will also depend on the number of 1s in the original array. If there are very few, my version offers a bigger advantage because it quickly skips of all the blanks, and the number of loop iterations will be small. Your's might be better if the input is mostly 1s.
If anyone want to try, I am sure it could be further optimized to take advantage of multiple CPU cores, for example. 😄
@Lucither wrote:
Thanks again for your comments, always welcome.
Just looking at the picture, here's a quick simplification:
After the main loop, you take the arrray subset. This is not needed here! Simply wire the 2D array directly and also wire the "valid size" from the shift register to N of the last FOR loop and the data will be truncated automatically. This might even avoid an extra datacopy, not sure....
