Live data from Hacker News

Benchmark: C++ vs C#

codeproject.com

21–30 of 36 posts

Re: Benchmark: C++ vs C#

#21

I think he hit the nail on the head referring to c# programmers in general not being as "performance conscious" which leads the misconception that c# is a much slower language to use. I've worked in many places and have come across the same thing. As a c++ programmer I have also worked with c# coders and am often shocked at their slap-dash approach to software engineering. I'm not saying they're all like that but it…

True enough in general, but that cuts both ways -- I've worked with a number of longtime C++ guys that tend to optimize early, write long unreadable methods and seem positively allergic to standard OOP architectures, much less design patterns.

Re: Benchmark: C++ vs C#

#22
post #8

The results seem conclusive: if you're developing software for the desktop, and (like me) you are equally skilled in C# and C++, it's safe to take advantage of the simpler syntax, rich standard libraries, stellar IntelliSense and reduced development effort that C# offers. With the glaring exception of numeric code, which is the most crucial thing for a lot of apps that are now written in C++. You'd be crazy to write…

http://www.getpaint.net/ I'm not saying paint.net is a replacement for photoshop. However, for me, it's in the "good enough" category. http://en.wikipedia.org/wiki/Paint.NET "Paint.NET is primarily programmed in the C# programming language, with small amounts of C++ used for installation and shell-integration related functions." Again this is good enough for a lot of peoples image manipulation. That area of "good eno…

Paint.NET is fine for small images, but performance really falls off a cliff when images get larger, whereas Photoshop hardly misses a beat. Which I guess is kind of your point, for doing 'normal' tasks under 'normal' loads C# is fine, but if you have to go beyond normal, then you really need the control and speed of something C-like.

Re: Benchmark: C++ vs C#

#23
post #8

The results seem conclusive: if you're developing software for the desktop, and (like me) you are equally skilled in C# and C++, it's safe to take advantage of the simpler syntax, rich standard libraries, stellar IntelliSense and reduced development effort that C# offers. With the glaring exception of numeric code, which is the most crucial thing for a lot of apps that are now written in C++. You'd be crazy to write…

http://www.getpaint.net/ I'm not saying paint.net is a replacement for photoshop. However, for me, it's in the "good enough" category. http://en.wikipedia.org/wiki/Paint.NET "Paint.NET is primarily programmed in the C# programming language, with small amounts of C++ used for installation and shell-integration related functions." Again this is good enough for a lot of peoples image manipulation. That area of "good eno…

Certainly C++'s niche is getter smaller every year. It just happens to be a niche occupied by the most interesting (IMO) native apps.

The flood of low-powered mobile devices out there seems to have given it some new legs though.

Re: Benchmark: C++ vs C#

#24
This article raises interesting questions. He has done low-level tests which do not read much from the data or instruction pipelines, so these tests show compiled MSIL can be better optimized than C++. C++ is prone to accidental performance deficits from problems like aliasing, so that makes sense.

Now I want to see higher-level tests, where algorithms reading significant data or application-level benchmarks are run. The faster the CPU core, the less penalty there will be from C# compilation. The problem is that it would take lots of time to translate something like WORF, GAMESS, or other standard numerical benchmarks.

Re: Benchmark: C++ vs C#

#25

The poor guy is taking a beating in the code-project comments which is a pity since he obviously spent some time putting it together. In a comparison like this, you are always going to get people on either side of the fence claiming the results are invalid because there was some compiler switch or code construct that was missed. The language-agnostic version of this article: you can write slow code in any language.

In the article he illustrated that with a Microsoft C++ library example (a heap?). In the benchmark he fixed it by writing his own. You can do that in C++

Re: Benchmark: C++ vs C#

#26
post #22

Earlier quoted context omitted.

http://www.getpaint.net/ I'm not saying paint.net is a replacement for photoshop. However, for me, it's in the "good enough" category. http://en.wikipedia.org/wiki/Paint.NET "Paint.NET is primarily programmed in the C# programming language, with small amounts of C++ used for installation and shell-integration related functions." Again this is good enough for a lot of peoples image manipulation. That area of "good eno…

Paint.NET is fine for small images, but performance really falls off a cliff when images get larger, whereas Photoshop hardly misses a beat. Which I guess is kind of your point, for doing 'normal' tasks under 'normal' loads C# is fine, but if you have to go beyond normal, then you really need the control and speed of something C-like.

I don't know, to me it seems there's a likely chance that Photoshop's implementation of handling large files is just better, and if Paint.NET took a similar approach maybe the performance might be more comparable. By this I mean stuff like not having to go through the whole file to generate a zoomed view of it, etc. Of course this is just an assumption based on the fact Paint.NET isn't in the same class of application as Photoshop, so I wouldn't expect handling massive files to be a priority to the authors. That and Photoshop has been around a lot longer and Adobe probably has more resources to throw at potential problems like this. Either way, these are just guesses to consider before assuming the difference is caused by the language.

Re: Benchmark: C++ vs C#

#27
This benchmark is totally wrong as you can read in the comments of the page.

Basically he didn't turn on all optimizations on the C++ program and used the "slow but secure" version of the Microsoft STL.

Also his GenericSum uses array in C++ and lists in C#, so the C++ has to reallocate at each append.

I could go on for long, I appreciate the intent, but all you need to know is that Microsoft gave up on using C# everywhere because it's damn too slow.

Re: Benchmark: C++ vs C#

#28
Even though the benchmark is incorrect, the flawed conclusion should lead you to see that Java is just as good a solution as C# (possibly better since it runs officially on more platforms).

Re: Benchmark: C++ vs C#

#29

This benchmark is totally wrong as you can read in the comments of the page. Basically he didn't turn on all optimizations on the C++ program and used the "slow but secure" version of the Microsoft STL. Also his GenericSum uses array in C++ and lists in C#, so the C++ has to reallocate at each append. I could go on for long, I appreciate the intent, but all you need to know is that Microsoft gave up on using C# every…

>> but all you need to know is that Microsoft gave up on using C# everywhere because it's damn too slow.

Got any proof of that?

Re: Benchmark: C++ vs C#

#30
post #29

This benchmark is totally wrong as you can read in the comments of the page. Basically he didn't turn on all optimizations on the C++ program and used the "slow but secure" version of the Microsoft STL. Also his GenericSum uses array in C++ and lists in C#, so the C++ has to reallocate at each append. I could go on for long, I appreciate the intent, but all you need to know is that Microsoft gave up on using C# every…

>> but all you need to know is that Microsoft gave up on using C# everywhere because it's damn too slow. Got any proof of that?

Not proof but, fwiw I read an article saying that.
Post reply on HN