Re: Can you write code directly in CIL ???

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.

"Pohihihi" <noemail@xxxxxxxxxxx> wrote in message
news:e6$JcnqCGHA.916@xxxxxxxxxxxxxxxxxxxxxxx
> 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]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:%23YB$FaqCGHA.3820@xxxxxxxxxxxxxxxxxxxxxxx
>> 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]
>> - mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> "Peter Olcott" <olcott@xxxxxxx> wrote in message
>> news:GV3sf.37927$QW2.2410@xxxxxxxxxxxxx
>>>
>>> "Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>>> message news:uvvaatpCGHA.4004@xxxxxxxxxxxxxxxxxxxxxxx
>>>> 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]
>>>> - mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>> "Peter Olcott" <olcott@xxxxxxx> wrote in message
>>>> news:xj2sf.37906$QW2.34052@xxxxxxxxxxxxx
>>>>>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]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
>>>>> in message news:%23RjK3$oCGHA.2040@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> 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]
>>>>>> - mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>
>>>>>> "Peter Olcott" <olcott@xxxxxxx> wrote in message
>>>>>> news:_51sf.37898$QW2.37853@xxxxxxxxxxxxx
>>>>>>>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]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
>>>>>>> in message news:OCvd7unCGHA.2644@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>> 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]
>>>>>>>> - mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>>
>>>>>>>>
>>>>>>>> "Peter Olcott" <olcott@xxxxxxx> wrote in message
>>>>>>>> news:7t%rf.37887$QW2.9998@xxxxxxxxxxxxx
>>>>>>>>> Cab you write code directly in the Common Intermediate language? I
>>>>>>>>> need to optimize a critical real-time function.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: GC.Collect can be trusted?
    ... compact the heap. ... It's not the task of the GC to return the memory to the OS, ... contain any GC heap data (managed objects and other CLR data). ... the memory manager won't ever return the default process heap segments occupied by ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Unfortunate dynamic linking for everything
    ... file, and executes that. ... Yes, disks have been getting bigger, but so has available memory. ... than we will ever see by statically-linking system ...
    (freebsd-current)
  • Re: Assembly memory limit exception -WHY?
    ... Asking for 700-800 MB of continuous memory is a ... CLR DLL's and Windows system DLL's and private user ... The managed heap allocated by the CLR ... >From this 1.2GB the CLR will allocate it's Large Object heap, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: CLR Memory Footprint
    ... The memory footprint can be a big issue with the CLR. ... processes in the usual way that Windows binaries work. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Getting out of memory exception using SealMessage()
    ... The CLR allocates memory from the GC heap, ... handles our TLS encryption between client and server. ... The connections will start dropping. ...
    (microsoft.public.windowsce.platbuilder)