Can you write code directly in CIL ???

[Peter Olcott]

Cab you write code directly in the Common Intermediate language? I need to
optimize a critical real-time function.

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

You can write it, but you would have to create a module with IL, and
then compile that into your assembly (or just write the whole assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing you can
do will change that. On top of that, the JIT is what's going to optimize
your code again after you try to, so you might actually end up hurting
yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell you
where you might make some improvements, but dipping down to the IL level is
most likely not going to help you much.

 

[Peter Olcott]

I need the best possible execution speed. I have found that there is a large
difference in the quality of the code generated by the various compilers. I have
16,000 hours of development time in my current project. There is a 100 line
function that must take no longer than 1/10 second to execute. I can just barely
achieve this with MSVC++ 6.0. MSVC++ 7.0 has had some of its optimizations
disabled. I eventually will need to port this to C# .NET. This is a case where
hand tweaked assembly language would be appropriate. I figured that hand tweaked
CIL would be the .NET equivalent of hand tweaked assembly language.

Peter,

You can write it, but you would have to create a module with IL, and then
compile that into your assembly (or just write the whole assembly).

Also, what optimizations do you think you can make? Ultimately, you suffer
from the fact that Windows is not a real-time OS, and nothing you can do will
change that. On top of that, the JIT is what's going to optimize your code
again after you try to, so you might actually end up hurting yourself more
than helping yourself.

If you post the code you are trying to optimize, we can try and tell you
where you might make some improvements, but dipping down to the IL level is
most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Cab you write code directly in the Common Intermediate language? I need to
optimize a critical real-time function.

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to perform
any optimizations it deems necessary, and that might not necessarily be in
line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to
your unmanaged code which uses It Just Works (IJW, seriously). You should
get a managed interface, and the best possible performance (for this
specific situation, not all situations) between managed an unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current project.
There is a 100 line function that must take no longer than 1/10 second to
execute. I can just barely achieve this with MSVC++ 6.0. MSVC++ 7.0 has had
some of its optimizations disabled. I eventually will need to port this to
C# .NET. This is a case where hand tweaked assembly language would be
appropriate. I figured that hand tweaked CIL would be the .NET equivalent
of hand tweaked assembly language.

Peter,

You can write it, but you would have to create a module with IL, and
then compile that into your assembly (or just write the whole assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing you
can do will change that. On top of that, the JIT is what's going to
optimize your code again after you try to, so you might actually end up
hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell
you where you might make some improvements, but dipping down to the IL
level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Cab you write code directly in the Common Intermediate language? I need
to optimize a critical real-time function.

 

[Peter Olcott]

I want to be able to stick with purely managed code, if possible. I just need
this 100 line function to run as fast as if it was hand tweaked assembly
language. I have examined CIL, for the most part it is essentially assembly
language. From what I understand any optimizations take place before the CIL is
generated. When I designed this system (in 1998) I had hand tweaked assembly
language in mind for this crucial function all along.

Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to perform any
optimizations it deems necessary, and that might not necessarily be in line
with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to your
unmanaged code which uses It Just Works (IJW, seriously). You should get a
managed interface, and the best possible performance (for this specific
situation, not all situations) between managed an unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a large
difference in the quality of the code generated by the various compilers. I
have 16,000 hours of development time in my current project. There is a 100
line function that must take no longer than 1/10 second to execute. I can just
barely achieve this with MSVC++ 6.0. MSVC++ 7.0 has had some of its
optimizations disabled. I eventually will need to port this to C# .NET. This
is a case where hand tweaked assembly language would be appropriate. I figured
that hand tweaked CIL would be the .NET equivalent of hand tweaked assembly
language.

Peter,

You can write it, but you would have to create a module with IL, and then
compile that into your assembly (or just write the whole assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing you can
do will change that. On top of that, the JIT is what's going to optimize
your code again after you try to, so you might actually end up hurting
yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell you
where you might make some improvements, but dipping down to the IL level is
most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I need to
optimize a critical real-time function.

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

You don't understand a fundamental concept to .NET and CIL. Yes, there
are compilers that will perform optimization of IL to a certain degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to a
degree.

For example, have you considered, what happens when a Garbage Collection
(GC) occurs while your function is running? If it is in complete managed
code, then there is nothing that you can do about it, and your function will
resume running when the GC is complete. Depending on what is happening on
the machine at the time, combined with what your program is doing, etc, etc,
it is very feasible that your code will take more than 1/10th of a second.

Just because it looks like assembly language, don't assume that CIL is
assembly language. There are some very different things going on under the
hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just
need this 100 line function to run as fast as if it was hand tweaked
assembly language. I have examined CIL, for the most part it is essentially
assembly language. From what I understand any optimizations take place
before the CIL is generated. When I designed this system (in 1998) I had
hand tweaked assembly language in mind for this crucial function all along.

Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to
your unmanaged code which uses It Just Works (IJW, seriously). You
should get a managed interface, and the best possible performance (for
this specific situation, not all situations) between managed an unmanaged
code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current project.
There is a 100 line function that must take no longer than 1/10 second to
execute. I can just barely achieve this with MSVC++ 6.0. MSVC++ 7.0 has
had some of its optimizations disabled. I eventually will need to port
this to C# .NET. This is a case where hand tweaked assembly language
would be appropriate. I figured that hand tweaked CIL would be the .NET
equivalent of hand tweaked assembly language.

in message Peter,

You can write it, but you would have to create a module with IL, and
then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing
you can do will change that. On top of that, the JIT is what's going
to optimize your code again after you try to, so you might actually end
up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell
you where you might make some improvements, but dipping down to the IL
level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Peter Olcott]

Peter,

You don't understand a fundamental concept to .NET and CIL. Yes, there are
compilers that will perform optimization of IL to a certain degree.

However, when the managed code is run, the CLR will take the CIL and then
compile it into native code. At this point in time, it is free to optimize,
or not optimize, or mangle your code in any way you want when making the
transition from CIL to native code.

When you are dealing with assembly language in general, you have complete
control of what is going on, memory allocation, deallocation, execution, etc,
etc. With the CLR, this is taken out of your hands to a degree.

I don't care about these things they are not effecting my performance. What is
effecting my performance are things such as the compiler failing to inline my
functions code, and unnecessary overhead in the translation of a switch
statement. My function will be always executed several million times every
second. It must run concurrently with other applications.

For example, have you considered, what happens when a Garbage Collection
(GC) occurs while your function is running? If it is in complete managed
code, then there is nothing that you can do about it, and your function will
resume running when the GC is complete. Depending on what is happening on the
machine at the time, combined with what your program is doing, etc, etc, it is
very feasible that your code will take more than 1/10th of a second.

My code knows exactly how much memory it needs at load time. It needs all of
this memory the whole time that it executes. It would make no sense to have any
garbage collection of my code's memory in this case. I want my code to be
implemented as a .ET component.

Just because it looks like assembly language, don't assume that CIL is
assembly language. There are some very different things going on under the
hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just need
this 100 line function to run as fast as if it was hand tweaked assembly
language. I have examined CIL, for the most part it is essentially assembly
language. From what I understand any optimizations take place before the CIL
is generated. When I designed this system (in 1998) I had hand tweaked
assembly language in mind for this crucial function all along.

Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to perform
any optimizations it deems necessary, and that might not necessarily be in
line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to your
unmanaged code which uses It Just Works (IJW, seriously). You should get a
managed interface, and the best possible performance (for this specific
situation, not all situations) between managed an unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a large
difference in the quality of the code generated by the various compilers. I
have 16,000 hours of development time in my current project. There is a 100
line function that must take no longer than 1/10 second to execute. I can
just barely achieve this with MSVC++ 6.0. MSVC++ 7.0 has had some of its
optimizations disabled. I eventually will need to port this to C# .NET. This
is a case where hand tweaked assembly language would be appropriate. I
figured that hand tweaked CIL would be the .NET equivalent of hand tweaked
assembly language.

message Peter,

You can write it, but you would have to create a module with IL, and
then compile that into your assembly (or just write the whole assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing you
can do will change that. On top of that, the JIT is what's going to
optimize your code again after you try to, so you might actually end up
hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell
you where you might make some improvements, but dipping down to the IL
level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I need
to optimize a critical real-time function.

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your thread
is going to be pre-empted (in most situations, except if you have the GC
running on a separate thread) and it WILL stop and it WILL affect your
performance when it happens.

Just because your code knows how much memory it needs doesn't mean that
you can pre-empt a GC. If it happens, it's going to happen, and there is
nothing you can do about it. Your 100-line function isn't going to be able
to stop it, and the CLR isn't going to care what your function is doing.

You can't just pretend its not going to happen. It does, and it will,
and you can't stop it. This isn't a choice you have if you are running
managed code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to
provide a good number of services, but you are going to have to pay for
them, and should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged code.
You will have your performance requirements fufilled, and not have to worry
about doing something that will ultimately be self-defeating.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter,

You don't understand a fundamental concept to .NET and CIL. Yes,
there are compilers that will perform optimization of IL to a certain
degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to a
degree.

I don't care about these things they are not effecting my performance.
What is effecting my performance are things such as the compiler failing
to inline my functions code, and unnecessary overhead in the translation
of a switch statement. My function will be always executed several million
times every second. It must run concurrently with other applications.

For example, have you considered, what happens when a Garbage
Collection (GC) occurs while your function is running? If it is in
complete managed code, then there is nothing that you can do about it,
and your function will resume running when the GC is complete. Depending
on what is happening on the machine at the time, combined with what your
program is doing, etc, etc, it is very feasible that your code will take
more than 1/10th of a second.

My code knows exactly how much memory it needs at load time. It needs all
of this memory the whole time that it executes. It would make no sense to
have any garbage collection of my code's memory in this case. I want my
code to be implemented as a .ET component.

Just because it looks like assembly language, don't assume that CIL is
assembly language. There are some very different things going on under
the hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just
need this 100 line function to run as fast as if it was hand tweaked
assembly language. I have examined CIL, for the most part it is
essentially assembly language. From what I understand any optimizations
take place before the CIL is generated. When I designed this system (in
1998) I had hand tweaked assembly language in mind for this crucial
function all along.

in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to
your unmanaged code which uses It Just Works (IJW, seriously). You
should get a managed interface, and the best possible performance (for
this specific situation, not all situations) between managed an
unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current
project. There is a 100 line function that must take no longer than
1/10 second to execute. I can just barely achieve this with MSVC++ 6.0.
MSVC++ 7.0 has had some of its optimizations disabled. I eventually
will need to port this to C# .NET. This is a case where hand tweaked
assembly language would be appropriate. I figured that hand tweaked CIL
would be the .NET equivalent of hand tweaked assembly language.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You can write it, but you would have to create a module with IL,
and then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately,
you suffer from the fact that Windows is not a real-time OS, and
nothing you can do will change that. On top of that, the JIT is
what's going to optimize your code again after you try to, so you
might actually end up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and
tell you where you might make some improvements, but dipping down to
the IL level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Peter Olcott]

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your thread is
going to be pre-empted (in most situations, except if you have the GC running
on a separate thread) and it WILL stop and it WILL affect your performance
when it happens.

I don't care if a GC occurs during the execution of my code. It can't occur
because of my code because my code knows how much memory it needs in advance and
always needs all of this memory the whole time that it is executing. If some
other process interrupts my code, it won't hurt it. My code just can't take more
than 1/10 second to execute, since it needs to execute every second this will
limit its use to 10% of the CPU time. Ultimately I want to limit my thread's
required execution to no more than 10% of the CPU time. This means that this one
function can't take more than 1/10 second to execute.

Just because your code knows how much memory it needs doesn't mean that you
can pre-empt a GC. If it happens, it's going to happen, and there is nothing
you can do about it. Your 100-line function isn't going to be able to stop
it, and the CLR isn't going to care what your function is doing.

You can't just pretend its not going to happen. It does, and it will, and
you can't stop it. This isn't a choice you have if you are running managed
code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to provide
a good number of services, but you are going to have to pay for them, and
should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged code.
You will have your performance requirements fufilled, and not have to worry
about doing something that will ultimately be self-defeating.

I don't think that unmanaged code would make a good .NET component. The current
design requires the function to be implemented as a .NET component.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter,

You don't understand a fundamental concept to .NET and CIL. Yes, there
are compilers that will perform optimization of IL to a certain degree.

However, when the managed code is run, the CLR will take the CIL and then
compile it into native code. At this point in time, it is free to optimize,
or not optimize, or mangle your code in any way you want when making the
transition from CIL to native code.

When you are dealing with assembly language in general, you have complete
control of what is going on, memory allocation, deallocation, execution,
etc, etc. With the CLR, this is taken out of your hands to a degree.

I don't care about these things they are not effecting my performance. What
is effecting my performance are things such as the compiler failing to inline
my functions code, and unnecessary overhead in the translation of a switch
statement. My function will be always executed several million times every
second. It must run concurrently with other applications.

For example, have you considered, what happens when a Garbage Collection
(GC) occurs while your function is running? If it is in complete managed
code, then there is nothing that you can do about it, and your function will
resume running when the GC is complete. Depending on what is happening on
the machine at the time, combined with what your program is doing, etc, etc,
it is very feasible that your code will take more than 1/10th of a second.

My code knows exactly how much memory it needs at load time. It needs all of
this memory the whole time that it executes. It would make no sense to have
any garbage collection of my code's memory in this case. I want my code to be
implemented as a .ET component.

Just because it looks like assembly language, don't assume that CIL is
assembly language. There are some very different things going on under the
hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just
need this 100 line function to run as fast as if it was hand tweaked
assembly language. I have examined CIL, for the most part it is essentially
assembly language. From what I understand any optimizations take place
before the CIL is generated. When I designed this system (in 1998) I had
hand tweaked assembly language in mind for this crucial function all along.

message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to perform
any optimizations it deems necessary, and that might not necessarily be in
line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to
your unmanaged code which uses It Just Works (IJW, seriously). You should
get a managed interface, and the best possible performance (for this
specific situation, not all situations) between managed an unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current project.
There is a 100 line function that must take no longer than 1/10 second to
execute. I can just barely achieve this with MSVC++ 6.0. MSVC++ 7.0 has
had some of its optimizations disabled. I eventually will need to port
this to C# .NET. This is a case where hand tweaked assembly language would
be appropriate. I figured that hand tweaked CIL would be the .NET
equivalent of hand tweaked assembly language.

in message Peter,

You can write it, but you would have to create a module with IL, and
then compile that into your assembly (or just write the whole assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing you
can do will change that. On top of that, the JIT is what's going to
optimize your code again after you try to, so you might actually end up
hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell
you where you might make some improvements, but dipping down to the IL
level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I need
to optimize a critical real-time function.

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

I highly recommend that you read up on how Garbage Collection works
exactly.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your
thread is going to be pre-empted (in most situations, except if you have
the GC running on a separate thread) and it WILL stop and it WILL affect
your performance when it happens.

I don't care if a GC occurs during the execution of my code. It can't
occur because of my code because my code knows how much memory it needs in
advance and always needs all of this memory the whole time that it is
executing. If some other process interrupts my code, it won't hurt it. My
code just can't take more than 1/10 second to execute, since it needs to
execute every second this will limit its use to 10% of the CPU time.
Ultimately I want to limit my thread's required execution to no more than
10% of the CPU time. This means that this one function can't take more
than 1/10 second to execute.

Just because your code knows how much memory it needs doesn't mean
that you can pre-empt a GC. If it happens, it's going to happen, and
there is nothing you can do about it. Your 100-line function isn't going
to be able to stop it, and the CLR isn't going to care what your function
is doing.

You can't just pretend its not going to happen. It does, and it will,
and you can't stop it. This isn't a choice you have if you are running
managed code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to
provide a good number of services, but you are going to have to pay for
them, and should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged
code. You will have your performance requirements fufilled, and not have
to worry about doing something that will ultimately be self-defeating.

I don't think that unmanaged code would make a good .NET component. The
current design requires the function to be implemented as a .NET
component.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

in message Peter,

You don't understand a fundamental concept to .NET and CIL. Yes,
there are compilers that will perform optimization of IL to a certain
degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to
a degree.

I don't care about these things they are not effecting my performance.
What is effecting my performance are things such as the compiler failing
to inline my functions code, and unnecessary overhead in the translation
of a switch statement. My function will be always executed several
million times every second. It must run concurrently with other
applications.


For example, have you considered, what happens when a Garbage
Collection (GC) occurs while your function is running? If it is in
complete managed code, then there is nothing that you can do about it,
and your function will resume running when the GC is complete.
Depending on what is happening on the machine at the time, combined
with what your program is doing, etc, etc, it is very feasible that
your code will take more than 1/10th of a second.
My code knows exactly how much memory it needs at load time. It needs
all of this memory the whole time that it executes. It would make no
sense to have any garbage collection of my code's memory in this case. I
want my code to be implemented as a .ET component.


Just because it looks like assembly language, don't assume that CIL
is assembly language. There are some very different things going on
under the hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I
just need this 100 line function to run as fast as if it was hand
tweaked assembly language. I have examined CIL, for the most part it is
essentially assembly language. From what I understand any optimizations
take place before the CIL is generated. When I designed this system (in
1998) I had hand tweaked assembly language in mind for this crucial
function all along.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper
to your unmanaged code which uses It Just Works (IJW, seriously).
You should get a managed interface, and the best possible performance
(for this specific situation, not all situations) between managed an
unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is
a large difference in the quality of the code generated by the
various compilers. I have 16,000 hours of development time in my
current project. There is a 100 line function that must take no
longer than 1/10 second to execute. I can just barely achieve this
with MSVC++ 6.0. MSVC++ 7.0 has had some of its optimizations
disabled. I eventually will need to port this to C# .NET. This is a
case where hand tweaked assembly language would be appropriate. I
figured that hand tweaked CIL would be the .NET equivalent of hand
tweaked assembly language.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You can write it, but you would have to create a module with IL,
and then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately,
you suffer from the fact that Windows is not a real-time OS, and
nothing you can do will change that. On top of that, the JIT is
what's going to optimize your code again after you try to, so you
might actually end up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and
tell you where you might make some improvements, but dipping down
to the IL level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Pohihihi]

IMHO and according to the following link GC is way better than traditional
memory mgmt. If method is running many million times a second (really??)
then GC will keep it. But as Nicholas said, running of GC is a overhead and
it is in control of CLR. Just because your code knows how much memory it
needs it really do not mean that it will always have that in hand. Again GC
is god here. If you want control of your code and how it behaves than leave
managed environment and go for traditional C++/C/ASM route, or as suggested
Interop.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp
section -->
"Myth: Garbage Colloction Is Always Slower Than Doing It by Hand"

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your thread
is going to be pre-empted (in most situations, except if you have the GC
running on a separate thread) and it WILL stop and it WILL affect your
performance when it happens.

Just because your code knows how much memory it needs doesn't mean that
you can pre-empt a GC. If it happens, it's going to happen, and there is
nothing you can do about it. Your 100-line function isn't going to be
able to stop it, and the CLR isn't going to care what your function is
doing.

You can't just pretend its not going to happen. It does, and it will,
and you can't stop it. This isn't a choice you have if you are running
managed code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to
provide a good number of services, but you are going to have to pay for
them, and should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged
code. You will have your performance requirements fufilled, and not have
to worry about doing something that will ultimately be self-defeating.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter,

You don't understand a fundamental concept to .NET and CIL. Yes,
there are compilers that will perform optimization of IL to a certain
degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to a
degree.

I don't care about these things they are not effecting my performance.
What is effecting my performance are things such as the compiler failing
to inline my functions code, and unnecessary overhead in the translation
of a switch statement. My function will be always executed several
million times every second. It must run concurrently with other
applications.

For example, have you considered, what happens when a Garbage
Collection (GC) occurs while your function is running? If it is in
complete managed code, then there is nothing that you can do about it,
and your function will resume running when the GC is complete.
Depending on what is happening on the machine at the time, combined with
what your program is doing, etc, etc, it is very feasible that your code
will take more than 1/10th of a second.

My code knows exactly how much memory it needs at load time. It needs all
of this memory the whole time that it executes. It would make no sense to
have any garbage collection of my code's memory in this case. I want my
code to be implemented as a .ET component.

Just because it looks like assembly language, don't assume that CIL
is assembly language. There are some very different things going on
under the hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just
need this 100 line function to run as fast as if it was hand tweaked
assembly language. I have examined CIL, for the most part it is
essentially assembly language. From what I understand any optimizations
take place before the CIL is generated. When I designed this system (in
1998) I had hand tweaked assembly language in mind for this crucial
function all along.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper
to your unmanaged code which uses It Just Works (IJW, seriously). You
should get a managed interface, and the best possible performance (for
this specific situation, not all situations) between managed an
unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current
project. There is a 100 line function that must take no longer than
1/10 second to execute. I can just barely achieve this with MSVC++
6.0. MSVC++ 7.0 has had some of its optimizations disabled. I
eventually will need to port this to C# .NET. This is a case where
hand tweaked assembly language would be appropriate. I figured that
hand tweaked CIL would be the .NET equivalent of hand tweaked assembly
language.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You can write it, but you would have to create a module with IL,
and then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately,
you suffer from the fact that Windows is not a real-time OS, and
nothing you can do will change that. On top of that, the JIT is
what's going to optimize your code again after you try to, so you
might actually end up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and
tell you where you might make some improvements, but dipping down to
the IL level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Peter Olcott]

Peter,

I highly recommend that you read up on how Garbage Collection works
exactly.

I already know this. One thing that it can not do is to reclaim memory that is
still in use. I remember reading the algorithm. It is some sort of aging system.
In any case even if my memory needs to be constantly checked to see if it is
still in use, I only need a single monolithic large block. One thing that I do
know about GC, is that it is ONLY invoked when memory runs out, and is needed,
otherwise it is never invoked.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your thread
is going to be pre-empted (in most situations, except if you have the GC
running on a separate thread) and it WILL stop and it WILL affect your
performance when it happens.

I don't care if a GC occurs during the execution of my code. It can't occur
because of my code because my code knows how much memory it needs in advance
and always needs all of this memory the whole time that it is executing. If
some other process interrupts my code, it won't hurt it. My code just can't
take more than 1/10 second to execute, since it needs to execute every second
this will limit its use to 10% of the CPU time. Ultimately I want to limit my
thread's required execution to no more than 10% of the CPU time. This means
that this one function can't take more than 1/10 second to execute.

Just because your code knows how much memory it needs doesn't mean that
you can pre-empt a GC. If it happens, it's going to happen, and there is
nothing you can do about it. Your 100-line function isn't going to be able
to stop it, and the CLR isn't going to care what your function is doing.

You can't just pretend its not going to happen. It does, and it will,
and you can't stop it. This isn't a choice you have if you are running
managed code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to
provide a good number of services, but you are going to have to pay for
them, and should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged code.
You will have your performance requirements fufilled, and not have to worry
about doing something that will ultimately be self-defeating.

I don't think that unmanaged code would make a good .NET component. The
current design requires the function to be implemented as a .NET component.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


message Peter,

You don't understand a fundamental concept to .NET and CIL. Yes, there
are compilers that will perform optimization of IL to a certain degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to a
degree.

I don't care about these things they are not effecting my performance. What
is effecting my performance are things such as the compiler failing to
inline my functions code, and unnecessary overhead in the translation of a
switch statement. My function will be always executed several million times
every second. It must run concurrently with other applications.


For example, have you considered, what happens when a Garbage
Collection (GC) occurs while your function is running? If it is in
complete managed code, then there is nothing that you can do about it, and
your function will resume running when the GC is complete. Depending on
what is happening on the machine at the time, combined with what your
program is doing, etc, etc, it is very feasible that your code will take
more than 1/10th of a second.
My code knows exactly how much memory it needs at load time. It needs all
of this memory the whole time that it executes. It would make no sense to
have any garbage collection of my code's memory in this case. I want my
code to be implemented as a .ET component.


Just because it looks like assembly language, don't assume that CIL is
assembly language. There are some very different things going on under
the hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just
need this 100 line function to run as fast as if it was hand tweaked
assembly language. I have examined CIL, for the most part it is
essentially assembly language. From what I understand any optimizations
take place before the CIL is generated. When I designed this system (in
1998) I had hand tweaked assembly language in mind for this crucial
function all along.

in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to
your unmanaged code which uses It Just Works (IJW, seriously). You
should get a managed interface, and the best possible performance (for
this specific situation, not all situations) between managed an
unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current
project. There is a 100 line function that must take no longer than 1/10
second to execute. I can just barely achieve this with MSVC++ 6.0.
MSVC++ 7.0 has had some of its optimizations disabled. I eventually will
need to port this to C# .NET. This is a case where hand tweaked assembly
language would be appropriate. I figured that hand tweaked CIL would be
the .NET equivalent of hand tweaked assembly language.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You can write it, but you would have to create a module with IL,
and then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately,
you suffer from the fact that Windows is not a real-time OS, and
nothing you can do will change that. On top of that, the JIT is
what's going to optimize your code again after you try to, so you
might actually end up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and
tell you where you might make some improvements, but dipping down to
the IL level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Pohihihi]

