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"
"Nicholas Paldino [.NET/C# MVP]" <
[email protected]>
wrote in message 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]"
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.