Why is C# 450% slower than C++ on nested loops ??

[Peter Olcott]

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a nested
loop. Is this because .NET is inherently slower or does the C# compiler merely
produce code that is not as well optimized as the C++ compiler?

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

For those that would like more information on why this question is being
asked, see the following link:

http://groups.google.com/group/micro...cc573d00467eec

A good amount of the reply, and the OPs misunderstanding of the nature
of .NET and the CLR is in this thread.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

[Peter Olcott]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:em*****************@tk2msftngp13.phx.gbl...

For those that would like more information on why this question is being
asked, see the following link:

http://groups.google.com/group/micro...cc573d00467eec
So then it seems that your contention (based on the message that the link points
to) is that the whole difference is because of poorer code generation by the C#
compiler.

A good amount of the reply, and the OPs misunderstanding of the nature of
.NET and the CLR is in this thread.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

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

Not at all. I never said .NET was slower than C++ code, nor did I say
that if it was slower, it was because C# compiles in a more inefficent
manner.

The thing you don't get is that IL runs through the CLR, which
transforms it into native code that is then run. End of story. Until you
accept that, none of the benchmarks or claims that you make will be valid.
Especially if you don't post the code in question which you claim is:

- 100 lines
- patent pending
- part of a system which is worth millions of dollars

You seem to have a history of long, intentionally confrontational posts
and we don't need another one.

Now I'm really done feeding the troll.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Peter Olcott" <ol****@att.net> wrote in message
news:BzBsf.38064$QW2.15791@dukeread08...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:em*****************@tk2msftngp13.phx.gbl...

For those that would like more information on why this question is
being asked, see the following link:

http://groups.google.com/group/micro...cc573d00467eec

So then it seems that your contention (based on the message that the link
points to) is that the whole difference is because of poorer code
generation by the C# compiler.

A good amount of the reply, and the OPs misunderstanding of the nature
of .NET and the CLR is in this thread.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

[Michael Bray]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
news:eF*************@TK2MSFTNGP15.phx.gbl:

- part of a system which is worth millions of dollars

The part I don't get is that the money-men are going to let a little thing
like "must be written in .NET" get between them and their millions. :)

-mdb

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

Michael,

I guess that's why I don't have millions of dollars already! =)
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael Bray" <mbray@makeDIntoDot_ctiusaDcom> wrote in message
news:Xn****************************@207.46.248.16. ..

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in
news:eF*************@TK2MSFTNGP15.phx.gbl:

- part of a system which is worth millions of dollars

The part I don't get is that the money-men are going to let a little thing
like "must be written in .NET" get between them and their millions. :)

-mdb

[Joanna Carter [TeamB]]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> a écrit
dans le message de news: eF***************@TK2MSFTNGP15.phx.gbl...

| Now I'm really done feeding the troll.

Heh, you ought to come and see what we have had to deal with in our non-tech
group :-))

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Peter Olcott]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eF***************@TK2MSFTNGP15.phx.gbl...

Not at all. I never said .NET was slower than C++ code, nor did I say that
if it was slower, it was because C# compiles in a more inefficent manner.
If you look at what I said, you will see that you just agreed with what I said.

The thing you don't get is that IL runs through the CLR, which transforms
it into native code that is then run. End of story. Until you accept that,
none of the benchmarks or claims that you make will be valid. Especially if
you don't post the code in question which you claim is:

- 100 lines
- patent pending
- part of a system which is worth millions of dollars

You seem to have a history of long, intentionally confrontational posts and
we don't need another one.

Now I'm really done feeding the troll.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Peter Olcott" <ol****@att.net> wrote in message
news:BzBsf.38064$QW2.15791@dukeread08...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:em*****************@tk2msftngp13.phx.gbl...

For those that would like more information on why this question is being
asked, see the following link:

http://groups.google.com/group/micro...cc573d00467eec

So then it seems that your contention (based on the message that the link
points to) is that the whole difference is because of poorer code generation
by the C# compiler.

A good amount of the reply, and the OPs misunderstanding of the nature of
.NET and the CLR is in this thread.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

[Peter Olcott]

"Michael Bray" <mbray@makeDIntoDot_ctiusaDcom> wrote in message
news:Xn****************************@207.46.248.16. ..

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
news:eF*************@TK2MSFTNGP15.phx.gbl:

- part of a system which is worth millions of dollars

The part I don't get is that the money-men are going to let a little thing
like "must be written in .NET" get between them and their millions. :)

If it can be written in .NET without any loss of speed it might have greater
value. It would seem to me that non managed code will be eventually phased out,
at least on the MS Windows platform.

-mdb

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

Joanna,

Which one, alt.inventors? That's a non-tech group I saw...
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2********************@TK2MSFTNGP12.phx.gbl.. .

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> a écrit
dans le message de news: eF***************@TK2MSFTNGP15.phx.gbl...

| Now I'm really done feeding the troll.

Heh, you ought to come and see what we have had to deal with in our
non-tech
group :-))

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Peter Olcott]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uo****************@TK2MSFTNGP11.phx.gbl...

Michael,

I guess that's why I don't have millions of dollars already! =) I have about 30,000 hours invested in various inventions since 1987. This
invention was the first one to receive very strong patent protection. It would
seem that I did a good job on writing the patent for three reasons:
(1) It scored very high on all of the http://www.patentratings.com/ measures.
(2) It passed scrutiny by the USPTO the first time without reservation.
(3) The six independent claims provide very broad protection. The functional
results that I achieve can not be achieved without directly reading on these
claims.