When GC is called it really do not matter if your process is taking 10% or
1% of memory or is taking 1/10 of second. When it starts it starts and you
have no control over it. This is bottom line. Now regarding achieving 1/10
of second for the thread, pre-empting is something you can't control, more
over until v1.1 there is no way to priorities your thread which leaves it to
the murcy of CLR. I am not sure if you can do that in v2.0, you might have
to check that.

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your
thread is going to be pre-empted (in most situations, except if you have
the GC running on a separate thread) and it WILL stop and it WILL affect
your performance when it happens.

I don't care if a GC occurs during the execution of my code. It can't
occur because of my code because my code knows how much memory it needs in
advance and always needs all of this memory the whole time that it is
executing. If some other process interrupts my code, it won't hurt it. My
code just can't take more than 1/10 second to execute, since it needs to
execute every second this will limit its use to 10% of the CPU time.
Ultimately I want to limit my thread's required execution to no more than
10% of the CPU time. This means that this one function can't take more
than 1/10 second to execute.

Just because your code knows how much memory it needs doesn't mean
that you can pre-empt a GC. If it happens, it's going to happen, and
there is nothing you can do about it. Your 100-line function isn't going
to be able to stop it, and the CLR isn't going to care what your function
is doing.

You can't just pretend its not going to happen. It does, and it will,
and you can't stop it. This isn't a choice you have if you are running
managed code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to
provide a good number of services, but you are going to have to pay for
them, and should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged
code. You will have your performance requirements fufilled, and not have
to worry about doing something that will ultimately be self-defeating.

