Can you write code directly in CIL ???

[Willy Denoyette [MVP]]

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


"Peter Olcott" <olcott@att.net > wrote in message
news:0izsf.3804 9$QW2.32014@duk eread08...[color=blue]
>
> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
> news:ezbs6U5CGH A.2292@tk2msftn gp13.phx.gbl...[color=green]
>>
>> "Peter Olcott" <olcott@att.net > wrote in message
>> news:g8ksf.3800 5$QW2.12382@duk eread08...[color=darkred]
>>>
>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>> news:%233iWaovC GHA.1032@TK2MSF TNGP11.phx.gbl. ..
>>>>
>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>> news:IEbsf.3796 5$QW2.18916@duk eread08...
>>>>>
>>>>> "Abubakar" <abubakarm@gmai l.com> wrote in message
>>>>> news:%23tiR4prC GHA.3820@TK2MSF TNGP12.phx.gbl. ..
>>>>>> 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.
>>>>> What I had in mind was to write the best possible code in C++ and have
>>>>> the best compiler translate this into assembly language. The best
>>>>> compiler so far seems to be Visual C++ 6.0. Some of the optimizations
>>>>> in 7.0 are disabled, in particular function inlining. Then I was going
>>>>> to hand tweak this generated assembly language. Then as a final step I
>>>>> was going to translate this into CIL.
>>>>>
>>>>>> 2- C# compiler is as clever in generating msil as anyone can possibly
>>>>>> get. I
>>>>> False assumption when one examines the benchmarks of managed C++
>>>>> against managed C#, Managed C++ does significantly better in at least
>>>>> some cases.
>>>>>
>>>>
>>>> Not sure where you get this from? Did you actually run such benchmarks?
>>>> I did run many benchmarks, since v1.0 comparing both C# and Managed C++
>>>> (and C++/CLI) and I never saw a delta (yes, for some C# is the winner)
>>>> larger than 5%, using v2 they are even smaller.
>>>>
>>>>
>>>>
>>>> Willy.
>>>>
>>>>
>>> I found it on the web, some of the differences were several-fold. I
>>> don't know which versions.[/color]
>>
>> Well, they were wrong, for sure, Please post the URL's where you found
>> this kind of nonsense.
>>
>> Willy.[/color]
>
> The difference between VC++ 6.0 and VC++ 7.0 is 50%. The older compiler
> produces much better code.[/color]

Ok, now you are again comparing C++(6.0) to C++ (7.1) while previously you
were comparing C++ to C#.
But also this one is one of your claims you can't (or are not willing?)
prove, anyway if it's true I would suggest you to file a bug report
(http://lab.msdn.microsoft.com).
I can prove that the newest C++ compiler produces equal or better (faster)
code than VC6.

Willy.

[Willy Denoyette [MVP]]

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


"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
message news:u3jMQ$8CGH A.740@TK2MSFTNG P12.phx.gbl...[color=blue]
> ROFL, that's hilarious.
>
> --[/color]


That's right, guess it's time to let this thread die,

Willy.

[Peter Olcott]

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


"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:OysdFI9CGH A.2436@TK2MSFTN GP15.phx.gbl...[color=blue]
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:R5zsf.3804 6$QW2.31800@duk eread08...[color=green]
>>
>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>> news:O%23d6lF5C GHA.1032@TK2MSF TNGP11.phx.gbl. ..[color=darkred]
>>>
>>> "Peter Olcott" <olcott@att.net > wrote in message
>>> news:egksf.3800 7$QW2.25703@duk eread08...
>>>>
>>>> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
>>>> news:MPG.1e1b84 c73d78be9098cbe 4@msnews.micros oft.com...
>>>>> Nicholas Paldino [.NET/C# MVP] <mvp@spam.guard .caspershouse.c om> 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.[/color]
>> Many of the instructions (all the ones in my critical 100 line function)
>> would map one-to-one with assembly language. All of the code in this critical
>> 100 line function is comparisons, branches, and the data movement of single
>> integers.
>>[/color]
>
> No they are not, IL is based on a pure stack based virtual machine execution
> environment, it has not such thing like registers, it has no notion of a real
> memory location, it has no access to the runtime stack.
>
> Just to give you an idea what I'm trying to explain, consider following C#
> method and it's compiler generated IL method.
>
> [C#]
> static void Foo()
> {
> int v = 0;
> int[] ar = new int[5] {0,1,2,3,4};
> for (int i = 0;i != 5 ;i++ )
> {
> v += ar[i];
> }
> }
> //
>
> [compiler generated IL]
> .method private hidebysig static void Foo() cil managed
> {
> // Code size 39 (0x27)
> .maxstack 3
> .locals init (int32 V_0,
> int32[] V_1,
> int32 V_2)
> IL_0000: ldc.i4.0
> IL_0001: stloc.0
> IL_0002: ldc.i4.5
> IL_0003: newarr [mscorlib]System.Int32
> IL_0008: dup
> IL_0009: ldtoken field valuetype
> '<PrivateImplem entationDetails >{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'/'__StaticArrayI nitTypeSize=20'
> '<PrivateImplem entationDetails >{E21D91A1-F27C-4190-94E3-4FB17E12D29A}': :'$$method0x600 0002-1'
> IL_000e: call void
> [mscorlib]System.Runtime. CompilerService s.RuntimeHelper s::InitializeAr ray(class
> [mscorlib]System.Array,
>
> valuetype [mscorlib]System.RuntimeF ieldHandle)
> IL_0013: stloc.1
> IL_0014: ldc.i4.0
> IL_0015: stloc.2
> IL_0016: br.s IL_0022
>
> IL_0018: ldloc.0
> IL_0019: ldloc.1
> IL_001a: ldloc.2
> IL_001b: ldelem.i4
> IL_001c: add
> IL_001d: stloc.0
> IL_001e: ldloc.2
> IL_001f: ldc.i4.1
> IL_0020: add
> IL_0021: stloc.2
> IL_0022: ldloc.2
> IL_0023: ldc.i4.5
> IL_0024: bne.un.s IL_0018
>
> IL_0026: ret
> } // end of method Tester::Foo
>
> and here is what the JIT compiler actually generated from this (!! CPU
> specific !!)
>
> 00cb0098 57 push edi
> 00cb0099 56 push esi
> 00cb009a ba05000000 mov edx,0x5
> 00cb009f b92a981579 mov ecx,0x7915982a
> 00cb00a4 e86b21c5ff call 00902214
> 00cb00a9 8d7808 lea edi,[eax+0x8]
> 00cb00ac be68204000 mov esi,0x402068
> 00cb00b1 f30f7e06 movq xmm0,qword ptr [esi]
> 00cb00b5 660fd607 movq qword ptr [edi],xmm0
> 00cb00b9 f30f7e4608 movq xmm0,qword ptr [esi+0x8]
> 00cb00be 660fd64708 movq qword ptr [edi+0x8],xmm0
> 00cb00c3 83c610 add esi,0x10
> 00cb00c6 83c710 add edi,0x10
> 00cb00c9 a5 movsd
> 00cb00ca 33d2 xor edx,edx
> 00cb00cc 8b4804 mov ecx,[eax+0x4]
> 00cb00cf 3bd1 cmp edx,ecx
> 00cb00d1 730b jnb 00cb00de
> 00cb00d3 83c201 add edx,0x1
> 00cb00d6 83fa05 cmp edx,0x5
> 00cb00d9 75f4 jnz 00cb00cf
> 00cb00db 5e pop esi
> 00cb00dc 5f pop edi
> 00cb00dd c3 ret
> 00cb00de e8fe453e79 call mscorwks!JIT_Rn gChkFail (7a0946e1)
> 00cb00e3 cc int 3
>
> Now try for yourself to build an IL module from the assembly code, and please
> make sure it compiles, is verifiable and runs as fast as the C# generated IL
> above. Or try to tweak the IL so it translates into better (faster) X86 code.[/color]

Show me the source code.
[color=blue]
>[color=green][color=darkred]
>>>
>>>> (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[/color]
>> The JIT probably does all the processor specific optimizations. These don't
>> affect performance nearly as much as the ones that are not processor
>> specific.
>>[/color]
>
> Apart from the processor specific optimizations (which are significant) it
> performs most of the optimizations performed by a C/C++ compiler back-end
> optimizer (both the C++ back-end optimizer and the JIT optimizer has been
> written by the same team), only difference is that it happens at run-time, so
> it is somewhat constrained by time, but this is largely compensated by the
> processor/memory specific optimizatons.
> Check this link and see how managed code compares to unmanaged code at the
> performance level.
> http://www.grimes.demon.co.uk/dotnet/man_unman.htm
>
>
> Willy.
>
>[/color]

http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

The above link is much more telling. There is a 450% difference in performance
between C++ and C# for something as simple as nested loops. Also the difference
between optimized code and code compiler with optimization disabled can be at
least an order of magnitude. If there is a 450% difference in the performance on
something as simple as a nested loop, this shows that there is significant room
for improvement.

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

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

And I apologize, for feeding the trolls as well.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:OFjwIX9CGH A.3976@TK2MSFTN GP10.phx.gbl...[color=blue]
>
> "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote
> in message news:u3jMQ$8CGH A.740@TK2MSFTNG P12.phx.gbl...[color=green]
>> ROFL, that's hilarious.
>>
>> --[/color]
>
>
> That's right, guess it's time to let this thread die,
>
> Willy.
>
>[/color]

[Peter Olcott]

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


"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:usot7P9CGH A.1288@TK2MSFTN GP09.phx.gbl...[color=blue]
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:Iczsf.3804 8$QW2.31968@duk eread08...[color=green]
>>
>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>> news:%23LKMMQ5C GHA.3064@TK2MSF TNGP14.phx.gbl. ..[color=darkred]
>>>
>>> "Peter Olcott" <olcott@att.net > wrote in message
>>> news:5pqsf.3802 2$QW2.34505@duk eread08...
>>>>
>>>> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
>>>> news:MPG.1e1c3e 6d3294046298cbe a@msnews.micros oft.com...
>>>>> Peter Olcott <olcott@att.net > wrote:
>>>>>> I have to screen out the good advice from the advice that does not apply
>>>>>> to my
>>>>>> needs. With 16,000 hours of development in the current project, and the
>>>>>> speed of
>>>>>> a single 100 line function making or breaking the success of this
>>>>>> project, many
>>>>>> of the typical rules would not apply. One poster said that hand tweaked
>>>>>> CIL
>>>>>> doubled the speed, thus confirming my estimations.
>>>>>
>>>>> I said it doubled the speed for one particular case, which was only
>>>>> about four instructions. I wouldn't expect there to be much difference
>>>>> (if any) normally.
>>>>>
>>>>> How much more performance do you need? Have you tried doing the
>>>>> conversion and seeing how it performs *without* tweaking?
>>>>
>>>> The fastest algorithm with the best compilation just barely meets my
>>>> target. This is with MS Visual C++ 6.0. The project requirements call for a
>>>> .NET component. If I could double the speed of this I would be very
>>>> pleased. In any case more recent compilers do not meet my target even with
>>>> the best algorithm, so I must do at least as well as the best compiler.
>>>> This should only be a matter of translating the generated assembly language
>>>> from the best unmanaged code into CIL.
>>>>
>>>>
>>>
>>> If the fasted algo using C++ barely meets your target, you wont do any
>>> better using IL, whether you "translate" X86 assembly to IL or not (which
>>> isn't possible as there is no direct mapping) or not, the IL will be JIT
>>> compiled at run-time, but don't expect it will translate to the same X86
>>> machine code.[/color]
>>
>> My goal is to at least match this fastest time. The project has a design
>> requirement to be implemented as a .NET component. I will probably also hand
>> tweak the assembly language from this fastest compiler VC++ 6.0, and then
>> attempt to match this performance in CIL. From all of this effort I expect to
>> improve the performance of the fastest compiler by at least 50%. Since this
>> critical function will be executed several million times every second, it
>> will be worth the cost of this extra effort at optimization.
>>[/color]
>
> Don't expect you can make it execute (50%) faster than unmanaged C++ code,
> don't expect to hand tweak ASM and translate that to IL and expect the JIT
> compiler will produce the same machine code - IT WONT. Also I'm not clear on
> what you mean by executing several million times per second, in another reply
> you said the function takes 10 msec to finish using VC6 and now you are
> expecting this to execute million times per second.[/color]

I hope to get the managed code to execute just as fast as my best unmanaged
code. I hope to improve the performance of my best unmanaged code by 50% by hand
tweaking the assembly language. The caller that executes this function executes
once in 10 ms. It executes this function several million times. The caller will
be executed once every second.
[color=blue]
>
> Willy.
>
>
>[/color]

[Peter Olcott]

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


"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:%23mkhQW9C GHA.3856@TK2MSF TNGP12.phx.gbl. ..[color=blue]
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:0izsf.3804 9$QW2.32014@duk eread08...[color=green]
>>
>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>> news:ezbs6U5CGH A.2292@tk2msftn gp13.phx.gbl...[color=darkred]
>>>
>>> "Peter Olcott" <olcott@att.net > wrote in message
>>> news:g8ksf.3800 5$QW2.12382@duk eread08...
>>>>
>>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>>> news:%233iWaovC GHA.1032@TK2MSF TNGP11.phx.gbl. ..
>>>>>
>>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>>> news:IEbsf.3796 5$QW2.18916@duk eread08...
>>>>>>
>>>>>> "Abubakar" <abubakarm@gmai l.com> wrote in message
>>>>>> news:%23tiR4prC GHA.3820@TK2MSF TNGP12.phx.gbl. ..
>>>>>>> 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.
>>>>>> What I had in mind was to write the best possible code in C++ and have
>>>>>> the best compiler translate this into assembly language. The best
>>>>>> compiler so far seems to be Visual C++ 6.0. Some of the optimizations in
>>>>>> 7.0 are disabled, in particular function inlining. Then I was going to
>>>>>> hand tweak this generated assembly language. Then as a final step I was
>>>>>> going to translate this into CIL.
>>>>>>
>>>>>>> 2- C# compiler is as clever in generating msil as anyone can possibly
>>>>>>> get. I
>>>>>> False assumption when one examines the benchmarks of managed C++ against
>>>>>> managed C#, Managed C++ does significantly better in at least some cases.
>>>>>>
>>>>>
>>>>> Not sure where you get this from? Did you actually run such benchmarks?
>>>>> I did run many benchmarks, since v1.0 comparing both C# and Managed C++
>>>>> (and C++/CLI) and I never saw a delta (yes, for some C# is the winner)
>>>>> larger than 5%, using v2 they are even smaller.
>>>>>
>>>>>
>>>>>
>>>>> Willy.
>>>>>
>>>>>
>>>> I found it on the web, some of the differences were several-fold. I don't
>>>> know which versions.
>>>
>>> Well, they were wrong, for sure, Please post the URL's where you found this
>>> kind of nonsense.
>>>
>>> Willy.[/color]
>>
>> The difference between VC++ 6.0 and VC++ 7.0 is 50%. The older compiler
>> produces much better code.[/color]
>
> Ok, now you are again comparing C++(6.0) to C++ (7.1) while previously you
> were comparing C++ to C#.
> But also this one is one of your claims you can't (or are not willing?) prove,
> anyway if it's true I would suggest you to file a bug report
> (http://lab.msdn.microsoft.com).
> I can prove that the newest C++ compiler produces equal or better (faster)[/color]
This has already been hashed out in microsoft.publi c.vc.mfc. It seems that the
newer compiler produces slower code. The biggest single reason for this is that
it does not inline function unless __forceinline is specified. There are other
reasons as well. Also the C# compiler seems to produce code that is 450% slower
than the C++ compiler on something as simple as a nested loop. My code uses many
nested loops. see link below:

http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

[color=blue]
> code than VC6.
>
> Willy.
>
>[/color]

[Peter Olcott]

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


"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:OFjwIX9CGH A.3976@TK2MSFTN GP10.phx.gbl...[color=blue]
>
> "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
> message news:u3jMQ$8CGH A.740@TK2MSFTNG P12.phx.gbl...[color=green]
>> ROFL, that's hilarious.
>>
>> --[/color]
>
>
> That's right, guess it's time to let this thread die,
>
> Willy.
>
>[/color]

http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

What about addressing this issue?

[Willy Denoyette [MVP]]

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


"Peter Olcott" <olcott@att.net > wrote in message
news:qoAsf.3805 3$QW2.6355@duke read08...[color=blue]
>
> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
> news:%23mkhQW9C GHA.3856@TK2MSF TNGP12.phx.gbl. ..[color=green]
>>
>> "Peter Olcott" <olcott@att.net > wrote in message
>> news:0izsf.3804 9$QW2.32014@duk eread08...[color=darkred]
>>>
>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>> news:ezbs6U5CGH A.2292@tk2msftn gp13.phx.gbl...
>>>>
>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>> news:g8ksf.3800 5$QW2.12382@duk eread08...
>>>>>
>>>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>>>> news:%233iWaovC GHA.1032@TK2MSF TNGP11.phx.gbl. ..
>>>>>>
>>>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>>>> news:IEbsf.3796 5$QW2.18916@duk eread08...
>>>>>>>
>>>>>>> "Abubakar" <abubakarm@gmai l.com> wrote in message
>>>>>>> news:%23tiR4prC GHA.3820@TK2MSF TNGP12.phx.gbl. ..
>>>>>>>> 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.
>>>>>>> What I had in mind was to write the best possible code in C++ and
>>>>>>> have the best compiler translate this into assembly language. The
>>>>>>> best compiler so far seems to be Visual C++ 6.0. Some of the
>>>>>>> optimizations in 7.0 are disabled, in particular function inlining.
>>>>>>> Then I was going to hand tweak this generated assembly language.
>>>>>>> Then as a final step I was going to translate this into CIL.
>>>>>>>
>>>>>>>> 2- C# compiler is as clever in generating msil as anyone can
>>>>>>>> possibly get. I
>>>>>>> False assumption when one examines the benchmarks of managed C++
>>>>>>> against managed C#, Managed C++ does significantly better in at
>>>>>>> least some cases.
>>>>>>>
>>>>>>
>>>>>> Not sure where you get this from? Did you actually run such
>>>>>> benchmarks?
>>>>>> I did run many benchmarks, since v1.0 comparing both C# and Managed
>>>>>> C++ (and C++/CLI) and I never saw a delta (yes, for some C# is the
>>>>>> winner) larger than 5%, using v2 they are even smaller.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Willy.
>>>>>>
>>>>>>
>>>>> I found it on the web, some of the differences were several-fold. I
>>>>> don't know which versions.
>>>>
>>>> Well, they were wrong, for sure, Please post the URL's where you found
>>>> this kind of nonsense.
>>>>
>>>> Willy.
>>>
>>> The difference between VC++ 6.0 and VC++ 7.0 is 50%. The older compiler
>>> produces much better code.[/color]
>>
>> Ok, now you are again comparing C++(6.0) to C++ (7.1) while previously
>> you were comparing C++ to C#.
>> But also this one is one of your claims you can't (or are not willing?)
>> prove, anyway if it's true I would suggest you to file a bug report
>> (http://lab.msdn.microsoft.com).
>> I can prove that the newest C++ compiler produces equal or better
>> (faster)[/color]
> This has already been hashed out in microsoft.publi c.vc.mfc. It seems that
> the newer compiler produces slower code. The biggest single reason for
> this is that it does not inline function unless __forceinline is
> specified. There are other reasons as well. Also the C# compiler seems to
> produce code that is 450% slower than the C++ compiler on something as
> simple as a nested loop. My code uses many nested loops. see link below:
>
> http://www.tommti-systems.de/go.html...enchmarks.html
>[color=green]
>> code than VC6.
>>
>> Willy.
>>
>>[/color]
>[/color]
Again this is all based on what you read on the internet (NG's etc) not on
personal findings, while my findings are based on real test runs.
Please do us and yourself a favor, translate your 100 line C++ (or whatever)
code to C# and run it and compare the time it takes with a similar run of
your C code.

Willy.

[Peter Olcott]

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


"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:%23mzM%23V $CGHA.2644@TK2M SFTNGP09.phx.gb l...[color=blue]
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:qoAsf.3805 3$QW2.6355@duke read08...[color=green]
>>
>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>> news:%23mkhQW9C GHA.3856@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
>>>
>>> "Peter Olcott" <olcott@att.net > wrote in message
>>> news:0izsf.3804 9$QW2.32014@duk eread08...
>>>>
>>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>>> news:ezbs6U5CGH A.2292@tk2msftn gp13.phx.gbl...
>>>>>
>>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>>> news:g8ksf.3800 5$QW2.12382@duk eread08...
>>>>>>
>>>>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>>>>> news:%233iWaovC GHA.1032@TK2MSF TNGP11.phx.gbl. ..
>>>>>>>
>>>>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>>>>> news:IEbsf.3796 5$QW2.18916@duk eread08...
>>>>>>>>
>>>>>>>> "Abubakar" <abubakarm@gmai l.com> wrote in message
>>>>>>>> news:%23tiR4prC GHA.3820@TK2MSF TNGP12.phx.gbl. ..
>>>>>>>>> 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.
>>>>>>>> What I had in mind was to write the best possible code in C++ and have
>>>>>>>> the best compiler translate this into assembly language. The best
>>>>>>>> compiler so far seems to be Visual C++ 6.0. Some of the optimizations
>>>>>>>> in 7.0 are disabled, in particular function inlining. Then I was going
>>>>>>>> to hand tweak this generated assembly language. Then as a final step I
>>>>>>>> was going to translate this into CIL.
>>>>>>>>
>>>>>>>>> 2- C# compiler is as clever in generating msil as anyone can possibly
>>>>>>>>> get. I
>>>>>>>> False assumption when one examines the benchmarks of managed C++
>>>>>>>> against managed C#, Managed C++ does significantly better in at least
>>>>>>>> some cases.
>>>>>>>>
>>>>>>>
>>>>>>> Not sure where you get this from? Did you actually run such benchmarks?
>>>>>>> I did run many benchmarks, since v1.0 comparing both C# and Managed C++
>>>>>>> (and C++/CLI) and I never saw a delta (yes, for some C# is the winner)
>>>>>>> larger than 5%, using v2 they are even smaller.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Willy.
>>>>>>>
>>>>>>>
>>>>>> I found it on the web, some of the differences were several-fold. I don't
>>>>>> know which versions.
>>>>>
>>>>> Well, they were wrong, for sure, Please post the URL's where you found
>>>>> this kind of nonsense.
>>>>>
>>>>> Willy.
>>>>
>>>> The difference between VC++ 6.0 and VC++ 7.0 is 50%. The older compiler
>>>> produces much better code.
>>>
>>> Ok, now you are again comparing C++(6.0) to C++ (7.1) while previously you
>>> were comparing C++ to C#.
>>> But also this one is one of your claims you can't (or are not willing?)
>>> prove, anyway if it's true I would suggest you to file a bug report
>>> (http://lab.msdn.microsoft.com).
>>> I can prove that the newest C++ compiler produces equal or better (faster)[/color]
>> This has already been hashed out in microsoft.publi c.vc.mfc. It seems that
>> the newer compiler produces slower code. The biggest single reason for this
>> is that it does not inline function unless __forceinline is specified. There
>> are other reasons as well. Also the C# compiler seems to produce code that is
>> 450% slower than the C++ compiler on something as simple as a nested loop. My
>> code uses many nested loops. see link below:
>>
>> http://www.tommti-systems.de/go.html...enchmarks.html
>>[color=darkred]
>>> code than VC6.
>>>
>>> Willy.
>>>
>>>[/color]
>>[/color]
> Again this is all based on what you read on the internet (NG's etc) not on
> personal findings, while my findings are based on real test runs.
> Please do us and yourself a favor, translate your 100 line C++ (or whatever)
> code to C# and run it and compare the time it takes with a similar run of your
> C code.[/color]

That would take more time that I can afford to spend right now. I already did
that with native code 6.0 and 7.0. Even this is too slow. Because benchmarks
indicate that C# can be 450% slower on nested loops (my code is mostly nested
loops), I wanted to look into solving this problem in advance. This is just the
feasibility study stage. I might be forced to digress to unmanaged code.
[color=blue]
>
> Willy.
>
>
>
>[/color]

[Willy Denoyette [MVP]]

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


"Peter Olcott" <olcott@att.net > wrote in message
news:BbAsf.3805 1$QW2.20783@duk eread08...[color=blue]
>
> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
> news:OysdFI9CGH A.2436@TK2MSFTN GP15.phx.gbl...[color=green]
>>
>> "Peter Olcott" <olcott@att.net > wrote in message
>> news:R5zsf.3804 6$QW2.31800@duk eread08...[color=darkred]
>>>
>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>> news:O%23d6lF5C GHA.1032@TK2MSF TNGP11.phx.gbl. ..
>>>>
>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>> news:egksf.3800 7$QW2.25703@duk eread08...
>>>>>
>>>>> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
>>>>> news:MPG.1e1b84 c73d78be9098cbe 4@msnews.micros oft.com...
>>>>>> Nicholas Paldino [.NET/C# MVP] <mvp@spam.guard .caspershouse.c om>
>>>>>> 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.
>>> Many of the instructions (all the ones in my critical 100 line function)
>>> would map one-to-one with assembly language. All of the code in this
>>> critical 100 line function is comparisons, branches, and the data
>>> movement of single integers.
>>>[/color]
>>
>> No they are not, IL is based on a pure stack based virtual machine
>> execution environment, it has not such thing like registers, it has no
>> notion of a real memory location, it has no access to the runtime stack.
>>
>> Just to give you an idea what I'm trying to explain, consider following
>> C# method and it's compiler generated IL method.
>>
>> [C#]
>> static void Foo()
>> {
>> int v = 0;
>> int[] ar = new int[5] {0,1,2,3,4};
>> for (int i = 0;i != 5 ;i++ )
>> {
>> v += ar[i];
>> }
>> }
>> //
>>
>> [compiler generated IL]
>> .method private hidebysig static void Foo() cil managed
>> {
>> // Code size 39 (0x27)
>> .maxstack 3
>> .locals init (int32 V_0,
>> int32[] V_1,
>> int32 V_2)
>> IL_0000: ldc.i4.0
>> IL_0001: stloc.0
>> IL_0002: ldc.i4.5
>> IL_0003: newarr [mscorlib]System.Int32
>> IL_0008: dup
>> IL_0009: ldtoken field valuetype
>> '<PrivateImplem entationDetails >{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'/'__StaticArrayI nitTypeSize=20'
>> '<PrivateImplem entationDetails >{E21D91A1-F27C-4190-94E3-4FB17E12D29A}': :'$$method0x600 0002-1'
>> IL_000e: call void
>> [mscorlib]System.Runtime. CompilerService s.RuntimeHelper s::InitializeAr ray(class
>> [mscorlib]System.Array,
>>
>> valuetype [mscorlib]System.RuntimeF ieldHandle)
>> IL_0013: stloc.1
>> IL_0014: ldc.i4.0
>> IL_0015: stloc.2
>> IL_0016: br.s IL_0022
>>
>> IL_0018: ldloc.0
>> IL_0019: ldloc.1
>> IL_001a: ldloc.2
>> IL_001b: ldelem.i4
>> IL_001c: add
>> IL_001d: stloc.0
>> IL_001e: ldloc.2
>> IL_001f: ldc.i4.1
>> IL_0020: add
>> IL_0021: stloc.2
>> IL_0022: ldloc.2
>> IL_0023: ldc.i4.5
>> IL_0024: bne.un.s IL_0018
>>
>> IL_0026: ret
>> } // end of method Tester::Foo
>>
>> and here is what the JIT compiler actually generated from this (!! CPU
>> specific !!)
>>
>> 00cb0098 57 push edi
>> 00cb0099 56 push esi
>> 00cb009a ba05000000 mov edx,0x5
>> 00cb009f b92a981579 mov ecx,0x7915982a
>> 00cb00a4 e86b21c5ff call 00902214
>> 00cb00a9 8d7808 lea edi,[eax+0x8]
>> 00cb00ac be68204000 mov esi,0x402068
>> 00cb00b1 f30f7e06 movq xmm0,qword ptr [esi]
>> 00cb00b5 660fd607 movq qword ptr [edi],xmm0
>> 00cb00b9 f30f7e4608 movq xmm0,qword ptr [esi+0x8]
>> 00cb00be 660fd64708 movq qword ptr [edi+0x8],xmm0
>> 00cb00c3 83c610 add esi,0x10
>> 00cb00c6 83c710 add edi,0x10
>> 00cb00c9 a5 movsd
>> 00cb00ca 33d2 xor edx,edx
>> 00cb00cc 8b4804 mov ecx,[eax+0x4]
>> 00cb00cf 3bd1 cmp edx,ecx
>> 00cb00d1 730b jnb 00cb00de
>> 00cb00d3 83c201 add edx,0x1
>> 00cb00d6 83fa05 cmp edx,0x5
>> 00cb00d9 75f4 jnz 00cb00cf
>> 00cb00db 5e pop esi
>> 00cb00dc 5f pop edi
>> 00cb00dd c3 ret
>> 00cb00de e8fe453e79 call mscorwks!JIT_Rn gChkFail (7a0946e1)
>> 00cb00e3 cc int 3
>>
>> Now try for yourself to build an IL module from the assembly code, and
>> please make sure it compiles, is verifiable and runs as fast as the C#
>> generated IL above. Or try to tweak the IL so it translates into better
>> (faster) X86 code.[/color]
>
> Show me the source code.
>[/color]

What else do you want?, I gave you the C# source code (the Foo method), it's
corresponding IL and the X86 code produced by the JIT.

[color=blue]
>
> http://www.tommti-systems.de/go.html...enchmarks.html
> The above link is much more telling. There is a 450% difference in
> performance between C++ and C# for something as simple as nested loops.
> Also the difference between optimized code and code compiler with
> optimization disabled can be at least an order of magnitude. If there is a
> 450% difference in the performance on something as simple as a nested
> loop, this shows that there is significant room for improvement.
>[/color]
This very specific (but broken [1] and cluless) benchmark (the loop) is a
sample where the NATIVE C compilers optimizer does a better job than the JIT
compiler/optimizer, but this has nothing to do with the IL code.

[1] This is the correct code which is still ~50% slower than the (corrected)
C++ code ( __int64 x=0; ).

int a = 0, b = 0, c = 0, d= 0, e = 0, f = 0;
long x=0;
startTime = DateTime.Now;
for (a=0; a!=n; a++)
for (b=0; b!=n; b++)
for (c=0; c!=n; c++)
for (d=0; d!=n; d++)
for (e=0; e!=n; e++)
for (f=0; f!=n; f++)
x+=a+b+c+d+e+f;

C# with /o+
Nested Loop elapsed time: 10015 ms - 479232000000

C++ with /O2 /EHsc
Nested Loop elapsed time: 6171 ms 479232000000

Willy.

[Jay B. Harlow [MVP - Outlook]]

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

Peter,
| That would take more time that I can afford to spend right now.
PMFJI: I would think the amount of time you have spent battling your cause
in *this* thread and the other thread, you could have translated the code
itself to C# & timed it. I further suspect you could have come close to
converting the code with ILDASM and hand tweaked the IL itself.

| I already did
| that with native code 6.0 and 7.0. Even this is too slow. Because
benchmarks
| indicate that C# can be 450% slower on nested loops (my code is mostly
nested
| loops), I wanted to look into solving this problem in advance.
I would "solve" this problem by converting the code, do some profiling &
timing on the converted code, and going from there! I would convert to C#
first, if C# proved to be too slow, I would then consider a unsafe C#,
followed by Managed C++ class library, as a last resort I would consider a
hand tweaked IL class library. My concern with hand tweaked IL would be when
the JIT was updated with better optimization algorithms which conflicted
with my hand tweaking, the 32bit JIT behaved differently then the 64bit JIT,
or the JIT behaved differently based on processor...

Remember to time the C# code outside of the VS IDE and use a Release build.
As the C# compiler doesn't optimize Debug builds & JIT compiler won't
optimize any code run under the IDE.

| This is just the
| feasibility study stage.
It would seem to me that if these 100 lines are the "critical" lines to your
process, then taking the time to convert them would be paramount for
determining the feasibility of the project.

IMHO I would not use some generic C# benchmark to decide if the project is a
go or no go. I would prototype (translate) the critical code & time that.

| I might be forced to digress to unmanaged code.
I would only digress to unmanaged code, once C#, unsafe C#, Managed C++ &
hand tweaked IL all proved (*proved*) to have performance issues.


--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


"Peter Olcott" <olcott@att.net > wrote in message
news:NSDsf.3809 2$QW2.25345@duk eread08...
|
| "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
| news:%23mzM%23V $CGHA.2644@TK2M SFTNGP09.phx.gb l...
| >
<<snip>>
| > Again this is all based on what you read on the internet (NG's etc) not
on
| > personal findings, while my findings are based on real test runs.
| > Please do us and yourself a favor, translate your 100 line C++ (or
whatever)
| > code to C# and run it and compare the time it takes with a similar run
of your
| > C code.
|
| That would take more time that I can afford to spend right now. I already
did
| that with native code 6.0 and 7.0. Even this is too slow. Because
benchmarks
| indicate that C# can be 450% slower on nested loops (my code is mostly
nested
| loops), I wanted to look into solving this problem in advance. This is
just the
| feasibility study stage. I might be forced to digress to unmanaged code.
|

[Willy Denoyette [MVP]]

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

>[color=blue]
> That would take more time that I can afford to spend right now. I already
> did that with native code 6.0 and 7.0. Even this is too slow. Because
> benchmarks indicate that C# can be 450% slower on nested loops (my code is
> mostly nested loops), I wanted to look into solving this problem in
> advance. This is just the feasibility study stage. I might be forced to
> digress to unmanaged code.
>[color=green]
>>
>> Willy.[/color][/color]

This is hilarious, you are making a fool of yourself really (or should I
call you a troll?), Translating 100 lines of C code to C# takes 5 minutes of
your time, hand optimizing the IL another 10 minutes, this is far less than
the time you wasted in this thread.

I said in other replies and in the other thread you started that the 450%
benchmarks is clueless and broken, read my reply in the relevant thread for
more details.

Willy.

[Pohihihi]

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

Peter,

Now it is very clear that you are not looking for any solution as you have
argument for every suggestion, and more over your argument is not solution
bound but ego bound. Seems like using this thread you are feeding your ego.
If ego is not the case and if you are so smart why even bother coming on
this newsgroup and replying every single post. If you are worried about your
work so much and millions of $$$ then you should have dropped this long time
back and try to find other ways own your own which we now all think you are
not worried about.

Seems like you are having a ego ride here showing off your 16000 hours of
work and going behind every solution. If you think non is working in your
case they move on dude. Believe me no one will even care what happened to
you after that.




"Peter Olcott" <olcott@att.net > wrote in message
news:wpAsf.3805 4$QW2.18933@duk eread08...[color=blue]
>
> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
> news:OFjwIX9CGH A.3976@TK2MSFTN GP10.phx.gbl...[color=green]
>>
>> "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote
>> in message news:u3jMQ$8CGH A.740@TK2MSFTNG P12.phx.gbl...[color=darkred]
>>> ROFL, that's hilarious.
>>>
>>> --[/color]
>>
>>
>> That's right, guess it's time to let this thread die,
>>
>> Willy.
>>
>>[/color]
>
>
> http://www.tommti-systems.de/go.html...enchmarks.html
> What about addressing this issue?
>[/color]

[Pohihihi]

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

My request to all MVPs. Please stop repling to this thread, it is bulking up
gargabe on my webpage.


"Peter Olcott" <olcott@att.net > wrote in message
news:7t%rf.3788 7$QW2.9998@duke read08...[color=blue]
> Cab you write code directly in the Common Intermediate language? I need to
> optimize a critical real-time function.
>[/color]

[Peter Olcott]

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


"Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
news:edGf46$CGH A.3820@TK2MSFTN GP12.phx.gbl...[color=blue]
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:BbAsf.3805 1$QW2.20783@duk eread08...[color=green]
>>
>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>> news:OysdFI9CGH A.2436@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>>
>>> "Peter Olcott" <olcott@att.net > wrote in message
>>> news:R5zsf.3804 6$QW2.31800@duk eread08...
>>>>
>>>> "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
>>>> news:O%23d6lF5C GHA.1032@TK2MSF TNGP11.phx.gbl. ..
>>>>>
>>>>> "Peter Olcott" <olcott@att.net > wrote in message
>>>>> news:egksf.3800 7$QW2.25703@duk eread08...
>>>>>>
>>>>>> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
>>>>>> news:MPG.1e1b84 c73d78be9098cbe 4@msnews.micros oft.com...
>>>>>>> Nicholas Paldino [.NET/C# MVP] <mvp@spam.guard .caspershouse.c om> 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.
>>>> Many of the instructions (all the ones in my critical 100 line function)
>>>> would map one-to-one with assembly language. All of the code in this
>>>> critical 100 line function is comparisons, branches, and the data movement
>>>> of single integers.
>>>>
>>>
>>> No they are not, IL is based on a pure stack based virtual machine execution
>>> environment, it has not such thing like registers, it has no notion of a
>>> real memory location, it has no access to the runtime stack.
>>>
>>> Just to give you an idea what I'm trying to explain, consider following C#
>>> method and it's compiler generated IL method.
>>>
>>> [C#]
>>> static void Foo()
>>> {
>>> int v = 0;
>>> int[] ar = new int[5] {0,1,2,3,4};
>>> for (int i = 0;i != 5 ;i++ )
>>> {
>>> v += ar[i];
>>> }
>>> }
>>> //
>>>
>>> [compiler generated IL]
>>> .method private hidebysig static void Foo() cil managed
>>> {
>>> // Code size 39 (0x27)
>>> .maxstack 3
>>> .locals init (int32 V_0,
>>> int32[] V_1,
>>> int32 V_2)
>>> IL_0000: ldc.i4.0
>>> IL_0001: stloc.0
>>> IL_0002: ldc.i4.5
>>> IL_0003: newarr [mscorlib]System.Int32
>>> IL_0008: dup
>>> IL_0009: ldtoken field valuetype
>>> '<PrivateImplem entationDetails >{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'/'__StaticArrayI nitTypeSize=20'
>>> '<PrivateImplem entationDetails >{E21D91A1-F27C-4190-94E3-4FB17E12D29A}': :'$$method0x600 0002-1'
>>> IL_000e: call void
>>> [mscorlib]System.Runtime. CompilerService s.RuntimeHelper s::InitializeAr ray(class
>>> [mscorlib]System.Array,
>>>
>>> valuetype [mscorlib]System.RuntimeF ieldHandle)
>>> IL_0013: stloc.1
>>> IL_0014: ldc.i4.0
>>> IL_0015: stloc.2
>>> IL_0016: br.s IL_0022
>>>
>>> IL_0018: ldloc.0
>>> IL_0019: ldloc.1
>>> IL_001a: ldloc.2
>>> IL_001b: ldelem.i4
>>> IL_001c: add
>>> IL_001d: stloc.0
>>> IL_001e: ldloc.2
>>> IL_001f: ldc.i4.1
>>> IL_0020: add
>>> IL_0021: stloc.2
>>> IL_0022: ldloc.2
>>> IL_0023: ldc.i4.5
>>> IL_0024: bne.un.s IL_0018
>>>
>>> IL_0026: ret
>>> } // end of method Tester::Foo
>>>
>>> and here is what the JIT compiler actually generated from this (!! CPU
>>> specific !!)
>>>
>>> 00cb0098 57 push edi
>>> 00cb0099 56 push esi
>>> 00cb009a ba05000000 mov edx,0x5
>>> 00cb009f b92a981579 mov ecx,0x7915982a
>>> 00cb00a4 e86b21c5ff call 00902214
>>> 00cb00a9 8d7808 lea edi,[eax+0x8]
>>> 00cb00ac be68204000 mov esi,0x402068
>>> 00cb00b1 f30f7e06 movq xmm0,qword ptr [esi]
>>> 00cb00b5 660fd607 movq qword ptr [edi],xmm0
>>> 00cb00b9 f30f7e4608 movq xmm0,qword ptr [esi+0x8]
>>> 00cb00be 660fd64708 movq qword ptr [edi+0x8],xmm0
>>> 00cb00c3 83c610 add esi,0x10
>>> 00cb00c6 83c710 add edi,0x10
>>> 00cb00c9 a5 movsd
>>> 00cb00ca 33d2 xor edx,edx
>>> 00cb00cc 8b4804 mov ecx,[eax+0x4]
>>> 00cb00cf 3bd1 cmp edx,ecx
>>> 00cb00d1 730b jnb 00cb00de
>>> 00cb00d3 83c201 add edx,0x1
>>> 00cb00d6 83fa05 cmp edx,0x5
>>> 00cb00d9 75f4 jnz 00cb00cf
>>> 00cb00db 5e pop esi
>>> 00cb00dc 5f pop edi
>>> 00cb00dd c3 ret
>>> 00cb00de e8fe453e79 call mscorwks!JIT_Rn gChkFail (7a0946e1)
>>> 00cb00e3 cc int 3
>>>
>>> Now try for yourself to build an IL module from the assembly code, and
>>> please make sure it compiles, is verifiable and runs as fast as the C#
>>> generated IL above. Or try to tweak the IL so it translates into better
>>> (faster) X86 code.[/color]
>>
>> Show me the source code.
>>[/color]
>
> What else do you want?, I gave you the C# source code (the Foo method), it's
> corresponding IL and the X86 code produced by the JIT.[/color]

I can't decipher the CIL from what you have provided. When I decipher the
assembly language I embed the source in the assembly language.[color=blue]
>
>[color=green]
>>
>> http://www.tommti-systems.de/go.html...enchmarks.html
>> The above link is much more telling. There is a 450% difference in
>> performance between C++ and C# for something as simple as nested loops. Also
>> the difference between optimized code and code compiler with optimization
>> disabled can be at least an order of magnitude. If there is a 450% difference
>> in the performance on something as simple as a nested loop, this shows that
>> there is significant room for improvement.
>>[/color]
> This very specific (but broken [1] and cluless) benchmark (the loop) is a
> sample where the NATIVE C compilers optimizer does a better job than the JIT
> compiler/optimizer, but this has nothing to do with the IL code.[/color]

What is wrong with the benchmark? Did you use these compiler options?

C++ compiler options: /Op /Oy /O2 /Oi /Og /Ot /EHsc /arch:SSE
C# compiler options: /optimize+ /debug- /checked-
[color=blue]
>
> [1] This is the correct code which is still ~50% slower than the (corrected)
> C++ code ( __int64 x=0; ).
>
> int a = 0, b = 0, c = 0, d= 0, e = 0, f = 0;
> long x=0;
> startTime = DateTime.Now;
> for (a=0; a!=n; a++)
> for (b=0; b!=n; b++)
> for (c=0; c!=n; c++)
> for (d=0; d!=n; d++)
> for (e=0; e!=n; e++)
> for (f=0; f!=n; f++)
> x+=a+b+c+d+e+f;
>
> C# with /o+
> Nested Loop elapsed time: 10015 ms - 479232000000
>
> C++ with /O2 /EHsc
> Nested Loop elapsed time: 6171 ms 479232000000[/color]

Did you try managed C++ ?
[color=blue]
>
> Willy.
>
>[/color]