The functional results that I achieve make possible great simplification to the
ease of use of graphical user interface based operating systems.
My original patent attorney graduated number one in his law school class of 144
graduates.


--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael Bray" <mbray@makeDIntoDot_ctiusaDcom> wrote in message
news:Xn****************************@207.46.248.16. ..

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
news:eF*************@TK2MSFTNGP15.phx.gbl:

- part of a system which is worth millions of dollars

The part I don't get is that the money-men are going to let a little thing
like "must be written in .NET" get between them and their millions. :)

-mdb

[Marcus Cuda]

OK, momma said not to feed the trolls, but I was curious.

This is a silly benchmark, since it is basically calculating n^6. The C++ and C++/CLI compiler figures this out, but the
C# compiler doesn't. Interestingly, neither does the JITer. Everything was compiled with optimizations on under VS2005.

The loop:
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++;

C++ assembly:
00401025 mov ecx,eax
00401027 imul ecx,eax
0040102A imul ecx,eax
0040102D imul ecx,eax
00401030 imul ecx,eax
00401033 imul ecx,eax
C++/CLI IL:
L_000f: ldloc.0
L_0010: dup
L_0011: mul
L_0012: ldloc.0
L_0013: mul
L_0014: ldloc.0
L_0015: mul
L_0016: ldloc.0
L_0017: mul
L_0018: ldloc.0
L_0019: mul

C++/CLI JITed:
00000046 mov edi,esi
00000048 mov eax,esi
0000004a mov edx,esi
0000004c mov ecx,esi
0000004e mov ebx,esi
00000050 imul ebx,esi
00000053 imul ecx,ebx
00000056 imul edx,ecx
00000059 imul eax,edx
0000005c imul edi,eax
C# IL:
L_0000: ldc.i4.0
L_0001: stloc.s num7
L_0003: ldc.i4.0
L_0004: stloc.0
L_0005: br.s L_0055
L_0007: ldc.i4.0
L_0008: stloc.1
L_0009: br.s L_004d
L_000b: ldc.i4.0
L_000c: stloc.2
L_000d: br.s L_0045
L_000f: ldc.i4.0
L_0010: stloc.3
L_0011: br.s L_003d
L_0013: ldc.i4.0
L_0014: stloc.s num5
L_0016: br.s L_0034
L_0018: ldc.i4.0
L_0019: stloc.s num6
L_001b: br.s L_0029
L_001d: ldloc.s num7
L_001f: ldc.i4.1
L_0020: add
L_0021: stloc.s num7
L_0023: ldloc.s num6
L_0025: ldc.i4.1
L_0026: add
L_0027: stloc.s num6
L_0029: ldloc.s num6
L_002b: ldarg.0
L_002c: blt.s L_001d
L_002e: ldloc.s num5
L_0030: ldc.i4.1
L_0031: add
L_0032: stloc.s num5
L_0034: ldloc.s num5
L_0036: ldarg.0
L_0037: blt.s L_0018
L_0039: ldloc.3
L_003a: ldc.i4.1
L_003b: add
L_003c: stloc.3
L_003d: ldloc.3
L_003e: ldarg.0
L_003f: blt.s L_0013
L_0041: ldloc.2
L_0042: ldc.i4.1
L_0043: add
L_0044: stloc.2
L_0045: ldloc.2
L_0046: ldarg.0
L_0047: blt.s L_000f
L_0049: ldloc.1
L_004a: ldc.i4.1
L_004b: add
L_004c: stloc.1
L_004d: ldloc.1
L_004e: ldarg.0
L_004f: blt.s L_000b
L_0051: ldloc.0
L_0052: ldc.i4.1
L_0053: add
L_0054: stloc.0
L_0055: ldloc.0
L_0056: ldarg.0
L_0057: blt.s L_0007
C# JITed:
0000003e xor edx,edx
00000040 mov dword ptr [esp],edx
00000043 nop
00000044 jmp 0000009A
00000046 xor edx,edx
00000048 mov dword ptr [esp+4],edx
0000004c nop
0000004d jmp 00000091
0000004f xor ebx,ebx
00000051 nop
00000052 jmp 00000089
00000054 xor edx,edx
00000056 mov dword ptr [esp+8],edx
0000005a nop
0000005b jmp 00000082
0000005d xor edx,edx
0000005f mov dword ptr [esp+0Ch],edx
00000063 nop
00000064 jmp 00000078
00000066 xor ebp,ebp
00000068 nop
00000069 jmp 00000070
0000006b inc dword ptr [esp+10h]
0000006f inc ebp
00000070 cmp ebp,esi
00000072 jl 0000006B
00000074 inc dword ptr [esp+0Ch]
00000078 cmp dword ptr [esp+0Ch],esi
0000007c jl 00000066
0000007e inc dword ptr [esp+8]
00000082 cmp dword ptr [esp+8],esi
00000086 jl 0000005D
00000088 inc ebx
00000089 cmp ebx,esi
0000008b jl 00000054
0000008d inc dword ptr [esp+4]
00000091 cmp dword ptr [esp+4],esi
00000095 jl 0000004F
00000097 inc dword ptr [esp]
0000009a cmp dword ptr [esp],esi
0000009d jl 00000046

[Peter Olcott]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ef***************@TK2MSFTNGP10.phx.gbl...

Joanna,

Which one, alt.inventors? That's a non-tech group I saw...
misc.int-property is much more useful. There are real patent agents and at least
one patent attorney that provide good advice for free. It can be verified as
good advice by cross validation.