I don't think that unmanaged code would make a good .NET component. The
current design requires the function to be implemented as a .NET
component.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

in message Peter,

You don't understand a fundamental concept to .NET and CIL. Yes,
there are compilers that will perform optimization of IL to a certain
degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to
a degree.

I don't care about these things they are not effecting my performance.
What is effecting my performance are things such as the compiler failing
to inline my functions code, and unnecessary overhead in the translation
of a switch statement. My function will be always executed several
million times every second. It must run concurrently with other
applications.


For example, have you considered, what happens when a Garbage
Collection (GC) occurs while your function is running? If it is in
complete managed code, then there is nothing that you can do about it,
and your function will resume running when the GC is complete.
Depending on what is happening on the machine at the time, combined
with what your program is doing, etc, etc, it is very feasible that
your code will take more than 1/10th of a second.
My code knows exactly how much memory it needs at load time. It needs
all of this memory the whole time that it executes. It would make no
sense to have any garbage collection of my code's memory in this case. I
want my code to be implemented as a .ET component.


Just because it looks like assembly language, don't assume that CIL
is assembly language. There are some very different things going on
under the hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I
just need this 100 line function to run as fast as if it was hand
tweaked assembly language. I have examined CIL, for the most part it is
essentially assembly language. From what I understand any optimizations
take place before the CIL is generated. When I designed this system (in
1998) I had hand tweaked assembly language in mind for this crucial
function all along.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper
to your unmanaged code which uses It Just Works (IJW, seriously).
You should get a managed interface, and the best possible performance
(for this specific situation, not all situations) between managed an
unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is
a large difference in the quality of the code generated by the
various compilers. I have 16,000 hours of development time in my
current project. There is a 100 line function that must take no
longer than 1/10 second to execute. I can just barely achieve this
with MSVC++ 6.0. MSVC++ 7.0 has had some of its optimizations
disabled. I eventually will need to port this to C# .NET. This is a
case where hand tweaked assembly language would be appropriate. I
figured that hand tweaked CIL would be the .NET equivalent of hand
tweaked assembly language.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You can write it, but you would have to create a module with IL,
and then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately,
you suffer from the fact that Windows is not a real-time OS, and
nothing you can do will change that. On top of that, the JIT is
what's going to optimize your code again after you try to, so you
might actually end up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and
tell you where you might make some improvements, but dipping down
to the IL level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Peter Olcott]

