C# and compiler optimizer.

[Olaf Baeyens]

I am trying to understand the IL assembler created by C# but as far as I can
see, there is no optimizing done by the C# compiler.
Optimizing is done by the JIT, but it can only go so far.

In C++ you can put the 'inline' keyword for properties and methods that
could be inserted into the generated code so you avoid a call and thus the
overhead, but as far as I can see, C# does not seem to have this
functionality.

Or is it because I use the VC# 2003 standard edition that this optimizing is
not done?

 

[Mattias Sjögren]

I am trying to understand the IL assembler created by C# but as far as I can
see, there is no optimizing done by the C# compiler.
Optimizing is done by the JIT, but it can only go so far.

The C# compiler does some optimizations itself if you compile with
/o+, but you're right that most of it is done by the JIT compiler.

In C++ you can put the 'inline' keyword

And the compiler is free to ignore it.

but as far as I can see, C# does not seem to have this
functionality.

Right, but the JIT compiler will inline some method calls.

Or is it because I use the VC# 2003 standard edition that this optimizing is
not done?

No.



Mattias

 

[Helge Jensen]

I am trying to understand the IL assembler created by C# but as far as I can
see, there is no optimizing done by the C# compiler.
Optimizing is done by the JIT, but it can only go so far.

<theory>
A JIT can just start by running the optimizations a traditional compiler
would do. Offline compilers can never be more "optimizing" than JIT.

In C++ you can put the 'inline' keyword for properties and methods that
could be inserted into the generated code so you avoid a call and thus the
overhead, but as far as I can see, C# does not seem to have this
functionality.

Even in C++, "inline" is a linkage-specifier, not a specification of
inling. The c++ compiler can choose to emit it as a separate function
and call-instructions, but the function must have internal linkage.

You can easily verify this by compiling a recursive function:

inline int f(int x) { return f(x+1); }
int main(int argc, string** argv) { return f(0); }

