Why is C# 500% slower than C++ on Nested Loops ???

[Peter Olcott]

http://www.tommti-systems.de/go.htm...ain-Dateien/reviews/languages/benchmarks.html
Why is C# 500% slower than C++ on Nested Loops ???
Will this problem be solved in the future???

 

[Bob Grommes]

Peter,

Well ... you will note it's more than 3 times faster than Java, which is
a much more appropriate comparison. C++ and C# are different tools for
different purposes, and are most usefully compared to their peers, not
to each other.

That said, you're right that the gap was particularly wide in this case.
I can only guess that C# doesn't have as many compiler optimizations
in place as C++ that would benefit this particular scenario.

--Bob

 

[Peter Olcott]

Peter,

Well ... you will note it's more than 3 times faster than Java, which is a much more appropriate comparison. C++ and C# are
different tools for different purposes, and are most usefully compared to their peers, not to each other.

That said, you're right that the gap was particularly wide in this case. I can only guess that C# doesn't have as many compiler
optimizations in place as C++ that would benefit this particular scenario.

--Bob

I am estimating that it will be a problem that is easy to fix.
I am making this estimate on the basis of how well C# did
on the other benchmarks, compared to Visual C++.

 

[Randy A. Ynchausti]

Peter,

Why is C# 500% slower than C++ on Nested Loops ???

If you are really worried about performance and still want to use managed
code, please read up on "ngen".

Regards,

Randy

 

