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




"Peter Olcott" <olcott@xxxxxxx> wrote in message
news:egksf.38007$QW2.25703@xxxxxxxxxxxxx
>
> "Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
> news:MPG.1e1b84c73d78be9098cbe4@xxxxxxxxxxxxxxxxxxxxxxx
>> Nicholas Paldino [.NET/C# MVP] <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> I will second that the C++ compiler is better at optimizing IL
>>> output
>>> than the C# compiler. However, as Willy stated, it will not always
>>> produce
>>> verifiable code... I believe the article you were looking for is in
>>> MSDN
>>> magazine.
>>
>> No, the article was definitely someone posting in this group saying, "I
>> want to be able to embed IL in my C# code, here's why." He then
>> produced some better IL (which I suspect *was* verifiable) which the C#
>> compiler "could" have produced from the source C# (i.e. the behaviour
>> was identical).
>>
>> I'm sure this will improve over time, but to be honest it's usually the
>> JIT that has more to do with optimisation IMO.
>
> I wouldn't think that this would be the case for two reasons:
> (1) CIL (for the most part) forms a one-to-one mapping with assembly
> language

Not true, IL is kind of high level language compared to X86 assembly, one
single IL instruction translates to x assembly level instructions where x is
certainly not 1.

> (2) End users are waiting on the JIT to complete, no time to waste doing
> optimizations that could have been done before the softwae shipped.
>

Wrong again, IL is not optimized that much, THE optimizer is the JIT. It's
the JIT that knows at run-time what kind of optmizations can be performed
depending on the characteristics of the HW like CPU type 32bit/64 bit,
number of registers, L1 and L2 cache sizes, MMX/SSE enabled etc.
The CLR is a run-time optimizing execution engine, whether you believe it or
not.


Willy.


.



Relevant Pages

  • Re: Strange behavior at runtime (JIT involved???)
    ... Thanks for your reply Fabian. ... but I wanted to be sure it could be JIT optimisation and not some ... I find it a little disturbing to see that the JIT can sometimes do ... no exception gets thrown since the ...
    (microsoft.public.dotnet.framework.clr)
  • Re: When is "volatile" used instead of "lock" ?
    ... That may be *a* type of optimisation blocking - it doesn't mean it's ... acquire/release semantics is the responsibility of Enter/Exit, MemoryBarrier, ... semantics guarantees do not directly affect what the JIT decides not to ... with the spec without having to do any extra checking. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Strange behavior at runtime (JIT involved???)
    ... but I wanted to be sure it could be JIT optimisation and not some ... > stupid things I was doing! ... I find it a little disturbing to see that the JIT can sometimes do ... is probably no rationale for it, since it seems to be a bug. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Roll your own std::vector ???
    ... Peter Olcott wrote: ... This is from published benchmarks and Microsoft's own recommendations. ... No, I believe the JIT does most of the optimisation, actually. ...
    (microsoft.public.dotnet.languages.csharp)

Loading