Compilers (and some JIT's) today have *very* advanced analysis of when
inlining should be applied and when it should not.

Which specific performance problem do you have which can be solved by
letting you specify inlining?

 

[Olaf Baeyens]

I am trying to understand the IL assembler created by C# but as far as I
can

The C# compiler does some optimizations itself if you compile with
/o+, but you're right that most of it is done by the JIT compiler.



And the compiler is free to ignore it.

True in a lot of cases, the C++ compiler just doesn't inline this part if I
look at my code.

Right, but the JIT compiler will inline some method calls.

I did not notice this before, but it would be nice.

 

[Olaf Baeyens]

Compilers (and some JIT's) today have *very* advanced analysis of when

inlining should be applied and when it should not.

Which specific performance problem do you have which can be solved by
letting you specify inlining?

Doing vector calculation, a few millions of them in one pass.
Those vectors have public properties X, Y and Z that (looking at IL asm)
appears not to be inline even though they are just stupid float without any
additional coding.
But for the moment I have nothing to compare to yet. I am still developing
the code. But it would be nice to know these things before I go too deep in
the creation of the code and discover that is slows down too much. Then I am
going to look at the generated x86 code to see what the JIT did do.

<theory>
A JIT can just start by running the optimizations a traditional compiler
would do. Offline compilers can never be more "optimizing" than JIT.
</theory>

Yes assuming they have tons of time to analyze your program running and
optimize most used functions even further dynamically.
Somehow it would be nice if a second compiled copy of your program could be
stored on the harddisk. And every time it gets loaded, it gets optimized
even further, so the more you use the program the faster it becomes. But I
guess that is not for tomorrow.

Compilers (and some JIT's) today have *very* advanced analysis of when
inlining should be applied and when it should not.

One of the things I am wondering is does you get a performance loss if you
use a class in one assembly that is defined in another assembly?
The assemblies are dll's, and I do know that dll's creates overhead in the
transition from one executable into your dll function.

 

[Helge Jensen]

Doing vector calculation, a few millions of them in one pass.

Aaah, you're actully doing something -- not just reacting to GUI

Try to do some timings on it, it may be as fast as native, or it may not...

If it is slow, you could try to factor that part of the code out, so you
can reimplement it natively when performance starts rearing it's ugly head.

Those vectors have public properties X, Y and Z that (looking at IL asm)
appears not to be inline even though they are just stupid float without any
additional coding.

Why are you using properties? are you implementing/inheriting an
interface/class?

The exported code has to have the public properties, for other code to
be able to acces them, they are public

The JIT might inline the access while running, if it's called a lot.

the creation of the code and discover that is slows down too much. Then I am
going to look at the generated x86 code to see what the JIT did do.

Generally, doing a test with timings is a very informative and cheap way
to evaluate performance.

Yes assuming they have tons of time to analyze your program running and

optimize most used functions even further dynamically.

One of the things I am wondering is does you get a performance loss if you
use a class in one assembly that is defined in another assembly?

Try to make some timings, it won't take long I wouldn't expect any
difference.

The assemblies are dll's, and I do know that dll's creates overhead in the
transition from one executable into your dll function.

But this is JIT, and the resolution of the just-address-resolution
*could* be done just once, when the code is jit-compiled and inserted
literally into the compiled version of the code. Try and time it.

 

[Olaf Baeyens]

Which specific performance problem do you have which can be solved by

Aaah, you're actully doing something -- not just reacting to GUI

I am implementing a scene library in OpenGL. Pretty complicated stuf to be
used for visualizing CT images.
It works darn good, only users don't want to install the .NET framework, so
I will probably end up having to do it the unmanaged C++ way. But right now
I am using the C# way because I speed up development, and porting to C++ is
pretty easy to do, and I still have time left then I would have done it in
C++ directly.

I use the NUnit for testing my mathematics things for accuracy. I love it
very much, since it speeds up testing dramatically.

 

[Christoph Nahr]

Doing vector calculation, a few millions of them in one pass.
Those vectors have public properties X, Y and Z that (looking at IL asm)
appears not to be inline even though they are just stupid float without any
additional coding.

Inlining of trivial property getters/setters is done by the JIT
compiler, so that's actually not a problem.

However, your project sounds as if it could profit from some
higher-level optimizations which the C#/VB and JIT compilers aren't
doing, neither in this nor in the next version -- the MS teams are too
busy implementing new features, I suppose.

That leaves the C++ compiler which is the only one that emits
optimized IL code. Unfortunately the current version of C++ for the
..NET Framework (called "Managed C++") is pretty ugly but .NET 2.0 will
ship with a much improved version called "C++/CLI".

 

[Olaf Baeyens]

However, your project sounds as if it could profit from some

higher-level optimizations which the C#/VB and JIT compilers aren't
doing, neither in this nor in the next version -- the MS teams are too
busy implementing new features, I suppose.

That leaves the C++ compiler which is the only one that emits
optimized IL code. Unfortunately the current version of C++ for the
.NET Framework (called "Managed C++") is pretty ugly but .NET 2.0 will
ship with a much improved version called "C++/CLI".

I am already using mixed managed/unmanaged C++
But the code I create now is pure C#, because I can test it faster (much
faster compiler) and create a fully functional version. So I can port it to
unmanaged C++ without losing the time to test too deep. Only testing if I
get the same results, but functional testing is already done ine C#.

At the same time I have already code available to fully managed and create
one executable that will both run on 32 and 64 bit while taking the full
advantage of 64 bit when The VS 2005 comes available.

So it is a strategy to lower the development cycle by prototyping in C#, and
preparing the code for the future at the same time.

 

[Daniel O'Connell [C# MVP]]

However, your project sounds as if it could profit from some

higher-level optimizations which the C#/VB and JIT compilers aren't
doing, neither in this nor in the next version -- the MS teams are too
busy implementing new features, I suppose.

The current scuttlebutt is an IL optimizer instead of individual
optimizations in the compilers, saving everyone time. No clue if it'll
actually happen or not though, or what kind of context would be lost.