Not only will it run several million times every second, but, it will constantly
access all of its memory. Can I write a .NET component using purely unmanaged
code? That would seem to be a contradiction in terms.

IMHO and according to the following link GC is way better than traditional
memory mgmt. If method is running many million times a second (really??) then
GC will keep it. But as Nicholas said, running of GC is a overhead and it is
in control of CLR. Just because your code knows how much memory it needs it
really do not mean that it will always have that in hand. Again GC is god
here. If you want control of your code and how it behaves than leave managed
environment and go for traditional C++/C/ASM route, or as suggested Interop.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp
section -->
"Myth: Garbage Colloction Is Always Slower Than Doing It by Hand"

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your thread is
going to be pre-empted (in most situations, except if you have the GC running
on a separate thread) and it WILL stop and it WILL affect your performance
when it happens.

Just because your code knows how much memory it needs doesn't mean that
you can pre-empt a GC. If it happens, it's going to happen, and there is
nothing you can do about it. Your 100-line function isn't going to be able
to stop it, and the CLR isn't going to care what your function is doing.

You can't just pretend its not going to happen. It does, and it will, and
you can't stop it. This isn't a choice you have if you are running managed
code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to provide
a good number of services, but you are going to have to pay for them, and
should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged code.
You will have your performance requirements fufilled, and not have to worry
about doing something that will ultimately be self-defeating.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message Peter,

