JIT compiler global optimization ?

[Guest]

I do a project using C# and C++ .NET and have some functionality to convert
imperial to metric units and vice versa.

In VC6 I just used a simple header file with some constants (e.g. const
double MM_TO_INCH = 1.0/25.4.

For .NET I thought it might be a good idea to have a class with static
methods for that to use in C# as well as C++ code.
C# didn't work well for that because I could not overload methods if they
only differ in types.
So I did the implementation in a C++ class called Units (e.g. static Double
MMtoINCH (Double MM) { return MM/(Double)25.4; } for the basic float types.

It works, but my concern is about the performance.
With VC6 the compiler would easily replace the function call by inlining the
code.
With .NET I have the IL code in an assembly which needs to be loaded and
then compiled by the JIT.

Does anyone know how good the JIT compiler handles this issue? Is he able to
do the same kind of global optimization? Do I lose performance?

Thanks
Carl

 

[Niki Estner]

I do a project using C# and C++ .NET and have some functionality to
convert
imperial to metric units and vice versa.

In VC6 I just used a simple header file with some constants (e.g. const
double MM_TO_INCH = 1.0/25.4.

For .NET I thought it might be a good idea to have a class with static
methods for that to use in C# as well as C++ code.
C# didn't work well for that because I could not overload methods if they
only differ in types.

Do you mean differ in return types?
That applies to C++ as well.

So I did the implementation in a C++ class called Units (e.g. static
Double
MMtoINCH (Double MM) { return MM/(Double)25.4; } for the basic float
types.

Doing e.g. this:
static double MMtoINCH (double MM) { return MM/(double)25.4; }
static float MMtoINCH (float MM) { return MM/(float)25.4; }

In C# works fine.
Post a sample if you need help on that topic.

It works, but my concern is about the performance.
With VC6 the compiler would easily replace the function call by inlining
the
code.

So does the JIT. (in a release build)

With .NET I have the IL code in an assembly which needs to be loaded and
then compiled by the JIT.

Does anyone know how good the JIT compiler handles this issue? Is he able
to
do the same kind of global optimization? Do I lose performance?

Actually, the .NET JIT can inline function calls even across assembly
borders: If your helper functions are in one assembly, the code that uses
them in another one, the JIT will still be able to inline the calls.

Niki

 

[Guest]

Do you mean differ in return types?
That applies to C++ as well.

You're right it works or works not in C# and C++ the same way. I missed to
change the parameter type in my C# test class, not just the return type.

Doing e.g. this:
static double MMtoINCH (double MM) { return MM/(double)25.4; }
static float MMtoINCH (float MM) { return MM/(float)25.4; }

That's exactly how I did it in C++. Tried to use a template first, but was
not successful with that.

So does the JIT. (in a release build)
Actually, the .NET JIT can inline function calls even across assembly
borders: If your helper functions are in one assembly, the code that uses
them in another one, the JIT will still be able to inline the calls.

That's great and is exactly what I liked to know.

Thanks a lot
Carl

 

[Guest]

Do you mean differ in return types?
That applies to C++ as well.

You're right. It work or works not the same way in C++ and C#. I missed to
change the parameter types in my C# test class (not only the return types).

Doing e.g. this:
static double MMtoINCH (double MM) { return MM/(double)25.4; }
static float MMtoINCH (float MM) { return MM/(float)25.4; }

That's exactly how I did it in C++. Tried to use a template, but was not
successful with that.

So does the JIT. (in a release build)
Actually, the .NET JIT can inline function calls even across assembly
borders: If your helper functions are in one assembly, the code that uses
them in another one, the JIT will still be able to inline the calls.

That's great and exactly what I liked to know.

Thanks a lot
Carl