|
Agreed 
Jeremy Falcon
|
|
|
|
|
Are we that picky now that we cannot even talk about programming language performance in the Lounge ?
If that is the case, then we should rename the site LoungeProject.com ...
I'd rather be phishing!
|
|
|
|
|
After a quick check, what you're really comparing here is the efficiency of Console.WriteLine vs cout
If you swap cout for printf you get much more similar times. In my case the C++ was a second faster than the C# but it's not a very fair comparison.
Really I don't think you'll find much difference in performance of either.
|
|
|
|
|
Good catch!
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Exactly. To make a fair comparison, just eliminate all io within the loop. Or, better yet, don't do any io within the code block that is measured.
That said, I wouldn't expect *any* meaningful difference for this code. it's just basic arithmetic that translates directly to assembly, and that goes for both C++ and C#.
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)
|
|
|
|
|
An answer to the question? What's wrong with you!!! 
It's funny how it was so horrible that this question was here, but the whole long conversation about liberals and stuff is just fine! Hmmm people just being people again. It's a shame the way we act sometimes.
hatfok
King Yiddum's Castle
Pegasus Galaxy
|
|
|
|
|
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.
|
|
|
|
|
Thanks for getting back on topic. While questioning c++ is perhaps not PC, it is relevant to programmers (given the marked difference in development time.)
|
|
|
|
|
Well... you know now how much of a lie it is!
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!
|
|
|
|
|
That's the way I see it. C++ as a religious belief
|
|
|
|
|
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.
Take a look here: Head-to-head benchmark: C++ vs .NET[^]
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
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)
|
|
|
|
|
Thanks for the very informative link!
|
|
|
|
|
3rd point down is crucial. Newbies often forget to ramp up compiler optimisation to -O2 or -O3. Leaving it as the default optimisation level usually sucks.
|
|
|
|
|
You successfully proofed the poor performance of C++ streams.
Just try the C++ version with printf instead of streams and it should be faster.
|
|
|
|
|
Yee I tried printf("%i\n",i);
it is 7 second. That's faster than coutt
|
|
|
|
|
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. 
|
|
|
|
|
Tomaž Štih wrote: I'm not 100% practically sure of what I just wrote.
I'd suggest that as a signature for some of our regular Lounge participants. I won't name names. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I already have it for long time  
M.D.V. 
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.
|
|
|
|
|
We all know that VB is faster than them both.
cheers
Chris Maunder
|
|
|
|
|
Shirley you mean VB on Rails!
veni bibi saltavi
|
|
|
|
|
Chris Maunder wrote: We all know that VB is faster than them both.
But not as fast as Coopers.
Michael Martin
Australia
"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 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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
