constant folding bug

[Kevin_Price]

I think it's mainly semantics and the docs should be improved, including the purpose for highlighting an example like yours as "constant folding."

I agree that there's no performance advantage in your example at the point where constant folding is displayed.  However, I personally happen to like the choice of displaying the gray bars inside the loop.  To me, the meaning is fairly clear -- as the wire passes through the loop boundary, something happens such that inside the loop the value becomes constant.  Yep, sounds right.  A good reminder about tunnels into loops, especially for beginners, IMHO.   What kind of confusion would you anticipate beginners to have?

-Kevin P.

[altenbach]

One of the conceptual problem is the fact that "folding" a single constant is really a degenerate case. 🙂 "Folding" typically invloves a reduction of multiple values to a single constant.

Have a look at the attached case. Now folding inside the loop is useful and it means that the addition is only done exactly once instead of 4 times.

You can easily extrapolate that this can lead to tremendous savings if complicated operations and high loop counts are involved. Of course a seasoned LabVIEW programmer would place the addition explicitely before the loop. But now with folding even crappy code can have decent performance. This is very important! 😄

Also have a look at my picture posted here:

http://forums.ni.com/ni/board/message?board.id=170&message.id=202657#M202657

Message Edited by altenbach on 09-26-2006 11:06 AM

[chrisger]

well: "I agree that there's no performance advantage in your example at the point where constant folding is displayed...."

in my opinion this is exactly the point where someone could think of an performance advantage where there is none. it's the purpose of that highlightning feature to show these advantages, so i think this should be corrected.

please confirm or correct my understanding of constant folding:

"if i wire a constant value (that means a value thats independent from any dynamic parameters at runtime, like a boolean or numeric constant. the constant value could also be the result of a calculation from other constant values. constant values are already known at design time) to a case structure, the cases that are not reached are not compiled to the runtime code. such constant values and case structures are then highlighted for visualisation. this results in smaller code and less calculations at runtime and therefore in a performance advantage."

is this correct?

[chrisger]

altenbach: "Now folding inside the loop is useful and it means that the addition is only done exactly once instead of 4 times."

i start to think that "constant folding" is in fact more that i thought at the beginning. i understand your example and see the advantage and the difference to prior versions. in fact this is big improvement.

thanks 

[CoastalMaineBird]

So, a couple of months later, here I come.

I came from this thread, BTW:

http://forums.ni.com/ni/board/message?board.id=170&message.id=215910&view=by_date_ascending&page=1

That fact that your (admittedly silly) above code example's performance can be improved by constant folding is vastly outweighed by the fact that it's just plain buggy. In this example, it tries to "improve performance" by preallocating a memory block, even though there is NO WAY you can think that that is what the code is supposed to do.

Take a look at this picture:

If you RUN the BUG CALLER, you will get a MEMORY FULL message, because it's trying to be "helpful" and pre-allocate the array for me. This is in spite of the fact that I'm really calling the SHUTDOWN function (which dows nothing), not the ALLOCATE function. Code is attached.

Message Edited by CoastalMaineBird on 11-17-2006 09:57 AM