How good is the 'G' compiler on optimisation?

[kimdino]

Hi folks,

When I am writing reuseable modules in 'C' libraries I know I can concentrate on making the modules versatile and easy to manage. This is because I know that modern 'C' compliers are very good at optimisation and that the compiler will eliminate irrelevant code and tune the object for each particular use. How far does the same apply to 'G'?

Cheers, Kimdino

[tst]

Because LabVIEW does dynamic memory allocation, the main causes for performance issues are continuous memory allocations and memory copies.

LabVIEW is very good at optimizing these, but you as the programmer are required to know where and when LabVIEW creates copies of data if you want an optimized program.

Here's a short list of some potential causes of memory allocations:

• Local variables.
• Global variables.
• Wires which are not split cleverly.
• SubVI terminals which are inside structures.
• Probes.
• Resizing operations.

LabVIEW 8.5 added a couple of nodes and structures to allow even finer control of this.

If you want some relevant reading material, try searching for application note 168, which describes some of the issues. It's a bit old, but the concepts still apply.

[TCPlomp]

Quite good.

A piece of code where the output is not connected might not be executed.
I've noticed this when I had property node that didn't return an error code if one of the outputs wasn't connected, while if I connected the output the property node would return an error.

So if the output isn't used the property wasn't read (optimization)

Ton

[kimdino]

Thanks tst,

The main thrust of my question is on dead code elimation. If a constant (say 3) was supplied as the selector to a Case statement so that the code in the other cases would never be used. Would the compiler be intelligent enough to spot this and leave out the code for cases 0,1,2,4 etc from the built code.

Cheers, Kimdino

[F._Schubert]

I don't understand the purpose. It will maybe spare you a few kB in the exe-size. Nothing when having 8 MB runtime-engine. The case also will cause minimal overhead in execution speed.

Felix

[Andrey_Dmitriev]

Hi, Kimdino,

I don't think so, and you can perform simple test yourself. For example, if you will put such construction on your block diagram:

and then build the application, then you will get constant in your builded application (but this constant is not connected, isolated with case, and disabled with disable structure).

regards,

Andrey.

[TCPlomp]

Andrey,
how and in which LabVIEW version did you tested this?

Ton

[kimdino]

Hi Felix,

The purpose, in this instance, is having a library module that adapts to the purpose it is being linked into.

For example - A system we use here of displaying how good the data is. In the case of a bad data connection we indicate this by greying out the control or indicator displaying the data. As each of our apps feature dozens of controls & indicators with one having several hundred this is a piece of functionality well worth paying significant attention to. We have written a library module that tests the connection and sets the 'Disabled' status accordingly. However, we have found that controls & indicators need different treatment so we currently have two separate library modules, one for controls & one for indicators. The current modules are very simple & may be implemented as 'inline'? So here we have one optimisation query - does the 'G' compiler do 'inline'?

Having just one library module that responded accordingly as to whether it was being applied to a control or indicator would be nice. However, the source code is three times bigger. So I would probably lose the 'inline' functionality.

As a library module the object type is a variable & needs to select different code according to whether it is applied to a control or indicator. However once the module is inserted in a programme the object type become a constant - a control will never change to an indicator & vice-versa.

This particular use is perhaps a bit more complex than usual & requires a lot from the compiler but it serves to illustrate the point. A good 'C' compiler, such as 'gcc', could spot that in this usage the other cases will never be called and remove the dead code. It might even then be able to restore the 'inline' functionality it it was really clever.

I think that ultimately this will just come down to try-it-and-see.  However, I am hoping to gain some insights into the 'G' compiler workings for when future queries arise.

Cheers, Kimdino

[tst]

---

kimdino wrote:

If a constant (say 3) was supplied as the selector to a Case statement so that the code in the other cases would never be used. Would the compiler be intelligent enough to spot this and leave out the code for cases 0,1,2,4 etc from the built code.

---

In LabVIEW 8.x the answer to that question should be yes, but if what Andrey is showing is correct, it looks like it doesn't work perfectly. In any case, you should note that LV machine code is probably not as efficient as the code created from optimized C code (I'm talking about a case where the C code itself is optimized). You might wish to read some of these for more details, but you should note that they are also relatively old.

[Andrey_Dmitriev]

Hi, Ton,

LabVIEW 8.5

Test project  in the attachment. That was a quick test, probably something wrong. Anyway without constant - size of the executable is small, and wit unused constant increased.

regards,

Andrey