|
I had one of these[^] the other day (I was driving - needed something less than full strength) and all I can say is: What were they thinking? 
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: We all know that VB is faster than them both.
... I assume this is after you accelerated it out the muzzle of a cannon.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Let's hear it for VB. Hip hip
|
|
|
|
|
So much is impossible to tell. But, as others have mentioned, avoid <iostream> for performance.
There are some very clever template libraries that do printf like behaviour while retaining type-safety. Which are the best of both worlds.
Apart from that, are you timing a release build? C++ typically optimises way more aggressively in release builds.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Not anyone I know says C++ *is* faster than C#. Most of the people I hear talking about it say C++ *can be* faster than C#. It's much easier to play memory arithmetic tricks in C++ than C#. You can do it in C# using Memory Pins and Unsafe blocks, but it's a lot more code to write just to get to a point where you can start doing the actual work of manipulating your values.
Also, trivial examples like that won't show you the biggest culprit of performance issues in any .net language: the GC. Once the GC starts grinding away, you can kiss anything that resembles good performance goodbye. You can of course mitigate this by using proper patterns and such, but that's a whole lot of mental overhead that the C++ programmer doesn't need to deal with.
|
|
|
|
|
C++ is filth. For real speed you need C. 
|
|
|
|
|
That depends a lot on whether you want to reuse components such as sort algorithms.
I doubt very much you can match std::sort performance with C code, except for hand-coding every damn sort. Even then, C++ optimisation is damn fine nowadays.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: hand-coding every damn sort
As appropriate for the specific task, yes.
|
|
|
|
|
C is filth. For real speed you need Assembler.
|
|
|
|
|
This link is a blog series done by Raymond Chen and Rico Mariani where Raymond wrote a Chinese dictionary in C++ and Rico wrote a naïve line-by-line translation of the C++ code in C#. The C# code blew away the C++ code in performance.
Raymond then did a number of ever more severe optimizations (including writing his own string class) to finally beat the naïve C# performance. Rico then optimized the C# code and again beat the C++ performance.
Raymond then did a couple of more optimizations to finally beat the C#.
The summary is thus: Doing a straightforward implementation in C# will yield really good performance (and is much quicker to implement, relative to C++), in many cases better than a straightforward implementation in C++. But, if you put in a significant amount of optimization effort, C++ CAN clearly outperform the C# code - as noted in the final blog post of that series, there's certain initial overhead (60ms in Rico's case) that the CLR imposes that you cannot optimize away in C#.
|
|
|
|
|
Gjeltema wrote: is much quicker to implement
Yes, and probably with lower maintenance requirements. As well as C# probably requiring a development team with an overall lower payroll. These are factors that really matter in real-world development. And if the result is "good enough", then call it done and move on.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