You don't understand a fundamental concept to .NET and CIL. Yes, there
are compilers that will perform optimization of IL to a certain degree.

However, when the managed code is run, the CLR will take the CIL and
then compile it into native code. At this point in time, it is free to
optimize, or not optimize, or mangle your code in any way you want when
making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to a
degree.

I don't care about these things they are not effecting my performance. What
is effecting my performance are things such as the compiler failing to
inline my functions code, and unnecessary overhead in the translation of a
switch statement. My function will be always executed several million times
every second. It must run concurrently with other applications.


For example, have you considered, what happens when a Garbage Collection
(GC) occurs while your function is running? If it is in complete managed
code, then there is nothing that you can do about it, and your function
will resume running when the GC is complete. Depending on what is happening
on the machine at the time, combined with what your program is doing, etc,
etc, it is very feasible that your code will take more than 1/10th of a
second.
My code knows exactly how much memory it needs at load time. It needs all of
this memory the whole time that it executes. It would make no sense to have
any garbage collection of my code's memory in this case. I want my code to
be implemented as a .ET component.


Just because it looks like assembly language, don't assume that CIL is
assembly language. There are some very different things going on under the
hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I just
need this 100 line function to run as fast as if it was hand tweaked
assembly language. I have examined CIL, for the most part it is essentially
assembly language. From what I understand any optimizations take place
before the CIL is generated. When I designed this system (in 1998) I had
hand tweaked assembly language in mind for this crucial function all along.