--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2********************@TK2MSFTNGP12.phx.gbl.. .

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> a écrit
dans le message de news: eF***************@TK2MSFTNGP15.phx.gbl...

| Now I'm really done feeding the troll.

Heh, you ought to come and see what we have had to deal with in our non-tech
group :-))

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

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

Seriously, stop, you are embarassing yourself.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Olcott" <ol****@att.net> wrote in message
news:zvCsf.38083$QW2.1425@dukeread08...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:uo****************@TK2MSFTNGP11.phx.gbl...

Michael,

I guess that's why I don't have millions of dollars already! =)

I have about 30,000 hours invested in various inventions since 1987. This
invention was the first one to receive very strong patent protection. It
would seem that I did a good job on writing the patent for three reasons:
(1) It scored very high on all of the http://www.patentratings.com/
measures.
(2) It passed scrutiny by the USPTO the first time without reservation.
(3) The six independent claims provide very broad protection. The
functional results that I achieve can not be achieved without directly
reading on these claims.

The functional results that I achieve make possible great simplification
to the ease of use of graphical user interface based operating systems.
My original patent attorney graduated number one in his law school class
of 144 graduates.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael Bray" <mbray@makeDIntoDot_ctiusaDcom> wrote in message
news:Xn****************************@207.46.248.16. ..

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in
news:eF*************@TK2MSFTNGP15.phx.gbl:

- part of a system which is worth millions of dollars
The part I don't get is that the money-men are going to let a little
thing
like "must be written in .NET" get between them and their millions. :)

-mdb

[Peter Olcott]

"Marcus Cuda" <ma****@newsgroup.nospam> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...

OK, momma said not to feed the trolls, but I was curious.

This is a silly benchmark, since it is basically calculating n^6. The C++ and
C++/CLI compiler figures this out, but the C# compiler doesn't. Interestingly,
neither does the JITer. Everything was compiled with optimizations on under
VS2005.

The loop:
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++;

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;

If you don't copy the code the way that it was posted, then the optimizer might
optimize away the loops. The whole point is to see how fast the looping is.

C++ assembly:
00401025 mov ecx,eax
00401027 imul ecx,eax
0040102A imul ecx,eax
0040102D imul ecx,eax
00401030 imul ecx,eax
00401033 imul ecx,eax
C++/CLI IL:
L_000f: ldloc.0
L_0010: dup
L_0011: mul
L_0012: ldloc.0
L_0013: mul
L_0014: ldloc.0
L_0015: mul
L_0016: ldloc.0
L_0017: mul
L_0018: ldloc.0
L_0019: mul

C++/CLI JITed:
00000046 mov edi,esi
00000048 mov eax,esi
0000004a mov edx,esi
0000004c mov ecx,esi
0000004e mov ebx,esi
00000050 imul ebx,esi
00000053 imul ecx,ebx
00000056 imul edx,ecx
00000059 imul eax,edx
0000005c imul edi,eax
C# IL:
L_0000: ldc.i4.0
L_0001: stloc.s num7
L_0003: ldc.i4.0
L_0004: stloc.0
L_0005: br.s L_0055
L_0007: ldc.i4.0
L_0008: stloc.1
L_0009: br.s L_004d
L_000b: ldc.i4.0
L_000c: stloc.2
L_000d: br.s L_0045
L_000f: ldc.i4.0
L_0010: stloc.3
L_0011: br.s L_003d
L_0013: ldc.i4.0
L_0014: stloc.s num5
L_0016: br.s L_0034
L_0018: ldc.i4.0
L_0019: stloc.s num6
L_001b: br.s L_0029
L_001d: ldloc.s num7
L_001f: ldc.i4.1
L_0020: add
L_0021: stloc.s num7
L_0023: ldloc.s num6
L_0025: ldc.i4.1
L_0026: add
L_0027: stloc.s num6
L_0029: ldloc.s num6
L_002b: ldarg.0
L_002c: blt.s L_001d
L_002e: ldloc.s num5
L_0030: ldc.i4.1
L_0031: add
L_0032: stloc.s num5
L_0034: ldloc.s num5
L_0036: ldarg.0
L_0037: blt.s L_0018
L_0039: ldloc.3
L_003a: ldc.i4.1
L_003b: add
L_003c: stloc.3
L_003d: ldloc.3
L_003e: ldarg.0
L_003f: blt.s L_0013
L_0041: ldloc.2
L_0042: ldc.i4.1
L_0043: add
L_0044: stloc.2
L_0045: ldloc.2
L_0046: ldarg.0
L_0047: blt.s L_000f
L_0049: ldloc.1
L_004a: ldc.i4.1
L_004b: add
L_004c: stloc.1
L_004d: ldloc.1
L_004e: ldarg.0
L_004f: blt.s L_000b
L_0051: ldloc.0
L_0052: ldc.i4.1
L_0053: add
L_0054: stloc.0
L_0055: ldloc.0
L_0056: ldarg.0
L_0057: blt.s L_0007
C# JITed:
0000003e xor edx,edx
00000040 mov dword ptr [esp],edx
00000043 nop
00000044 jmp 0000009A
00000046 xor edx,edx
00000048 mov dword ptr [esp+4],edx
0000004c nop
0000004d jmp 00000091
0000004f xor ebx,ebx
00000051 nop
00000052 jmp 00000089
00000054 xor edx,edx
00000056 mov dword ptr [esp+8],edx
0000005a nop
0000005b jmp 00000082
0000005d xor edx,edx
0000005f mov dword ptr [esp+0Ch],edx
00000063 nop
00000064 jmp 00000078
00000066 xor ebp,ebp
00000068 nop
00000069 jmp 00000070
0000006b inc dword ptr [esp+10h]
0000006f inc ebp
00000070 cmp ebp,esi
00000072 jl 0000006B
00000074 inc dword ptr [esp+0Ch]
00000078 cmp dword ptr [esp+0Ch],esi
0000007c jl 00000066
0000007e inc dword ptr [esp+8]
00000082 cmp dword ptr [esp+8],esi
00000086 jl 0000005D
00000088 inc ebx
00000089 cmp ebx,esi
0000008b jl 00000054
0000008d inc dword ptr [esp+4]
00000091 cmp dword ptr [esp+4],esi
00000095 jl 0000004F
00000097 inc dword ptr [esp]
0000009a cmp dword ptr [esp],esi
0000009d jl 00000046

