Slashdot Mirror
Does C# Measure Up?
An anonymous reader queries: "Windows::Developer is offering a detailed, quantitative examination [free login required] of C#'s performance versus Java, C, C++ and D. 'Overall the results were surprising, although perhaps unexciting, in showing that C# (and to a less extent Java) is, to a good degree, on a par in efficiency terms with its older and (presumed to be) more efficient counterparts C and C++ at least as far as the basic language features compared in this analysis are concerned,' writes the author, Matthew Wilson. I'm only an amateur coder, and confess to not understanding most of the two-part article. I'd love to hear how true programmers view his results, which are too wide-ranging to summarize easily here. How about it Slashdot, as this special edition asks, 'Can C# keep up with compiled languages like C, C++, and D or byte-code based Java?'"
While we're on the topic of C#, rnd() queries: "It's been a while now, since Mono and DotGnu have begun eroding the market power of Microsoft by creating open source implementations of C# and the Common Language Runtime. Over the weekend I loaded Mono and did some informal benchmarking of object creation, intensive message passing, massive iteration, etc., and the results show that Mono is about 90% as fast as Microsoft's implementation after a very short time. I now want to switch my .NET development over to Linux/Mono exclusively, but I want to first settle on a free alternative to Visual Studio .NET 2003. Any suggestions?"
OK lets get a few things settled.
Given: two identical applications; A, written in low level language like machine assembly, C, or C++; B, written in high level language like Java, Python, VB, hgluahalguha.
If the application is high in CPU burn (lets call it X), like oh, for (i = 0; i
If the application is copying a very large file using basic read/write system calls and large enough buffers (lets call this Y), A and B will have very similar performance.
If the application is printing hello world, they will have similar performance, although the startup costs for B may be higher, and A will probably finish executing faster.
MOST applications written today are written to solve for Y. The code that most programmers write today is NOT the CPU intensive portion. Usually the CPU intensive portion is in the library called by the programmer: rendering a box, moving things around on a storage device, making something appear on a network.
In these cases, a high or low level language makes no freaking difference on execution speed. However, your choice WILL make a huge difference on time to develop, maintainability, resultant bugginess, SECURITY, etc.
OF COURSE THERE ARE EXCEPTIONS. Maybe you're writing a routine that needs to draw lines fast, or move bytes through a network filter at 100MB/sec, or you're compressing a file, whatever. In these cases you tend to write the performance critical code in a more low level language so you have greater control over the physical machine. Sometimes you write the entire application in the low level language.
Many high level languages provide mechanisms for calling low-level code when it's necessary for performance. It's often pretty easy.
The performance argument is a red herring.
Moreover, languages like C and C++ can be used in very different ways, depending on the circumstances. You can code the "safe convenient" way using tools like STL or glib to manage strings, containers, etc. I've found that the overall performance of such an application often is in the same ballpark of a Java implementation (other than Java's obnoxious startup time).
However, C and C++ also allow you to write in a "masochistic balls-to-the-wall" mode that gives you much higher performance in exchange for 10X the programming effort. To do this, you often have to analyze your algorithms over and over until you can implement them using only stack and static structures. You avoid malloc() at all costs, avoid copying any data unless absolutely necessary, etc. You might disassemble the compiler output, run profilers and arrange data in cache-friendly patterns to squeeze out even more performance. The implementation will be much more brittle and prone to bugs, but you can often get a 10X or more speed improvement over the "natural" C or C++ implementation. Obviously, very few problems warrant this kind of attention, but making blanket statements about "comparing" other languages to C/C++ really should acknowlege the large range of performance that these languages can cover.
And this is where the .NET Framework shines, because the CLR is a generic virtual machine to which any number of languages can be compiled. Currently there are C#, C++, VB, and even Java (under the moniker J#). There has been talk of writing a Python compiler and even possibly a Perl compiler. So you can choose your language of choice, and your resulting binaries or objects will fully interoperate with the other .NET languages and class libraries.
And as far as this article is concerned, I think the interesting point is not that they're comparing apples to oranges, but just that the performance numbers for CLR-compiled C# aren't so horrible that they should scare off the majority of developers.
I really can't believe this thread. Why do people always come up with this worn out line whenever someone suggests that C++ templates are an advantage? And how come so many people have done so in replying to the same post? All but the first are (-1, Redundant), and the first is (-1, Ill-informed).
OK, please, read this carefully, for I shall write it only once (in this thread):
Java's generics are not even close to the power of C++ templates. They are glorified macros to fix a bug in the type system that should never have been there.
C++ templates were at that level around a decade ago. Today, they're used not only to create generic containers (for which they are, no doubt, very useful) but also, via metaprogramming techniques, as the tool underlying most of the really powerful developments in C++ for the past few years: expression templates, high performance maths libraries, etc.
If you didn't already know that, please read it again and understand it before proceeding.
Java's generics don't even come close to the same power. They're a cheap knock-off, aimed at just one of the uses of C++ templates, which fixes a glaring flaw in the previous Java language. For that, they serve their purpose well, but please don't pretend they're anything more.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
but you have to remember that C++ is designed to open up the power of the machine to you, not make you think a particular way or be magical for you.
The onus is on the "our language does it for you" crowd because you were not supposed to say "oh, you have to understand how the VM is working"... right?
Of course, in the end, all languages will have to tell us this "oh, yes, well, you have to know something". Of course you do! It will always be this way.
So choose the most efficient and effective language for you and learn it well, learn a different one if called for, etc.
At least, I take this to be apparent.
PS: "pyrrhonist"... right on!
-pyrrho
Currently there are C#, C++, VB, and even Java
.NET framework correctly, there is no way to support either multiple inheritance or templates--in which case C++ cannot be accurately modeled in .NET. Nor will Java be .NETtable after 1.5, which will introduce pale imitations of templates (but imitation enough to give the CLR a hissyfit).
.NET CLR does not support multiple languages. It supports one language--C#. Its "multiple language support" comes from being able to compile down many functionally-identical languages with different syntaxes down to the same bytecodes.
.NET supports are those which are subsets of C#. And once you realize that, .NET becomes much less interesting.
.NET much in the last few months. Last I checked these things were true, but after being very unimpressed with .NET I haven't kept up with things.)
If I understand the
The
But truly different languages are not representable in the CLR. Show me how to do a Scheme continuation in the CLR, please, or export a C++ template, or a LISP macro.
The only languages
(Warning: haven't used