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? 77 5135
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?
"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?
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?
"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
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
"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]" <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?
"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
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
"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
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
"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
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
"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
"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
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.
Post the link for the patent
> 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.
"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.
"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.
"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.
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.
"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.
"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.
"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 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
"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
"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
"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.
"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.
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.
"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.
"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.
"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.
"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
"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
"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
"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.
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
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
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
"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.
"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.
"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.
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
"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!
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
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)
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) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Neptune |
last post by:
Hello.
I am working my way through Zhang's "Teach yourself C in 24 hrs (2e)"
(Sam's series), and for nested loops, he writes (p116) "It's often
necessary to create a loop even when you are...
|
by: Peter Olcott |
last post by:
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
Why is C# 500% slower than C++ on Nested Loops ???
Will this problem be solved in...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM).
In this month's session, the creator of the excellent VBE...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: Aftab Ahmad |
last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below.
Dim IE As Object
Set IE =...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: marcoviolo |
last post by:
Dear all,
I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
| |