C# vs. C++ performance [modified] (Contest)
-
If I'm using MSVC, do you think it's really worth it to switch over to Intel's compiler? And, does it integrate into VS? Just curious to know, as I've never used it, but I've heard positive stories about it.
Jeremy Falcon
Jeremy Falcon wrote:
If I'm using MSVC, do you think it's really worth it to switch over to Intel's compiler? And, does it integrate into VS? Just curious to know, as I've never used it, but I've heard positive stories about it.
It integrates pretty close to seamlessly into the VS environment. As for efficiency, that is a tough one. The Intel compiler does a better job at optimizing unoptimized code. If you are already an expert at writing optimized algorithms the only benefit would be seamless integration to VTune to let you hand-optimize your algorithms. We've had anywhere from 1% to 20% improvements.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
On another thread some posted this link: http://www.csharphelp.com/archives2/archive458.html[^] Now I was very suprised by this bad C# result, it's not at all what I experience! So I decided to test my self! I have .NET 2 and gcc 3.4.4 I compiled like this: CPP> gcc -O3 -o sieve2.exe sieve.cpp -lstdc++ C#> csc /o+ /nologo /out:sieve.exe Sieve.cs I got: C# 10000 Milliseconds = 1156 C++ 10000 Milliseconds = 1313 Haheum..... what else can I say? -- modified at 11:18 Tuesday 1st August, 2006 I propose a Contest. Post a small C++ performance test program here (less than 200 readable lines). I'll try to beat it with a C# version!
Super Lloyd wrote:
So I decided to test my self!
Unfortunately algorithm makes the difference.... I noticed a few things.... The Vector version uses < char > so occupies less memory space and with multi-byte per-word is referenced via pointer very efficiently. I also got a slower response on an integer Array, but by dropping down to a character array like the vector, the speed improved. Second... never benchmark anything under a second or near a second. increase itterations until it is at least 10 seconds. you get a better benchmark, most benchmarks try for at least 30 seconds. If you want to bench in under a second, like time a single occurance of a function, use the CPU clock, this gives finer timing. I even found a project here that uses it. http://www.codeproject.com/datetime/ccputicker.asp[^] Third, every language has their uses. Trying to claim one language beats them all is a waste of time. Focus on the strong points, which C# has in abundance, and live with the rest without complaint. -- modified at 18:05 Tuesday 1st August, 2006
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
gcc is not exactly known for the speed of its code. try MSVC or Intel.
Why donchoo take a peekchur mayn? OK, cleeeeek
Chris Losinger wrote:
gcc is not exactly known for the speed of its code. try MSVC or Intel.
It sure beats MSVC with C. Dunno about other languages. Try it :)
**
xacc.ide-0.2.0.50 - now with partial MSBuild support!
**
-
Chris Losinger wrote:
gcc is not exactly known for the speed of its code. try MSVC or Intel.
It sure beats MSVC with C. Dunno about other languages. Try it :)
**
xacc.ide-0.2.0.50 - now with partial MSBuild support!
**
i don't have a gcc installation to try
Why donchoo take a peekchur mayn? OK, cleeeeek
-
Super Lloyd wrote:
So I decided to test my self!
Unfortunately algorithm makes the difference.... I noticed a few things.... The Vector version uses < char > so occupies less memory space and with multi-byte per-word is referenced via pointer very efficiently. I also got a slower response on an integer Array, but by dropping down to a character array like the vector, the speed improved. Second... never benchmark anything under a second or near a second. increase itterations until it is at least 10 seconds. you get a better benchmark, most benchmarks try for at least 30 seconds. If you want to bench in under a second, like time a single occurance of a function, use the CPU clock, this gives finer timing. I even found a project here that uses it. http://www.codeproject.com/datetime/ccputicker.asp[^] Third, every language has their uses. Trying to claim one language beats them all is a waste of time. Focus on the strong points, which C# has in abundance, and live with the rest without complaint. -- modified at 18:05 Tuesday 1st August, 2006
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
yeah, benchmarking itterations under 1sec there is a big chance that the .NET JIT is going to eat a big chunk of that time
-
last time i used it, the integration was almost seamless. the performance wasn't much better, if at all, for my stuff. but i'd already optimized the hell out of my code with the MS compiler, so the Intel compiler didn't have much to work with. maybe if i'd given it more naive implementations, it would have done better against MS.
Why donchoo take a peekchur mayn? OK, cleeeeek
I'm thinking that is MSVC comes just about the same anyway, it's may not be worth the extra $800. :laugh: Thanks for the info.
Jeremy Falcon
-
Jeremy Falcon wrote:
If I'm using MSVC, do you think it's really worth it to switch over to Intel's compiler? And, does it integrate into VS? Just curious to know, as I've never used it, but I've heard positive stories about it.
It integrates pretty close to seamlessly into the VS environment. As for efficiency, that is a tough one. The Intel compiler does a better job at optimizing unoptimized code. If you are already an expert at writing optimized algorithms the only benefit would be seamless integration to VTune to let you hand-optimize your algorithms. We've had anywhere from 1% to 20% improvements.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
The Intel compiler does a better job at optimizing unoptimized code.
Well, I'd like to think my code is optimized, but that very well may not be the case. :laugh: Thanks for the info.
Jeremy Falcon
-
Hey, I did optimize both! didn't you see the -O3 ?! Well the result are... well.... I didn't know gcc was that bad!.... :omg: That make me rethink about life! :laugh:
Did you try -O2 for optimization? -O2 generally optimizes better than -O3. At least it did so back in the days. :)
-- In Hypno-Vision
-
On another thread some posted this link: http://www.csharphelp.com/archives2/archive458.html[^] Now I was very suprised by this bad C# result, it's not at all what I experience! So I decided to test my self! I have .NET 2 and gcc 3.4.4 I compiled like this: CPP> gcc -O3 -o sieve2.exe sieve.cpp -lstdc++ C#> csc /o+ /nologo /out:sieve.exe Sieve.cs I got: C# 10000 Milliseconds = 1156 C++ 10000 Milliseconds = 1313 Haheum..... what else can I say? -- modified at 11:18 Tuesday 1st August, 2006 I propose a Contest. Post a small C++ performance test program here (less than 200 readable lines). I'll try to beat it with a C# version!
A few months ago, I realized that time critical C# algorithm I was working on was similar to some C++ code I had worked on previously (no big surprise since I wrote both.) My curiosity got the better of me and I spent several hours setting up performance comparisons. One thing led to another and I ended up doing even more performance comparisons. I couldn't resist throwing the code into managed C++ and trying that. On average, FOR THESE TESTS, I found that the managed C++ code ran twice as fast as the C# code and the native C++ code ran twice as fast as the managed C++ code. There was one exception; I could fill a list box with thousands of items faster in C# than in native Win32 (The performance still stunk; I needed to fully virtualize both, but I'm not on that project any more so I don't care.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Super Lloyd wrote:
and I though a new at each iteration was overkill
Of course it is an overkill, but it is a benchmark, isn't it?
it is not equal! in C++ it is just one instruction to move the stack pointer and not so in C#...
-
Uh, frankly, 95% of the time, I don't care. 95% of the time, the programmer writes such crappy code, performance is the least of my worries. Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerI have no worry, I was already sold to C#. But it's just that all my test showed that C# is just as good as C++ speedwise, so I wanted to dispel the misperception! Unfortunately I was wrong and I also learnt that GCC is a slow compiler as well. It's all good mate! ;P
-
Did you try -O2 for optimization? -O2 generally optimizes better than -O3. At least it did so back in the days. :)
-- In Hypno-Vision
Okay, let's try! It's a little bit better, but still slower than C#
-
Okay, let's try! It's a little bit better, but still slower than C#
Did you try the other optimization features that come with gcc? There's a bunch of -f-XXX flags that do stuff. But, don't get your hopes up though. GCC isn't the best compiler out there, at least not for C++. It would be interesting to compare a hand optimized version in assembler with C#. Care to write one? ;)
-- Based on a True Story
-
Did you try the other optimization features that come with gcc? There's a bunch of -f-XXX flags that do stuff. But, don't get your hopes up though. GCC isn't the best compiler out there, at least not for C++. It would be interesting to compare a hand optimized version in assembler with C#. Care to write one? ;)
-- Based on a True Story
I forget all my assembly! In fact I never passed the gap of the protected mode, that kind of stopped dead all my assembly effort :sigh:
-
it is not equal! in C++ it is just one instruction to move the stack pointer and not so in C#...
Super Lloyd wrote:
it is not equal! in C++ it is just one instruction to move the stack pointer and not so in C#...
Exactly :) That's one reason why C++ is faster than C#.
-
Super Lloyd wrote:
it is not equal! in C++ it is just one instruction to move the stack pointer and not so in C#...
Exactly :) That's one reason why C++ is faster than C#.
no, that's just show that you are a bad C# developer ;P