LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Design challenge: find biggest block of true in boolean array

Sorry for the double post,

 

but there is one clarification to be made:

The corner case of the array elements all being false is of no concern to me in that piece of code. If that is the case I handle things differently anyway.

 

Sorry for making you guess - but smercurio seems to be the best at "guessing what Florian wants" Smiley Happy

 

Regards Florian

0 Kudos
Message 31 of 37
(560 Views)

@altenbach wrote:

smercurio_fc wrote:

I'm not sure I understand. It's comparing the two different index outputs. How can they be the same (unless they both come out to be -1)?


Look for the red text..... 😉

 

 


Oh, yeah - missed that. Well, that's what you get for slapping a VI together rather quickly and then not fully testing it (and not seeing the obvious duplication). After all, I wasn't trying to win a prize, but just show an alternative implementation that didn't use as many shift registers. Not implying that shift registers are bad - it was just an alternative.

0 Kudos
Message 32 of 37
(543 Views)

If you turn off debugging on your new benchmark the performance of the different methods changes drastically. JW-L3CE goes from 1 sec to 7 ms on my home computer which appears to blow all the other methods out of the water. Florian2 also seems to do far better. But if you adjust Numerisch those two's scores don't change which indicates the code optimizer removed the test repetition. If you duplicate the input data you disallow the optimizer from breaking the comparison.

Mine gains the most from disabling debugging going from 180ms to 46ms (4x faster) the next biggest gain is GerdW  from 139 to 93 (1.5x faster).

Message 33 of 37
(522 Views)

It's interesting to see how differently those pieces of code are affected by debugging. Smiley Surprised

I don't know nearly enough about that switch to guess why this happens.

 

Duplicating the input data is important to know for anyone who wants to benchmark code!

Thanks for that tip.

 

Regards

0 Kudos
Message 34 of 37
(514 Views)
Hehe, mine constant folds... not entirely fair.
Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 35 of 37
(512 Views)

@Florian.Ludwig wrote:

It's interesting to see how differently those pieces of code are affected by debugging. Smiley Surprised

I don't know nearly enough about that switch to guess why this happens.

 

Duplicating the input data is important to know for anyone who wants to benchmark code!

Thanks for that tip.

 

Regards


I'm not sure why switching to debug caused this, but it constant folds my entire code in that VI. The only thing it does within the sequence frame is use the constant to update the indicator a number of times. Hence the speed.

 

Not sure how to fix that from a bechmark standpoint. Maybe randomly generate a set of input arrays.

Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 36 of 37
(477 Views)

@JW-L3CE wrote:

I'm not sure why switching to debug caused this, but it constant folds my entire code in that VI.

 

Not sure how to fix that from a bechmark standpoint. Maybe randomly generate a set of input arrays.


You can usually prevent constant folding by changing a constant to a control, even if you just give it some default value and don't change it.

0 Kudos
Message 37 of 37
(461 Views)