[Peter Olcott]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:es****************@TK2MSFTNGP11.phx.gbl...

Seriously, stop, you are embarassing yourself.
Time will tell.


--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Olcott" <ol****@att.net> wrote in message
news:zvCsf.38083$QW2.1425@dukeread08...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uo****************@TK2MSFTNGP11.phx.gbl...

Michael,

I guess that's why I don't have millions of dollars already! =)

I have about 30,000 hours invested in various inventions since 1987. This
invention was the first one to receive very strong patent protection. It
would seem that I did a good job on writing the patent for three reasons:
(1) It scored very high on all of the http://www.patentratings.com/ measures.
(2) It passed scrutiny by the USPTO the first time without reservation.
(3) The six independent claims provide very broad protection. The functional
results that I achieve can not be achieved without directly reading on these
claims.

The functional results that I achieve make possible great simplification to
the ease of use of graphical user interface based operating systems.
My original patent attorney graduated number one in his law school class of
144 graduates.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael Bray" <mbray@makeDIntoDot_ctiusaDcom> wrote in message
news:Xn****************************@207.46.248.16. ..
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
news:eF*************@TK2MSFTNGP15.phx.gbl:

> - part of a system which is worth millions of dollars
>

The part I don't get is that the money-men are going to let a little thing
like "must be written in .NET" get between them and their millions. :)

-mdb

[Cecil]

I'm not a compiler authority, but I did believe it common knowledge
that the C++ compiler was the best of the bunch in terms on speed. The
engineers behind it have said that even managed code done in C++ will
outperform the other languages.

I doubt 450% is likely though. It sounds to me like you may be
comparing binary code to code that has yet to be compiled which
obviously will run signifigantly slower in most instances.