[Jon Skeet [C# MVP]]

Well ... you will note it's more than 3 times faster than Java, which is
a much more appropriate comparison.

Which result are you looking at? Looking at the "nested loops" column
(the one the OP is talking about) I can only see Java being faster than
C# - and in some cases the Java is faster than the C++.

Also note that the released Java 1.5 isn't part of the results, and
neither is the IBM JVM (which I believe would be a lot better at the
trig - I don't know about the other results).

 

[Jon Skeet [C# MVP]]

If you are really worried about performance and still want to use managed
code, please read up on "ngen".

That makes startup faster, but it actually reduces the number of
optimisations the JIT performs.

 

[Christoph Nahr]

I am estimating that it will be a problem that is easy to fix.

Uh, no. Writing a good optimizer is pretty hard. The current
iterations of Visual C++ and Intel C++ had over a decade of labor
poured into them to make them as fast as they are.

I am making this estimate on the basis of how well C# did
on the other benchmarks, compared to Visual C++.

You're comparing different benchmarks for languages with very
different infrastructures! You can't make any cross-inferences from
one benchmark to another in this case.

 

[Zanna]

Which result are you looking at? Looking at the "nested loops" column
(the one the OP is talking about) I can only see Java being faster than
C# - and in some cases the Java is faster than the C++.

Java faster than something else?
It's hard to me to figure it out

 

[Willy Denoyette [MVP]]

http://www.tommti-systems.de/go.htm...ain-Dateien/reviews/languages/benchmarks.html
Why is C# 500% slower than C++ on Nested Loops ???
Will this problem be solved in the future???

In general, such kind of micro-benchmarks have little or no value, in this
particular case, it shows that the C# language compiler could have done a
better job in optimizing the IL.
To prove it, here are the results of the nested loop run comparing C++,
C++/CLI and C#.

//C++ native (Compiler version 13.00)
Nested Loop elapsed time: 6048 ms -1804337152
//C++ managed - compiler options /clr /O2 /EHsc (14.00)
Nested Loop elapsed time: 6047 ms -1804337152
//C#
v1.1
Nested Loop elapsed time: 19800 ms - -1804337152
v2.0
Nested Loop elapsed time: 21050 ms - -1804337152

See, the native C++ and managed C++ results are the same, this indicates
that it's not a JIT issue but an IL issue.
When comparing the generated IL of both C# and C++/CLI, it's the C++/CLI
language compiler who did a better job than C#. However, for the
'Exceptions" case, it's C# who is the clear winner (managed code), so
suppose this is the result of the differences in priorities and constraints
set by the different language teams.


Willy.

 

[Peter Olcott]

Uh, no. Writing a good optimizer is pretty hard. The current
iterations of Visual C++ and Intel C++ had over a decade of labor
poured into them to make them as fast as they are.

Yet, since these mechanisms already exist in code that Microsoft
already owns, it is only a matter of adapting and porting. By very
easy, I am meaning, "just takes a little work", as opposed to
requiring new computer science to be invented.

 

[Peter Olcott]

Which result are you looking at? Looking at the "nested loops" column
(the one the OP is talking about) I can only see Java being faster than
C# - and in some cases the Java is faster than the C++.

The next to last column on the right of all three tables. On this column
on these tables MS C++ won all but one the fifteen benchmarks.
On this column of these tables C++ consistently beat C# by a factor
of about 500%.

 

[Peter Olcott]

In general, such kind of micro-benchmarks have little or no value, in this particular case, it shows that the C# language compiler
could have done a better job in optimizing the IL.
To prove it, here are the results of the nested loop run comparing C++, C++/CLI and C#.

//C++ native (Compiler version 13.00)
Nested Loop elapsed time: 6048 ms -1804337152
//C++ managed - compiler options /clr /O2 /EHsc (14.00)
Nested Loop elapsed time: 6047 ms -1804337152
//C#
v1.1
Nested Loop elapsed time: 19800 ms - -1804337152
v2.0
Nested Loop elapsed time: 21050 ms - -1804337152

See, the native C++ and managed C++ results are the same, this indicates that it's not a JIT issue but an IL issue.
When comparing the generated IL of both C# and C++/CLI, it's the C++/CLI language compiler who did a better job than C#. However,
for the

That is very helpful information. That provides me with just
the sort of answer that I was looking for. I wanted to know
whether or not there is any inherent property of the .NET
architecture that prevented it from executing the fastest possible
code. Your little experiment would seem to prove that the
answer is no.

'Exceptions" case, it's C# who is the clear winner (managed code), so

From the tables on the link that I provided, C# was consistently
400% slower than C++.

 

[Willy Denoyette [MVP]]

From the tables on the link that I provided, C# was consistently
400% slower than C++.

I was comparing C# and C++/CLI (both managed code) where C# is twice as fast
as C++/CLI, NOT C# and native C++!

Willy.

 

[Peter Olcott]

I was comparing C# and C++/CLI (both managed code) where C# is twice as fast as C++/CLI, NOT C# and native C++!

Can you post these results please?
Thanks again for your help. The first answer that you
provided has proven to me the .NET development will
eventually replace all development on the Windows platform.
..NET is a superb Rapid Application Development architecture.

 

[Mike]

Can you post these results please?
Thanks again for your help. The first answer that you
provided has proven to me the .NET development will
eventually replace all development on the Windows platform.
.NET is a superb Rapid Application Development architecture.

Why would you need those results to prove that to you?
If the code inside was actually doing anything - dealing with a database or
the GUI or any other I/O, responding to events, whatever, then you'd have a
hard time even measuring any performance penalty. (You'd probably find the
C# faster than native C++, if both were coded ideomatically - and you'd
certainly find the C# easier to write and read and be free of most memory
issues.) If you're trying to predict the weather or code the inner loop of
your renderer, then you're using the wrong tool and you should code that 1%
of your program (after profiling) in native code.

Even so, it's rarely the technical merits alone that decide if a language
will be a success.

m

 

[Peter Olcott]

Why would you need those results to prove that to you?

You have generally shown that the performance of code is dependent upon the
code generator, and optimizer rather than any inherent features of the .NET
architecture. The one exception to this seems to be "exceptions." I want
to fully understand why this might be.

If the code inside was actually doing anything - dealing with a database or the GUI or any other I/O, responding to events,
whatever, then you'd have a hard time even measuring any performance penalty. (You'd probably find the

I have developed a system that I am planning on porting the C# .NET
architecture. It is a system rather than application program. Its performance
requirements are based on real-time response rate. It is very computationally
intensive. Far greater than 99% of its time is spent performing computations.
From the results that you provided, in the worst case scenario I can
switch to C++ .NET from C# .NET, to achieve my required performance.
I want to completely verify this before I spend too much time learning .NET

 

[Guest]

updated results & benchmarks:

http://www.cuj.com/documents/s=9816/cuj0507bruckschlegel/0507bruckschlegel.html



Thomas