in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper to
your unmanaged code which uses It Just Works (IJW, seriously). You
should get a managed interface, and the best possible performance (for
this specific situation, not all situations) between managed an unmanaged
code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is a
large difference in the quality of the code generated by the various
compilers. I have 16,000 hours of development time in my current project.
There is a 100 line function that must take no longer than 1/10 second to
execute. I can just barely achieve this with MSVC++ 6.0. MSVC++ 7.0 has
had some of its optimizations disabled. I eventually will need to port
this to C# .NET. This is a case where hand tweaked assembly language
would be appropriate. I figured that hand tweaked CIL would be the .NET
equivalent of hand tweaked assembly language.

in message Peter,

You can write it, but you would have to create a module with IL, and
then compile that into your assembly (or just write the whole
assembly).

Also, what optimizations do you think you can make? Ultimately, you
suffer from the fact that Windows is not a real-time OS, and nothing
you can do will change that. On top of that, the JIT is what's going
to optimize your code again after you try to, so you might actually end
up hurting yourself more than helping yourself.

If you post the code you are trying to optimize, we can try and tell
you where you might make some improvements, but dipping down to the IL
level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language? I
need to optimize a critical real-time function.

 

[Pohihihi]

Your benchmarking on perfomance is bit off posting to posting. If it is 100
lines of code in asm then surely it will be performing better but how many
lines of .NET conversion of it. But if you are saying 100 lines of code in
..Net then I wonder how many lines of instruction code your .net code is
creating to execute it several million times in a given second or 10 of a
second or which ever benchmark is correct.