[Ignacio Machin \( .NET/ C# MVP \)]

Post the link for the patent

[Marcus Cuda]

> If you don't copy the code the way that it was posted, then the optimizer might

optimize away the loops. The whole point is to see how fast the looping is.

my apologizes. I didn't see the code listed on the site you gave (I do now), so I grabbed the code from
http://dada.perl.it/shootout - which was linked from your url.

[Peter Olcott]

"Cecil" <ce********@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I'm not a compiler authority, but I did believe it common knowledge
that the C++ compiler was the best of the bunch in terms on speed. The
engineers behind it have said that even managed code done in C++ will
outperform the other languages.

I doubt 450% is likely though. It sounds to me like you may be
comparing binary code to code that has yet to be compiled which
obviously will run signifigantly slower in most instances.

http://www.tommti-systems.de/go.html...marks.htmlHere are the benchmarks. 24,586 millisencons to 5,438 milliseconds. It is notclear whether or not the C++ is managed C++ or native code.

[Peter Olcott]

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in
message news:OG******************@tk2msftngp13.phx.gbl...

Post the link for the patent

It has just been approved December 13, 2005. I am taking my maximum time to
decide whether or not to file a divisional, a continuation, or continuation in
part. This is three months. The patent office then takes about another three
months. Then it will be posted to their website. Sometime around June 13, 2006.

[Peter Olcott]

"Marcus Cuda" <ma****@newsgroup.nospam> wrote in message
news:OG*****************@TK2MSFTNGP11.phx.gbl...

If you don't copy the code the way that it was posted, then the optimizer
might optimize away the loops. The whole point is to see how fast the looping
is.

my apologizes. I didn't see the code listed on the site you gave (I do now),
so I grabbed the code from http://dada.perl.it/shootout - which was linked
from your url.

I am quite new to .NET, I would be interested in seeing the CIL generated from
both the C# and the C++. I would also like to see if the native C++ is much
different from the managed C++ in its benchmark performance. Thanks.

[Cecil]

Um, why are we arguing over this?
Unmanaged C++ is going to outperform pretty much anything. If you need
that speed & you're not getting it w/ .NET then use C++. No biggy. I
love C++. Wouldn't want to write video games in anything else. But I
wouldn't wanna write Web Apps or Windows Apps in it anymore either. At
least not Win32 ones. It's just too tedious and the performance of .net
is exceptable for what I'm doing.

Why don't you benchmark your secret code and determine what gives you
the most positives and least negatives in terms of speed,
maintainability, deployment, etc. I don't think we can be of much help
since we're not in on the particulars of your code.

It's hard to find an area in CS that has one always best solution I'm
afraid. Since only you will be able to know all the specifics of what
you're accomplishing only you can find your answer.

[Willy Denoyette [MVP]]

"Cecil" <ce********@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I'm not a compiler authority, but I did believe it common knowledge
that the C++ compiler was the best of the bunch in terms on speed. The
engineers behind it have said that even managed code done in C++ will
outperform the other languages.
Both managed C++ and C# compile to IL which translates to machine code by
exactly the same JIT compiler. Only difference is that the managed C++
compiler is less time constrained when optimizing the IL, but even with this
slight advantage the differences are minimal and not always in favor of C++,
simply because:
the compiler teams deliver well optimized IL, but they won't spend much time
trying to optimize something that better can be left to the JIT
compiler/optimizer.
I doubt 450% is likely though. It sounds to me like you may be
comparing binary code to code that has yet to be compiled which
obviously will run signifigantly slower in most instances.

Not at all, both are compiled binary code.

Willy.

[Willy Denoyette [MVP]]

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

I know why but I don't care, these benchmarks are clueless and they are
broken, compile the C# code with /checked+ (check overflow on) and watch the
exceptions getting thrown on you.

Willy.

[Joanna Carter [TeamB]]

"Willy Denoyette [MVP]" <wi*************@telenet.be> a écrit dans le message
de news: OP**************@TK2MSFTNGP11.phx.gbl...

| I know why but I don't care, these benchmarks are clueless and they are
| broken, compile the C# code with /checked+ (check overflow on) and watch
the
| exceptions getting thrown on you.

Can I ask whether these benchmarks were taken from C# code on first run
(including JITting) or after it has been JITted ? It is only sensible to
exclude the JIT process if you are comparing execution times as, after the
first execution, times get a great deal faster due to the code now being
natively compiled.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Fabio Cannizzo]

It would seem to me that non managed code will be eventually phased out,
at least on the MS Windows platform.

I am sure you have your reasons for rejecting the idea of interop code.
However, ifwhat you mention above is your only concern, you may be right,
but I would place a very big bet you are pretty safe at least for the next
10 years.
Actually, some mathematichal intensive software is still maintained in
Fortran and has not even migrated yet to C. So I guess it may take even
longer, say another 30 years?
I believe native code is there to stay for the moment, and by the time it
become obsolete I am pretty sure you'll have had the time to complete your
patent and may be rewrite your code in same more advanced and faster
technology.
On a separate subject, I used to write ASM inline in my C++. VC4could easily
be beaten , but VC6... that's another story! I suppose DotNet will undergo
the same evolution.

Good luck
F

[Peter Olcott]

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OM*************@TK2MSFTNGP12.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.be> a écrit dans le message
de news: OP**************@TK2MSFTNGP11.phx.gbl...

| I know why but I don't care, these benchmarks are clueless and they are
| broken, compile the C# code with /checked+ (check overflow on) and watch
the
| exceptions getting thrown on you.

Can I ask whether these benchmarks were taken from C# code on first run
(including JITting) or after it has been JITted ? It is only sensible to
exclude the JIT process if you are comparing execution times as, after the
first execution, times get a great deal faster due to the code now being
natively compiled.
It must have been after the JIT, because C# beat C++ on some things, just not
the nested loops. The author of the link would know relatively obvious things
such as this.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Peter Olcott]

"Fabio Cannizzo" <fc*****************@london.edu> wrote in message
news:43**********************@reader3.news.tin.it. ..

It would seem to me that non managed code will be eventually phased out,
at least on the MS Windows platform.
I am sure you have your reasons for rejecting the idea of interop code.
However, ifwhat you mention above is your only concern, you may be right, but
I would place a very big bet you are pretty safe at least for the next 10
years.
Actually, some mathematichal intensive software is still maintained in Fortran
and has not even migrated yet to C. So I guess it may take even longer, say
another 30 years?
I believe native code is there to stay for the moment, and by the time it
become obsolete I am pretty sure you'll have had the time to complete your
patent and may be rewrite your code in same more advanced and faster
technology.

The patent is completed. I originally filed the provisional patent in August
2001. The regular patent was filed a year later. In the worst case I will have
to digress to unmanaged code. In theory there is no reason why this should be
necessary.
On a separate subject, I used to write ASM inline in my C++. VC4could easily
be beaten , but VC6... that's another story! I suppose DotNet will undergo the
same evolution.

Good luck
F

[Willy Denoyette [MVP]]

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OM*************@TK2MSFTNGP12.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.be> a écrit dans le
message
de news: OP**************@TK2MSFTNGP11.phx.gbl...

| I know why but I don't care, these benchmarks are clueless and they are
| broken, compile the C# code with /checked+ (check overflow on) and watch
the
| exceptions getting thrown on you.

Can I ask whether these benchmarks were taken from C# code on first run
(including JITting) or after it has been JITted ? It is only sensible to
exclude the JIT process if you are comparing execution times as, after the
first execution, times get a great deal faster due to the code now being
natively compiled.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

The timer is started when the function runs so after it's been compiled
(compiling the static di-unction takes less than a millisec. anyway).

Willy.

[Willy Denoyette [MVP]]

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

Argggg... broken benchmarks published by people who have no clue what they
are talking about, sorry.
Just to mention what's broken in the function that's 450% slower here is the
correct code for C#.

//x was an int type, but should be a long, else the result x will overflow
several hundred times (and be incorrect), and negatively impacting the
execution time.
int a = 0, b = 0, c = 0, d= 0, e = 0, f = 0;
long x=0; // see note above
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;

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

Herewith are the timings measured on my system.

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

2) VC++ with /O2 /EHsc (native code)
Nested Loop elapsed time: 6171 ms 479232000000

Note that this is a sample where the native C++ compiler optimizer does a
better job than C# and the JIT compiler/optimizer.

