The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Yes, it's comparing Console.WriteLine with cout, but even then it's not a fair comparison. std::endl doesn't just write a newline character, it also flushes the output buffer. Try replacing endl with '\n'.
Also try redirecting the console output to a file, running each program several times, discarding the outliers and taking an average of the remaining run times then come back with your results. I doubt that there will be much difference between the two programs because basic C++ streams are not as bad as some people here are trying to make out.
Arguably, theoretically, C++ should be faster because it has a better ahead of time compiler.
But it's also relying on harder to optimize and write library and less elegant compiler constructs... which make it slower...
However C# will slow down at 2 crucial point:
Start-up. C# start-up time is definitely, humanely perceptibly, slower (because of all the assemblies verification)
Allegedly real time code can only be reliably be written in C++ as it is, likely easier to write allocation free code, whereas realtime C# slow down on hidden object allocation (although its allocation algorithm are much faster than C++ ones)
Finally, for laugh, it's just an empty arguments that C++ developer have against C# developer. Surprisingly most of the random comparison code written by random developer make C# wins. But the occasional C++ zealots sometimes come back after a couple of day of profiling and disassembly with a marginally faster C++ version saying that the C++ version was... unoptimized! So... here you have it!
I'm not an expert in this but I can tell you this much:
- You didn't set a processor affinity. Stack swaps could have skewed your results.
- You didn't set the process and thread priority to high. Your programs code have been interrupted by other threads.
- Did you make sure you ran both programs with compiler optimization and without debugger/profiler attached?
- Integer-arithmetic isn't representative for the overall speed of the language.
That article provides a rather thorough comparison, but it focuses on library implementations, not the core language. Just from skimming over the results I spotted several remarks on 'lousy' implementations, and that alone is a dead giveaway that the results should be taken with a huge pint of salt.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Others have already nailed it down to C++ streams. Besides that I remember reading somewhere that the execution on modern highly parallelized systems also highly depends on the structure of the code.
For example: modern systems would read several machine instructions ahead and analyze them while executing the current one. So if your code would have multiple jump instructions which would prevent effective pipelining this would probably run slower.
Note that I'm not 100% practically sure of what I just wrote. It's theoretical.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
... 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?
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
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.