Well anyways, seems like you know the ground you are playing on so for the
answer for your original question, yes you can write the whole program in
IL. I will be interested in knowing how you optimized it.

Not only will it run several million times every second, but, it will
constantly access all of its memory. Can I write a .NET component using
purely unmanaged code? That would seem to be a contradiction in terms.

IMHO and according to the following link GC is way better than
traditional memory mgmt. If method is running many million times a second
(really??) then GC will keep it. But as Nicholas said, running of GC is a
overhead and it is in control of CLR. Just because your code knows how
much memory it needs it really do not mean that it will always have that
in hand. Again GC is god here. If you want control of your code and how
it behaves than leave managed environment and go for traditional
C++/C/ASM route, or as suggested Interop.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp
section -->
"Myth: Garbage Colloction Is Always Slower Than Doing It by Hand"

Peter,

You are missing the point completely. If you implement your code as
managed code, even in IL, you can't stop a GC no matter what. Your
thread is going to be pre-empted (in most situations, except if you have
the GC running on a separate thread) and it WILL stop and it WILL affect
your performance when it happens.

Just because your code knows how much memory it needs doesn't mean
that you can pre-empt a GC. If it happens, it's going to happen, and
there is nothing you can do about it. Your 100-line function isn't
going to be able to stop it, and the CLR isn't going to care what your
function is doing.

You can't just pretend its not going to happen. It does, and it
will, and you can't stop it. This isn't a choice you have if you are
running managed code, whether you do it in IL or not.

This is what it means to have ^managed^ code. The CLR is going to
provide a good number of services, but you are going to have to pay for
them, and should be aware of how they impact your code.

This is why I recommended that you use interop with your unmanaged
code. You will have your performance requirements fufilled, and not have
to worry about doing something that will ultimately be self-defeating.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You don't understand a fundamental concept to .NET and CIL. Yes,
there are compilers that will perform optimization of IL to a certain
degree.

However, when the managed code is run, the CLR will take the CIL
and then compile it into native code. At this point in time, it is
free to optimize, or not optimize, or mangle your code in any way you
want when making the transition from CIL to native code.

When you are dealing with assembly language in general, you have
complete control of what is going on, memory allocation, deallocation,
execution, etc, etc. With the CLR, this is taken out of your hands to
a degree.

I don't care about these things they are not effecting my performance.
What is effecting my performance are things such as the compiler
failing to inline my functions code, and unnecessary overhead in the
translation of a switch statement. My function will be always executed
several million times every second. It must run concurrently with other
applications.