3) VC++ with /O2 /clr (managed code, unverifiable!!!)
Nested Loop elapsed time: 6406 ms 479232000000
In this particular case, the C++/CLI compiler optimizer does a better job
than C# when generating the IL, at the cost of generating unverifiable
code!!.

3) And here to please you all is the result of the same function compiled to
safe IL

// function slightly adapted to make it possible to compile with /clr:safe
(verifiable) code
static void nl(int n) {

int a, b, c, d, e, f;
__int64 x = 0;

Stopwatch^ stopWatch = gcnew Stopwatch;
stopWatch->Start();

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;
stopWatch->Stop();
TimeSpan ts = stopWatch->Elapsed;

System::Console::WriteLine("Nested Loop elapsed time: {0} sec.{1} msec.
{2}\n", ts.Seconds, ts.Milliseconds, x);
}

Nested Loop elapsed time: 12 sec.812 msec. 479232000000

Notice the result is slightly slower (dispite the O2 optimizing flag) than
the C# code, this is because the IL is constrained by the verifier (for both
C# and C++/CLI in safe mode). So here C# emits slightly better IL.

Willy.

[Mark White]

Awesome write-up! Thanks.

Is the C# code in debug or release mode?

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

Argggg... broken benchmarks published by people who have no clue what they
are talking about, sorry.
Just to mention what's broken in the function that's 450% slower here is

the correct code for C#.

//x was an int type, but should be a long, else the result x will overflow
several hundred times (and be incorrect), and negatively impacting the
execution time.
int a = 0, b = 0, c = 0, d= 0, e = 0, f = 0;
long x=0; // see note above
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;

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

Herewith are the timings measured on my system.

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

2) VC++ with /O2 /EHsc (native code)
Nested Loop elapsed time: 6171 ms 479232000000

Note that this is a sample where the native C++ compiler optimizer does a
better job than C# and the JIT compiler/optimizer.

3) VC++ with /O2 /clr (managed code, unverifiable!!!)
Nested Loop elapsed time: 6406 ms 479232000000
In this particular case, the C++/CLI compiler optimizer does a better job
than C# when generating the IL, at the cost of generating unverifiable
code!!.

3) And here to please you all is the result of the same function compiled to safe IL

// function slightly adapted to make it possible to compile with /clr:safe
(verifiable) code
static void nl(int n) {

int a, b, c, d, e, f;
__int64 x = 0;

Stopwatch^ stopWatch = gcnew Stopwatch;
stopWatch->Start();

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;
stopWatch->Stop();
TimeSpan ts = stopWatch->Elapsed;

System::Console::WriteLine("Nested Loop elapsed time: {0} sec.{1} msec.
{2}\n", ts.Seconds, ts.Milliseconds, x);
}

Nested Loop elapsed time: 12 sec.812 msec. 479232000000

Notice the result is slightly slower (dispite the O2 optimizing flag) than
the C# code, this is because the IL is constrained by the verifier (for both C# and C++/CLI in safe mode). So here C# emits slightly better IL.

Willy.

[Willy Denoyette [MVP]]

"Mark White" <ma*******@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...

Awesome write-up! Thanks.

Is the C# code in debug or release mode?

Optimized code see:

1) C# with /o+

This to be on par with the /O2 optimizing flag used to compile the C++ code.
Debug mode is obviously slower :-)

Willy.

[Peter Olcott]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

Argggg... broken benchmarks published by people who have no clue what they are
talking about, sorry.
Just to mention what's broken in the function that's 450% slower here is the
correct code for C#.

//x was an int type, but should be a long, else the result x will overflow
several hundred times (and be incorrect), and negatively impacting the
execution time.
int a = 0, b = 0, c = 0, d= 0, e = 0, f = 0;
long x=0; // see note above
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;

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

Herewith are the timings measured on my system.

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

2) VC++ with /O2 /EHsc (native code)
Nested Loop elapsed time: 6171 ms 479232000000

Note that this is a sample where the native C++ compiler optimizer does a
better job than C# and the JIT compiler/optimizer.

3) VC++ with /O2 /clr (managed code, unverifiable!!!)
Nested Loop elapsed time: 6406 ms 479232000000
In this particular case, the C++/CLI compiler optimizer does a better job than
C# when generating the IL, at the cost of generating unverifiable code!!.

So the C++ compiler produces comparable speed for both managed and unmanaged
code. Whatever verifiable means. In software engineering it meant mathematical
proof of correctness.

3) And here to please you all is the result of the same function compiled to
safe IL

// function slightly adapted to make it possible to compile with /clr:safe
(verifiable) code
static void nl(int n) {

int a, b, c, d, e, f;
__int64 x = 0;

Stopwatch^ stopWatch = gcnew Stopwatch;
stopWatch->Start();

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;
stopWatch->Stop();
TimeSpan ts = stopWatch->Elapsed;

System::Console::WriteLine("Nested Loop elapsed time: {0} sec.{1} msec.
{2}\n", ts.Seconds, ts.Milliseconds, x);
}

Nested Loop elapsed time: 12 sec.812 msec. 479232000000

Notice the result is slightly slower (dispite the O2 optimizing flag) than the
C# code, this is because the IL is constrained by the verifier (for both C#
and C++/CLI in safe mode). So here C# emits slightly better IL.

Willy.

[Peter Olcott]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

Argggg... broken benchmarks published by people who have no clue what they are
talking about, sorry.

What is wrong with the benchmark?
Just to mention what's broken in the function that's 450% slower here is the
correct code for C#.

