Design challenge: find biggest block of true in boolean array

[Florian.Ludwig]

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"

Regards Florian

[smercurio_fc]

---

@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.

[Matt_W1]

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).

[Florian.Ludwig]

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

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

[JW-JnJ]

Hehe, mine constant folds... not entirely fair.

[JW-JnJ]

---

@Florian.Ludwig wrote:

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

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.

[nathand]

---

@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.