For example, have you considered, what happens when a Garbage
Collection (GC) occurs while your function is running? If it is in
complete managed code, then there is nothing that you can do about it,
and your function will resume running when the GC is complete.
Depending on what is happening on the machine at the time, combined
with what your program is doing, etc, etc, it is very feasible that
your code will take more than 1/10th of a second.
My code knows exactly how much memory it needs at load time. It needs
all of this memory the whole time that it executes. It would make no
sense to have any garbage collection of my code's memory in this case.
I want my code to be implemented as a .ET component.


Just because it looks like assembly language, don't assume that CIL
is assembly language. There are some very different things going on
under the hood.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I want to be able to stick with purely managed code, if possible. I
just need this 100 line function to run as fast as if it was hand
tweaked assembly language. I have examined CIL, for the most part it
is essentially assembly language. From what I understand any
optimizations take place before the CIL is generated. When I designed
this system (in 1998) I had hand tweaked assembly language in mind for
this crucial function all along.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

Not at all. When the CLR gets a hold of the JIT, it is free to
perform any optimizations it deems necessary, and that might not
necessarily be in line with what you are expecting.

My recommendation would be to use Managed C++ to create a wrapper
to your unmanaged code which uses It Just Works (IJW, seriously).
You should get a managed interface, and the best possible
performance (for this specific situation, not all situations)
between managed an unmanaged code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I need the best possible execution speed. I have found that there is
a large difference in the quality of the code generated by the
various compilers. I have 16,000 hours of development time in my
current project. There is a 100 line function that must take no
longer than 1/10 second to execute. I can just barely achieve this
with MSVC++ 6.0. MSVC++ 7.0 has had some of its optimizations
disabled. I eventually will need to port this to C# .NET. This is a
case where hand tweaked assembly language would be appropriate. I
figured that hand tweaked CIL would be the .NET equivalent of hand
tweaked assembly language.

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message Peter,

You can write it, but you would have to create a module with
IL, and then compile that into your assembly (or just write the
whole assembly).

Also, what optimizations do you think you can make?
Ultimately, you suffer from the fact that Windows is not a
real-time OS, and nothing you can do will change that. On top of
that, the JIT is what's going to optimize your code again after
you try to, so you might actually end up hurting yourself more
than helping yourself.

If you post the code you are trying to optimize, we can try and
tell you where you might make some improvements, but dipping down
to the IL level is most likely not going to help you much.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Cab you write code directly in the Common Intermediate language?
I need to optimize a critical real-time function.

 

[Abubakar]

Hi,

Cab you write code directly in the Common Intermediate language? I need to
optimize a critical real-time function.

ofcourse you can, by now you may even have done it. Just write few *.il
lines and pass it to ilasm (that comes with the sdk) and you'll get the
managed binary.

although Nicholas tried explaning. I have just few things to add.

1- If you look at the shared source implementation of .net, ie, SSCLI (aka
ROTOR), you wont find a single *.il file that microsoft devs had to write in
order to acheive better performance. The max they did to write fast code as
a .net code was to write the unsafe C# code (which uses pointers). Beyond
that, places that needed to get maximum efficiency like JIT, they used a
pure c++ code and in very few places, x86 assembly code was used. I think if
those developers could acheive anything significant by writing il directly,
they would have done that.
2- C# compiler is as clever in generating msil as anyone can possibly get. I
would recommend that start analysing the output of the C# compiler by
looking at the generated msil using ildasm (or your fav il disassembler) and
really see if you could have written a better msil.
3- I heard somebody mention that there are indeed some msil instructions
that C# compiler doesnt use. If by using those instructions more fast code
could be produced than maybe you have a chance. But I would not count on
this one.

regards,

Ab.
http://joehacker.blogspot.com

 

[Jon Skeet [C# MVP]]

2- C# compiler is as clever in generating msil as anyone can possibly get. I
would recommend that start analysing the output of the C# compiler by
looking at the generated msil using ildasm (or your fav il disassembler) and
really see if you could have written a better msil.

This is entirely untrue. I believe the MC++ compiler generates better
IL than the C# compiler, for a start. For a second thing, I remember a
post a long time ago by someone who wanted to be able to embed IL in
his C#. We asked him whether he was sure it would produce a performance
improvement, and he produced his hand-tweaked IL and the IL generated
by the C# compiler - and the hand-tweaked IL was about twice as fast.

Don't misunderstand me - I'm not recommending hand-tweaking IL - I'm
just saying that the C# compiler does *not* generate "perfect" IL.

 

[Abubakar]

Don't misunderstand me - I'm not recommending hand-tweaking IL - I'm

just saying that the C# compiler does *not* generate "perfect" IL.

I hope that the new C#(2.0) compiler is better at this.

Thanks.

Ab.

 

[Jon Skeet [C# MVP]]

I hope that the new C#(2.0) compiler is better at this.

It may well be better, although I don't know that it is. I doubt that
it's absolutely perfect though - that you could never, ever improve on
the code it generates.

It's a shame I can't find the newsgroup thread I'm thinking about - I
could give it a try with C# 2.0...

 

[Abubakar]

It's a shame I can't find the newsgroup thread I'm thinking about - I

could give it a try with C# 2.0...

btw what search engine are you using? It maybe socking for some people but
few days back I was searching some thread and for the same keywords google
could not find the post but msn search (search.msn.com) did

Ab.