//x was an int type, but should be a long, else the result x will overflow
several hundred times (and be incorrect), and negatively impacting the
execution time.
int a = 0, b = 0, c = 0, d= 0, e = 0, f = 0;
long x=0; // see note above
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;

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

Herewith are the timings measured on my system.

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

2) VC++ with /O2 /EHsc (native code)
Nested Loop elapsed time: 6171 ms 479232000000

Note that this is a sample where the native C++ compiler optimizer does a
better job than C# and the JIT compiler/optimizer.

3) VC++ with /O2 /clr (managed code, unverifiable!!!)
Nested Loop elapsed time: 6406 ms 479232000000
In this particular case, the C++/CLI compiler optimizer does a better job than
C# when generating the IL, at the cost of generating unverifiable code!!.

3) And here to please you all is the result of the same function compiled to
safe IL

// function slightly adapted to make it possible to compile with /clr:safe
(verifiable) code
static void nl(int n) {

int a, b, c, d, e, f;
__int64 x = 0;

Stopwatch^ stopWatch = gcnew Stopwatch;
stopWatch->Start();

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;
stopWatch->Stop();
TimeSpan ts = stopWatch->Elapsed;

System::Console::WriteLine("Nested Loop elapsed time: {0} sec.{1} msec.
{2}\n", ts.Seconds, ts.Milliseconds, x);
}

Nested Loop elapsed time: 12 sec.812 msec. 479232000000

Notice the result is slightly slower (dispite the O2 optimizing flag) than the
C# code, this is because the IL is constrained by the verifier (for both C#
and C++/CLI in safe mode). So here C# emits slightly better IL.

Willy.

[carion1]

"Peter Olcott" <ol****@att.net> wrote in message
news:7_Fsf.38113$QW2.1189@dukeread08...

What is wrong with the benchmark?

It's existence?

--

Derek Davis
dd******@gmail.com

[Michael S]

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

As Nicholas gave a great link to a thread that have been done to death,
could we just stop this one?

Stop Feeding The Troll!

While I consider myself an expert in trolling, I hate when the unskilled
ones get all the attention I deserve =)

Happy Trolling
- Michael S

[Peter Olcott]

"carion1" <ddavis76 _at_ gmail _dot_ com> wrote in message
news:Or*************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:7_Fsf.38113$QW2.1189@dukeread08...

What is wrong with the benchmark?

It's existence?

That sure seems to be a moronic answer.

--

Derek Davis
dd******@gmail.com

[Willy Denoyette [MVP]]

"Peter Olcott" <ol****@att.net> wrote in message
news:7_Fsf.38113$QW2.1189@dukeread08...

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?

Argggg... broken benchmarks published by people who have no clue what
they are talking about, sorry.

What is wrong with the benchmark?

Ever heard of integer overflow?
x (an integer type) cannot hold the value of +=a+b+c+d+e+f;
What's the value of a benchmark that produces wrong results?

Willy.

[Christoph Nahr]

On Wed, 28 Dec 2005 19:54:55 -0600, "Peter Olcott" <ol****@att.net>
wrote:

That sure seems to be a moronic answer.

You sure seem to ask a lot of moronic questions. Willy already stated
what was wrong with the benchmark _and_ corrected it, in his post that
you obviously either didn't read or didn't understand.
--
http://www.kynosarges.de

[Christoph Nahr]

On Thu, 29 Dec 2005 00:19:33 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:

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

Great analysis! This 50% slowdown is also what I've observed in other
(non-broken...) mathematical benchmarks of C# vs native C++.

For the record, that's also the maximum performance loss I've ever
observed; in tasks that aren't as well suited to modern C++
optimizers the speed difference is only about 10-20%.
--
http://www.kynosarges.de

[Jeff B]

This is all very interesting (yawn), but Mr. Olcott seems more intent on
self-promotion than question-answering. Moving on...

"Peter Olcott" wrote:

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ef***************@TK2MSFTNGP10.phx.gbl...

Joanna,

Which one, alt.inventors? That's a non-tech group I saw...

misc.int-property is much more useful. There are real patent agents and at least
one patent attorney that provide good advice for free. It can be verified as
good advice by cross validation.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2********************@TK2MSFTNGP12.phx.gbl.. .

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> a écrit
dans le message de news: eF***************@TK2MSFTNGP15.phx.gbl...

| Now I'm really done feeding the troll.

Heh, you ought to come and see what we have had to deal with in our non-tech
group :-))

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Willy Denoyette [MVP]]

"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:j4********************************@4ax.com...

On Thu, 29 Dec 2005 00:19:33 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:

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

Great analysis! This 50% slowdown is also what I've observed in other
(non-broken...) mathematical benchmarks of C# vs native C++.

For the record, that's also the maximum performance loss I've ever
observed; in tasks that aren't as well suited to modern C++
optimizers the speed difference is only about 10-20%.
--

In this "particular" case, one could conclude that the C# team could have
done a beter job. However, when looking at the IL produced by C++/CLI and C#
you'll see that all three produce identical IL (or the loop construct), so
there is no reason to blame C#.
However, despite the fact that all managed compilers produce the same IL
they perform differently:

Same IL
C#: 100% (verifiable)
C++/CLI /clr: 64% (non-verifiable)
C++/CLI /clr:safe : 120% (verifiable)

native C++ : 62%

So you see that in this 'particular case', managed code can perform like
native code and C# performs slightly better than managed safe C++, but is
this true in all cases? NO sure not. And that's why you should be careful
when interpreting benchmark figures, most of the time they have no real
value and sometimes they are (in a subtle way) incorrect
Willy.

