Constant Folding of Structures (LV2013)

[ThiCop]

In case I might be confusing people I'll try to use the right terminology.

Above I was refering to the "Dead Code Elimination" which in this case occurs because the array generated by the for loop is not used for any purpose, hence can be considered as "dead code".

This is also one of the optimizations done by disabling debugging.

Edit: I just realized too late that I forgot to explain the concept and Norbert was too fast 🙂

[johnsold]

Thank you Norbert and Thierry for the informative discussion.

This is probably something for the Idea Exchange but constant folding is an indication to the programmer that the compiler is or can be making optimizations which reduce executable code to contants. While it is understandable that debugging may prevent this optimization, I think it would be useful to continue to provide the visible indication that reduction to a constant is possible. While developing code debugging is important. Maybe you guys write code which does not need debugging, but I have not reached that point yet. However, having the compliler tell me that it could reduce a section of code to constants is useful. Requiring to turn off debugging to see what those code segments are is counterproductive. At least make it (viewing possible constant folding) some kind of easy-to-use option.

Lynn

[ThiCop]

Hello Lynn,

I like the statement "Maybe you guys write code which does not need debugging, but I have not reached that point yet", but unfortunately that's not true. 🙂

I totally agree that it would be useful to see where constant folding will occur, but I honestly don't know if this would be practically feasible without "side-effects".

As far as I know and have experienced the constant folding seems to be linked to the actual compiled code and it will require an actual compilation to determine if something is going to be "constant folded".

If how I see this is correct, then this would mean the following:

Goal: We want to have debugging enabled and constant folding visible

Simple Solution:

We need to have 2 things done:

- To enable debugging features: Compile code made with the debugging options enabled for the VI.

- To see the constant folding: Compiled code made with the debugging features disabled for the VI.

This would then require for each compilation two sets of compilations.

This left aside it would still be extremely useful to have a quick button (in the Tools>Profile section?) by default available to check for "possible occurances of constant folding".

My ideal way would be to have two ways of showing constant folding:

1) Indicated with a "positive" color (eg. green): Things that are currently constant folded

2) Indicated with a "negative" color (eg. red): Things that could be constant folded, but currently aren't (either being caused by enabling debugging, by using a reentrant subVI instead of an inlined subVI, etc..)

Even better would be to have an option to say which optimizations this quick tool can do.

The configuration could be comparable to  how one specifyies in the FPGA IP Builder how your code should be optimized (and how not).

[johnsold]

Thierry,

What you propose would be quite satisfactory.

To avoid two compilations if the compiler could set some flags on code which might be possible candidates for folding and show those in red, I think it would be useful even if it were only 80-90% accurate.  The compiler must have some rules for deciding what could be folded. If it could apply those rules to a section of code and then say "the only thing preventing this rule from applying is debugging code," then it could be marked. Debugging code is not part of the source code (as developed by and visible to the programmer on the BD), so the complier should be able to identify it.  I do not know how hard this would be.

I will watch this thread to see what other comments are posted. If nothing that appears to make it completely infeasible shows up here, I will post to the Idea Exchange.

Lynn

[ouadji]

@johnsold :

"The compiler must have some rules for deciding what could be folded. If it could apply ...."

nice dream, but it's almost the same work that a compilation.

In my opinion, it is not feasible ...
this would require almost a compilation ... for any changes on diagram.

[Norbert_B]

---

@johnsold wrote:

[..]but constant folding is an indication to the programmer that the compiler is or can be making optimizations which reduce executable code to contants.[...]

---

 Lynn,

the point is that showing constant folding results in a display of what the compiler already optimized for you. Please note: this is past tense!

So, if there is no compilation, no constant folding will be shown.

---

@johnsold wrote:

[...]Maybe you guys write code which does not need debugging, but I have not reached that point yet.[...]

---

"If debugging is the process of removing bugs from software, programming must be the process of putting them in." - Unknown

You know, nobody writes bug-free software. And if he states this, he either lies or doesnt write applications, but peanuts. (Btw, see myth here, remark of Darin 😉 )

No debugging is a very important process and debugging must be enabled during development. BUT, when coming closer to release testing, the developer has to remove the debugging option from his VIs in order to analyze if the VIs will perform well in executable-surounding.

Norbert

[Norbert_B]

---

@johnsold wrote:

[...]The compiler must have some rules for deciding what could be folded. If it could apply those rules to a section of code and then say "the only thing preventing this rule from applying is debugging code," then it could be marked. [..]

---

That is exactly what LV 7.x and older do.

NI moved away from this for several reasons. Two are most obvious:

- For esp. bigger block diagrams, continuous re-compilation takes time and as only sections are re-compiled, it is possible that the whole VI breaks. This has happened in the past, sometimes a force compile of the VI solved the issue, sometimes (for VERY big BDs), the programmer had to split the code into subVIs or stick with a corrupt VI.

- Some optimizations are so complex, that taking a limited section of code cannot grant the possibility for such optimization. Take "inplaceness" for instance: You cannot chose if a data is NOT copied if only looking at a very limited part of the code. The only thing you can state is if that code segment REQUIRES a copy.....

The only option nowadays would be to have the compiler run with debugging disabled, mark all the structures and then re-compiling with debugging enabled but keeping the marks.

This will essentially more than double compile times, which is for most users unwanted. Also, the marks are not correct anymore as the structure are not folded anymore....

Norbert

[johnsold]

Norbert,

Thank you for the thoughtful and comprehensive explanation.

I think I will drop the idea of requesting that it goes back to the older method.

However, it does seem that showing constant folding of structures is essentially useless now.

Lynn

[Norbert_B]

---

@johnsold wrote:
[..]However, it does seem that showing constant folding of structures is essentially useless now.

Lynn

---

Lynn,

i contradict on that one. Why should LV display something which is not true?

With debugging enabled, no structures are folded.

Without debugging enabled, structures are folded and it is displayed like that.

I concur with your wish to display "foldable" structures, but honestly....what is the gain of that?

Let me give an example:

You require an array with 5 elements, starting from 12, incrementing each value up to 16. So you got two choices:

a) implement the VI as shown in the OP

b) create a constant manually with the elements.

Option b) is better when working with small arrays. But as soon as the number of elements is larger than one screen could display for option b), option a) is the far better choice.

Sure, during development (and debugging), you carrry some overhead, BUT that is removed once disabling debugging. On the other hand, the code is way more readable as you see with a single look on the BD what is minimum and maximum within the array.....

EDIT: So overall, the display of constant folding is "only" a remark of the compiler showing the developer where optimizations have been done. Constant folding never showed more than that in previous versions and most likely never will in future versions. And knowing which structures are foldable during development does most often not give you any advantage as.... if a structure is not foldable, what do you have to do in order that the compiler WILL fold it???

Norbert

[jcarmody]

Quick Drop 🙂