|
Rule #1 of bench-marking code like this is to make damn sure both pieces of code are on the same playing field. As you've already been told, they are not.
NEVER EVER EVER put output code (WriteLine, cout, printf, setting a TextBox.Text property, ...) inside your timing code. If you need to print result strings, put the result values in a plain old, preallocated(!), array. Arrays works pretty much the same across all languages so there isn't much of an overhead difference between implementations. Output your data to the screen after you exit the timing code. This way, you're not timing the efficiency of the output code on top of your algorithm code. As you've seen, the differences between console, stream and even visual control implementations can be HUGE.
|
|
|
|
|
Dave Kreskowiak wrote: NEVER EVER EVER
 Hmmm, sounds like you're waffling on this issue.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
What dreadful code. Try a proper Sieve of Eratosthenes in both languages. Sieve of Eratosthenes - Wikipedia, the free encyclopedia[^]
And, as the others have said, don't judge by IO.
Also, run each several times, discard the highest and lowest times, and take the average.
And use optimized builds.
P.S. Streams is a big reason I do not use C++. 
|
|
|
|
|
Don't trust all what you read. Too many people think of C# as the early Java (that was painfully slow) or don't get what a JIT is really about.
|
|
|
|
|
Remove cout and see... Somewhere I read streams in c++ aren't performant
|
|
|
|
|
As many others have also shown, your main issue is the cout streaming in C++ is less than optimal (to say the least). Also things like compiling to production settings (i.e. all optimizations possible) instead of debug, ensuring thread priority is set to high and cpu affinity set to ensure no other processes interfere and cause a cache reload during the test. All these thing could throw out any such benchmarking.
But just to be nitpicky: You're using a simple clock to time your benchmark. In both C++ as well as C#, that has previously been seen to have lots of inaccuracies due to optimizations in the clock's implementation. To ensure the most accurate such timing (if you're not using a profiler instead - which BTW you should rather do) then rather use:
- In C++ it depends on the system. Under Linux clock_gettime[^], under Windows QPC
[^] is a better alternative - In C# you should be using Stopwatch[^] instead.
|
|
|
|
|
Comparing apples and pears ...
c
for (int i = 2; i < 2000000; i++)
for (int j = 2; j*j <= i; j++)
c#
for (int i = 2; i <= 2000000; i++)
for (int j = 2; j * j < i; j++)
As it stands now, C does quite a few more loops than C# ...
Change the loops (so that they are the same) and remove I/O from inside them. YMMV
modified 3-Feb-16 5:24am.
|
|
|
|
|
you righ'tit escaped me. I fixed now c# is 7 second.
|
|
|
|
|
Any benchmark test never ever should include I/O! You're not experienced here, so we forgive you. 
|
|
|
|
|
I am junior developer. I need to learn more software culture. But I don't have any teacher(who is senior developer) for learning this subjects. So I take risk to asking dummy questions
|
|
|
|
|
All the comments are like "but you didn't do it this way" or "you didn't do it that way".
So that pretty much just says that you can easily write c# code to be fast, and in many cases faster than c++. However if you want to obsess over your code optimization and use uncommon coding practices you can make c++ be faster than c# in many cases.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
I copied and pasted your exact code and compiled them with the Visual Studio 2008 (v9.0) compilers (cl for C++, csc for C#) and got wildly different results--C++ reported a time of 2.868 seconds, versus 4 for C#. My exact command lines were:
For C++:
cl /EHcs cpptest.cpp
cpptest.exe > cppoutput.txt
For C#:
csc cstest.cs
cstest.exe > csoutput.txt
As far as why people say C++ is faster than C#--there are a great many factors, including how the code was written, what the code is doing, how it was compiled, the system (hardware and OS) it's run on, compilers, etc. that can make a difference, and no doubt there may be examples of C# performing some things faster in some instances. In general, I think it has more to do with the overhead inherent in C#, but that's just me speculating. Maybe we can get a real answer from someone knows more than I do about the internals of the languages (and whether managed C++/CLI would have had results similar to the C# code above).
|
|
|
|
|
This is like challenging a boxing champion to an arm-wrestling competition and then find him wanting.
The speed of C++ is not tested by printing into stdout. Do some processing that doesn't involve printing repeatedly into console.
For example, calculate the largest 10 digit prime by traversing a 5x5 number matrix. Then compare the speed.
|
|
|
|
|
|
"my tests shows c# is faster than c++"
No they don't. You showed that ONE C# program ran faster than ONE C++ program.
Sheesh.
|
|
|
|
|
Hi,
I compiled and ran the program at home using g++.
The printing version was 5.6 seconds and a non printing version was 4.62 seconds.
much better than both those times.
C# also has the overhead on the .NET runtime.
And the C++ program just has the c++ standary libray for overhead.
c++ is fully compiled and c# is tokenized and still needs to be processed by the JIT.
|
|
|
|
|
std::endl is not equivalent to '\n' but also flushes the buffer. Try to change endl by '\n'
|
|
|
|
|
Muharrem B. wrote: Everyone says c++ is faster than c#, why?
Because "everyone" doesn't know what they are talking about when then make a statement like that.
First of course in pantheon of programming speed is of small consequence. Microsoft, google and apple are not successful because of speed but rather because they make money. Businesses that don't make money do not last. And developers that think technology is more important than sales end up working for companies that don't make money.
Second of course there can be actual business reasons where 'speed' is important but in the vast, vast majority of cases actually producing speed is based on factors besides just code and language.
Third when in fact something needs to be faster it is experience not code that actually leads to faster solutions. Someone with years of experience is much more likely to produce a 'fast' system than someone without that experience regardless of technology choice. Keep in mind however that that is an average an not an absolute.
Fourth, benchmarks, which is what you have, is pretty much useless in determining speed as far as it means anything in the business world. They often reflect nothing but one small aspect of the language and platform on which they run. That is if they are down well. Poorly done they often reflect a misunderstanding of how languages, platforms and even benchmarks work. Very rarely they even reflect a biased attempt to achieve a specific result.
Fifth if one really wants to actually focus on professional programming then one should focus on understanding the basics on what it means to create a system and not language specifics.
Basic one would be to understand that performance is impacted in the following way
1. Requirements, most impact
2. Design (including explicit and implicit.)
3. platform
4. language least impact
Basic two would be to understand that if one wants to get more performance out of an application (not a system) and one can only focus on 4 in the above then one must do the following
1. Learn how to use an application profiler
2. Learn how to simulate real business data in the application
3. Run the profiler and determine where it might actually be possible to improve performance.
Focusing on 1/2 in the above can achieve orders of magnitude impacts on performance while 4 can only achieve marginal percentage increases.
After all of that my personal opinion is that if one had an unlimited amount of time, if there was an optimal design and requirements, if two programmers were very, very experienced with similar backgrounds in application design and the application was limited to a very narrow subset of functionality then it is possible that the C++ programmer might produce a solution that is marginally faster than the C# programmer.
But since that is a complete fantasy which has nothing to do with reality it is pointless to discuss it.
|
|
|
|
|
Because its not.
1) Did you run with the debugger attached?
2) Did you build in "release" configuration?
3) Are the builds both running in x86 or x64?
4) What C++ and C#/.NET compiler are you using?
Almost nothing is faster in C# when doing numerical calculations like this.
Usually only stuff where the GC has some kind of benefit in performance be delaying de-allocation.
|
|
|
|
|
C# or rather the .Net runtime does a number of things to make code "safer". These are things like bounds checking, type safety, etc. Some of that happens at compile time, but of necessity a lot of it happens at run time. This obviously takes time. Much of it can be "turned off" if you want to though you may not want to. If you want very tight control of timing then C++ and likely straight C is a better bet. For a variety of problems .Net (and therefore C#) is performant enough and "safer" than C or C++. It is good to have options.
Pat O
|
|
|
|
|
If you can manage it, never-ever work with Telerik!!!
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Yeah.
He's too lazy, that bloke - and he never refills the coffee machine when he takes the last cup.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
But if you do and you get stuck, please don't ask questions on Telerik's own forums that are packed with people who know a lot about Telerik
|
|
|
|
|
The problem that those payed to support you don't know nothing...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Just to rub it in a bit, my experience with DevExpress is quite different. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