[Peter Olcott]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:eV**************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:7_Fsf.38113$QW2.1189@dukeread08...

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Peter Olcott" <ol****@att.net> wrote in message
news:l_Asf.38059$QW2.19657@dukeread08...

http://www.tommti-systems.de/go.html...enchmarks.html
The above link shows that C# is 450% slower on something as simple as a
nested loop. Is this because .NET is inherently slower or does the C#
compiler merely produce code that is not as well optimized as the C++
compiler?
Argggg... broken benchmarks published by people who have no clue what they
are talking about, sorry.
What is wrong with the benchmark?

Ever heard of integer overflow?
x (an integer type) cannot hold the value of +=a+b+c+d+e+f;
What's the value of a benchmark that produces wrong results?

If the only purpose of the benchmark is to see how long an arbitrary construct
takes to execute arithmetic overflow should not be much of an issue. There are
some cases (such as computing the checksum) where arithmetic overflow is the
desired result,
Willy.

[Peter Olcott]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:j4********************************@4ax.com...

On Thu, 29 Dec 2005 00:19:33 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:

[1] This is the correct code which is still ~50% slower than the (corrected)
native C++ code ( __int64 x=0;).
Great analysis! This 50% slowdown is also what I've observed in other
(non-broken...) mathematical benchmarks of C# vs native C++.

For the record, that's also the maximum performance loss I've ever
observed; in tasks that aren't as well suited to modern C++
optimizers the speed difference is only about 10-20%.
--

In this "particular" case, one could conclude that the C# team could have done
a beter job. However, when looking at the IL produced by C++/CLI and C# you'll
see that all three produce identical IL (or the loop construct), so there is
no reason to blame C#.
However, despite the fact that all managed compilers produce the same IL they
perform differently:

According to MS technical support this is incorrect. The only reason that one
compiler produces faster code than another is that they generate different CIL.

Same IL
C#: 100% (verifiable)
C++/CLI /clr: 64% (non-verifiable)
C++/CLI /clr:safe : 120% (verifiable)

native C++ : 62%

So you see that in this 'particular case', managed code can perform like
native code and C# performs slightly better than managed safe C++, but is this
true in all cases? NO sure not. And that's why you should be careful when
interpreting benchmark figures, most of the time they have no real value and
sometimes they are (in a subtle way) incorrect
Willy.

[Christoph Nahr]

On Thu, 29 Dec 2005 15:55:20 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:

In this "particular" case, one could conclude that the C# team could have
done a beter job. However, when looking at the IL produced by C++/CLI and C#
you'll see that all three produce identical IL (or the loop construct), so
there is no reason to blame C#.

Now you've lost me. Marcus Cuda already posted the IL generated for
C++/CLI and C#, and they are clearly different -- the C# version is
much longer. How could it even be possible that the same IL performed
differently when generated by different compilers?
--
http://www.kynosarges.de

[Peter Olcott]

"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:su********************************@4ax.com...

On Thu, 29 Dec 2005 15:55:20 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:

In this "particular" case, one could conclude that the C# team could have
done a beter job. However, when looking at the IL produced by C++/CLI and C#
you'll see that all three produce identical IL (or the loop construct), so
there is no reason to blame C#.

Now you've lost me. Marcus Cuda already posted the IL generated for
C++/CLI and C#, and they are clearly different -- the C# version is
much longer. How could it even be possible that the same IL performed
differently when generated by different compilers?
--
http://www.kynosarges.de

My point exactly!

[Christoph Nahr]

On Thu, 29 Dec 2005 22:31:53 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:

Sorry, above is not completely true, the C# IL may differ as I only compared
the IL of both: C++ /clr and C++ /clr:safe, and despite they are identical
(only for the loop part), the results are quite different (100%).
That means that even with identical IL the perf. level may differ, and
different IL may produce equal results. The secret (especially in this
case!) lays in the metadata which 'tells' the JIT that one is verifiable
code while the other is not, so it's allowed to generate different machine
code for the same IL.
That's an interesting idea but it must be something else (see below).

The unsafe method modifier allows the C# compiler to generate
unverifiable code, too, but a quick test showed absolutely no
difference between two benchmark runs -- one unchanged, one with the
"unsafe" modifier on the nested loop test. So apparently the machine
code generated for either flag is identical.
Marcus code posted in this thread is wrong,he changed:

x+=a+b+c+d+e+f;
into:
x++;
, please re-read his post and the follow-up,
Right, I saw his post now.
PS. find the IL for both in attachment.

You've lost me again. I've compared both IL sequences, and they are
quite different! The unverifiable version has a different calling
convention, a smaller local stack, calls to C++ library methods, and
overall a smaller IL instruction count.

My diff program can't find the identical loop part that you claim
exists because the two IL sequences are so different. Evidently the
/clr:safe switch causes the C++ compiler to generate different IL, not
just to set a different JIT flag.
--
http://www.kynosarges.de

[Anders Borum]

Hello!

It must have been after the JIT, because C# beat C++ on some things, just
not the nested loops. The author of the link would know relatively obvious
things such as this.

Unless somebody documents what methods have been used to measure the
benchmarks, I am disposing the data altogether. Benchmarks should be
verifiable ..

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)

[Anders Borum]

I think Mr. Olcott was busy filing patent requests instead of reading the
excellent posting by Mr. Denoyette. I must admit that I have learned some
great things about IL and optimization from this thread, but I am still
wondering why some people post here in the first place ..

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)