Can you write code directly in CIL ???

[Willy Denoyette [MVP]]

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)
code than VC6.

Willy.

 

[Willy Denoyette [MVP]]

ROFL, that's hilarious.

--

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

Willy.

 

[Peter Olcott]

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;
}
}
//

[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
'<PrivateImplementationDetails>{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'/'__StaticArrayInitTypeSize=20'
'<PrivateImplementationDetails>{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'::'$$method0x6000002-1'
IL_000e: call void
[mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class
[mscorlib]System.Array,

valuetype [mscorlib]System.RuntimeFieldHandle)
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_RngChkFail (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.

Show me the source code.

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.

http://www.tommti-systems.de/go.htm...ain-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]]

And I apologize, for feeding the trolls as well.

 

[Peter Olcott]

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.

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.

 

[Peter Olcott]

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)

This has already been hashed out in microsoft.public.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.htm...ain-Dateien/reviews/languages/benchmarks.html

 

[Peter Olcott]

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

Willy.

http://www.tommti-systems.de/go.htm...ain-Dateien/reviews/languages/benchmarks.html
What about addressing this issue?

 

[Willy Denoyette [MVP]]

This has already been hashed out in microsoft.public.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.htm...ain-Dateien/reviews/languages/benchmarks.html

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]

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]]

Nicholas Paldino [.NET/C# MVP] <[email protected]>
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;
}
}
//

[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
'<PrivateImplementationDetails>{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'/'__StaticArrayInitTypeSize=20'
'<PrivateImplementationDetails>{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'::'$$method0x6000002-1'
IL_000e: call void
[mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class
[mscorlib]System.Array,

valuetype [mscorlib]System.RuntimeFieldHandle)
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_RngChkFail (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.

Show me the source code.

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.

http://www.tommti-systems.de/go.htm...ain-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.

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]]

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


|
| | >
<<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]]

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.

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]

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.

 

[Pohihihi]

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

 

[Peter Olcott]

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;
}
}
//

[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
'<PrivateImplementationDetails>{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'/'__StaticArrayInitTypeSize=20'
'<PrivateImplementationDetails>{E21D91A1-F27C-4190-94E3-4FB17E12D29A}'::'$$method0x6000002-1'
IL_000e: call void
[mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class
[mscorlib]System.Array,

valuetype [mscorlib]System.RuntimeFieldHandle)
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_RngChkFail (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.

Show me the source code.

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.

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.

http://www.tommti-systems.de/go.htm...ain-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.

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.

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-

[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

Did you try managed C++ ?

 

[Peter Olcott]

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.

The project has already been determined to be feasible. This stage is assessing
whether or not converting it to C# .NET is feasible.

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.

There is a learning curve involved in this that might hurt my chances of
ultimate success. This is the point in time where I decide to proceed down the
C# .NET path or remain on the native code C++ path. I can't afford to spend the
time learning C# and .NET, and then converting even this part of the project to
later find out that C# and .NET were not the way to go. At this stage I am
determining which of these two paths to take.

| 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


|
| | >
<<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.
|

 

[Peter Olcott]

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.

First I have to learn C# and .NET.

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

Yet you never bothered to say what is clueless and broken about it, thus it is
merely an unsupported assertion.

 

[Peter Olcott]

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.

The purpose of this thread was to determine the feasibility of converting my
project to .NET. That answer has not yet been sufficiently derived. My project
is feasible if I limit the options to native code. Whether or not .NET is
capable of native code performance should be a topic of great interest. This
issue has not been fully resolved. I was shocked and disappointed to see that
even the native code performance of MSVC++ was degraded as it was updated from
6.0 to 7.0. This is a problem that I didn't think could occur. There is another
screwy quirk that 2002 refuses to compile a C++ project converted from 6.0 if
that project is located on a network. It ends with internal compiler error
C1001. MS tech support said that this is an error that they won't bother to fix,
or provide support for.

 

[mablejune]

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

Without a doubt, this is the longest thread I have ever seen. It
looks like a lightening bolt in the reader when the replies are
exposed ;o)

 

[mablejune]

{snip}

I have
16,000 hours of development time in my current project.

Oh, Peter....

Since you didn't say "our" project I assume you spent 2000 8 hour
man-days (5.4794520547945205479452054794521 years) without taking a
day off on your project.

Would you mind telling us how many lines of code are in your 16,000
hour project? I'm sure one, such as yourself, who pays great
attention to detail will know the exact count.

I'd like to calculate how long it took you to write that 100 line
function.

I think you're full of BS, troll...

mable