Question about optimised compilation?

[tsdt]

Hi,

I noticed that there is a checkbox in the compile field that says optimised compilation. I was wondering that how is the code compilation being optimised.

For example:

How does the code being optimised for the following example?

x=0

if x = 0 then
goto pp
else
goto yy
end if

Thanks.

:icon_clap:

 

[agraham]

In the past "compilation" in basic4ppc referred to the translation of the code to bytecodes and the packaging of it for interpretation by a runtime engine. When true compilation, in the form of translation to C# code and the actual compilation of that code to an executable was introduced the term "optimised compilation" was introduced to differentiate it from the original "compilation". From version 6.90 only "optimised compilation" is available which can now be referred to as "compilation" with no possibility of misunderstanding.

 

[tsdt]

In the past "compilation" in basic4ppc referred to the translation of the code to bytecodes and the packaging of it for interpretation by a runtime engine. When true compilation, in the form of translation to C# code and the actual compilation of that code to an executable was introduced the term "optimised compilation" was introduced to differentiate it from the original "compilation". From version 6.90 only "optimised compilation" is available which can now be referred to as "compilation" with no possibility of misunderstanding.

Thanks Agraham for the reply. By the way, can B4PPC do any optimisation like the code above? This is also quite important to know on that one.

:icon_clap:

 

[agraham]

do any optimisation like the code above?

I'm afraid I don't understand what you mean by this, nor why it is important. The C# compiler does some optimisations and the .NET Common Language Runtime Just In Time compiler will (on the desktop at least) do further performance code analysis and performance optimisations. What these optimisations are is not documented and I see no need to know what they are just as I see no need to see what the processor is doing when it in turn is optimising the machine code by performing branch prediction and out of order execution. As long as the code performs as I expect I don't care about such things.

Nowadays it's a far cry from the days of writing machine code for a Z80, using your own home-written assembler, where you knew what was happening right down to the silicon level and could even guess the microcode sequences for each instruction and because of this predict what the undocumented "missing" opcodes might do.

 

[tsdt]

I'm afraid I don't understand what you mean by this, nor why it is important. The C# compiler does some optimisations and the .NET Common Language Runtime Just In Time compiler will (on the desktop at least) do further performance code analysis and performance optimisations. What these optimisations are is not documented and I see no need to know what they are just as I see no need to see what the processor is doing when it in turn is optimising the machine code by performing branch prediction and out of order execution. As long as the code performs as I expect I don't care about such things..

I need to know that because I was thinking of reducing my loading time to the processor. At the moment, I noticed that B4PPC does not have preprocessor like #ifdef and hence, the only way, I can reduce the code loading time, is by reducing the module or actual code size.

The other way is via compilation optimisation. For example: if I code like the above way, then, the compiler will be smart enough to ignore the rest of the code from compiling and hence, my code size would be smaller and indirectly, my loading time would be small too.

This is why I was asking about this. Or if you have a other better way of reducing the loading time, it would be nice if you can share with us

Thanks Agraham. :icon_clap:

 

[agraham]

"Loading" a .NET application is not like loading a native code program. It is a progressive process that reads the Intermediate Language bytecodes for the CLR virtual machine and then proceeds something like this.

The application is started and as each class is needed it is built in memory and it's constructor Just In Time compiled (JITed)to machine code and executed. When an instance of each class is needed it in turn is built in memory, its constructor JITed and executed. Similarly as each method is called it is JITed and run. Once a method is JITed the code is saved so JITing is only performed once when needed. Uncalled methods are not JITed. If memory is short then the JITed code can be discarded and re-JITed if the method is called again.

Uncalled methods are never JITed so code size itself is not a factor in "loading" performance.

Richter - "CLR via C#, Second Edition" Chapter 1 has a good description of the desktop version of this process.

The device and desktop JITers are optimised differently. The desktop analyses the IL and tries for the best performance, for instance by in-lining simple property accesses. The device JITer is more concerned with JITing speed than with outright performance and so does far less runtime optimisation than the desktop version.

 

[tsdt]

:icon_clap:

"Loading" a .NET application is not like loading a native code program. It is a progressive process that reads the Intermediate Language bytecodes for the CLR virtual machine and then proceeds something like this.

The application is started and as each class is needed it is built in memory and it's constructor Just In Time compiled (JITed)to machine code and executed. When an instance of each class is needed it in turn is built in memory, its constructor JITed and executed. Similarly as each method is called it is JITed and run. Once a method is JITed the code is saved so JITing is only performed once when needed. Uncalled methods are not JITed. If memory is short then the JITed code can be discarded and re-JITed if the method is called again.

Uncalled methods are never JITed so code size itself is not a factor in "loading" performance.

Richter - "CLR via C#, Second Edition" Chapter 1 has a good description of the desktop version of this process.

The device and desktop JITers are optimised differently. The desktop analyses the IL and tries for the best performance, for instance by in-lining simple property accesses. The device JITer is more concerned with JITing speed than with outright performance and so does far less runtime optimisation than the desktop version.

Thanks Agraham for your reply.

So, is that the reason why "loading" into WinCE platform is slower compare to "loading" into WinMobile platform?

In this case, there is nothing we can do to enhance the speed of the "loading" except reduce the code size right?

:icon_clap:

 

[agraham]

:So, is that the reason why "loading" into WinCE platform is slower compare to "loading" into WinMobile platform?

No, for the same version of .NET on both platforms performance should be the same. I would guess that any difference is due to different platform processor clock speeds.

In this case, there is nothing we can do to enhance the speed of the "loading" except reduce the code size right?

Correct!

 

[tsdt]

No, for the same version of .NET on both platforms performance should be the same. I would guess that any difference is due to different platform processor clock speeds.
Correct!

Thanks Agraham.

Last question. There is no preprocessor for B4PPC to actually commented out the unused modules (but, cant remove because of those modules might be useful for other products), how do you normally do it to reduce the code size besides commented out those codes (which, will change a hell lots of the structure.)

Please advise.

Thanks.
:icon_clap:

 

[agraham]

I can think of no other way than to keep two (or more) copies of your application using common modules where possible and trying to isolate the differences in as few other modules as possible.