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?"
Hotspot is really good about compiling bytecodes down to the native machine language. That code is real honest to goodness native code, and will execute at approximately C++ speed.
Why use anything else?
- David
to add....
GUI development isn't that bad in Visual Studio. In fact, it is easy as hell. With emulators like Wine available, it makes sense to develop the software with Visual Studio and its amazing debugging tools for WINDOWS and then use Wine to run it on Linux.
One could use the GTK and GNU-C to develop multi-platform software in the first place, but then you are dealing with the parent poster's problem of debugging on multi-platforms, not to mention that GTK sucks under Windows (Anyone else use GAIM?)
More than enough BS
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.
I recommend that any programmers out there try using it before discounting it. It might be especially interesting for those C++ programmers out there who don't like Java for one reason or another.
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.
C# is to C/C++ like what C/C++ were to assembly. Yes, Assembly is faster then C/C++, but most of the time it's not worth the trouble. Likewise, for a lot of programming that people do today, squeezing out every last processor cycle isn't always worth it! C# offers some very convienent features compared to C/C++, yet at a minor, (and sometimes no,) performence hit.
Simply put, the language you use depends on the intended use of your application. If you're writing a number-crunching app for a single CPU type, then there's no reason to use C#. Likewise, if you're writing an application that needs to be developed quickly and be highly reliable, yet doesn't need to save each CPU cycle, then C# may be a better choice.
Personally, I think C# is great for Windows GUI programming where there is a lot of user interaction.
I've been coding for a million years: 6502 machine code all the way up to a recent foray into C#, and almost everything in between. Here's my take, for what it's worth. And, it's your chance to mod me down for pontificating!
.NET, to which C# is bolted, is pretty good as well. And the IDE is very nice. So, all-in-all, I think that C# is a good choice for Windows development. The web forms stuff seems interesting, but I have a feeling that using it would be something that I'd end up regretting - there's bound to be nasty gotchas that won't show up until late in the project.
Delphi is the best all-around language ever for producing Windows apps. The Delphi programmer has control over everything if they want it, but they don't need to muck around with nasty details unless they need to. It encourages clean coding. Performance is superb. And the IDE is excellent. The Delphi package (language plus IDE) has been the path of least resistance to getting an app done for the past six or seven years.
Prior to Delphi, the way to go was VB with C DLLs. Do the UI in VB, do the internals as C DLLs. VB was great for abstracting nasty stuff, but it often overabstracted, and performance was ungood. Writing companion DLLs in C boosted flexibility and performance.
Generally speaking, C is basically not much beyond portable assembly language. If a reasonable alternative is available, and it usually is, using C for anything beyond embedded systems or super resource-critical applications is probably not a good idea, as the code tends to be dangerous and obsfuscated. And keeping track of pointers is just nutty.
C++ is a nightmare. In theory it's object oriented, but all of the code that I've seen is a total mess, more like C using the C++ libraries. Ugh.
Java is almost good: it is pretty safe, and encourages good habits. But I find it clumsy - like it was designed by academics rather than practical developers. Lack of enumerated types, for example, is insane, and encourages unsafe programming. It's also a pig, which doesn't matter so much for a lot of things these days - we usually have lots of CPU cycles to spare. For doing GUI apps, Swing is a weird joke - a pig's pig - which should be forgotten immediately. And the Java IDEs have only recently become usable for command-line stuff, but they suck as bad as Swing for GUI development.
Now C#. Having toyed with C# for an app recently, I'm quite impressed. It's sort of like the best of Java with some of Delphi's goodness added. It's ALMOST as good as Delphi - which makes sense, since the same fellow (Anders Hejlsbeg) was key in developing both of these languages. And
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.
First of all, I've been at this professinally for over 20 years. C has always been considered to be a "low level" language -- even compared to something like Fortran. Fortran, in the versions most of us learned it when back whe it was more or less mandatory to learn it, was not "low level", it was just primitive, which is not the same thing at all.
The big change over the years isn't just that machines have gotten faster: systems have become more complex. Typical application programs are more complex than entire operating systems used to be. It isn't just that Java and C# make programs cheaper, being cheaper is another way of saying more complex systems can be built for the same budget (python takes this to a further degree).
Making real applications in the real world, I'd say this: performance doesn't matter until it does. At some point you'll deliver a product that is just not fast enough. Probably you screwed up; you should have reorganized this or that, but often its hell to fix. I always tell my guys that there is no difference in a user interface between 100ms and 300ms, not much differnce between 1 hour and 3 hours, but a lot of difference betwen 1 second and three seconds. In those cases a "frees" 2x speed improvement (which we've seen with some library upgrades) or even 20%, is a godsend.
WRT databases, I'd say this: I'd pit a modern RDBMS against an old hierarchical database -- depending on the query. Machines have got a lot faster, it is true, but databases have also got much, much larger, and the questions we are asking them are a lot more complicated. With the old databases, pretty much every question required some kind of hand coded program to answer. With modern RDBMS's, unless the question is something that can be answered by a trivial algorithm (adding a single column or traversing a single index), there's little doubt in my mind that a modern optimizer will beat what most programmers would produce in the time available to them, and what many programmers could produce with unlimited time.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Microsoft have had a .Net version of Quake II mentioned on their developer pages for some time now. It's a port to Visual C++ .Net 2003, using the CLR.
Has anyone tried this? It's presumably managed C++ rather than C#, but it should give a fair indication of the performance you'd get from C# if it's using the same run-time framework. If they can get comparable performance in a FPS using the .NET run-time, it might be worth looking at for games development after all...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Give or take a few quirks, most recent (last five years, say) C++ compilers support all the major features acceptably well for most purposes. There are only a few issues that cause significant problems: the infamous export, Koenig look-up and partial specialisation of templates come to mind. None of these features is used very often anyway, though.
Coding standards that forbid the use of templates, exceptions and half the standard library in C++ are common, but way out of date.
By the way, I write code for a living that gets shipped on more than a dozen different C++ platforms. Alas, some of them are well pre-standard, and so don't support even basic template or exception mechanics properly, which sucks. But this is an issue we've looked into in some detail, so I'm pretty confident in my statements above.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Translation: Today they are used to butcher a perfectly fine language and add new impediments to understanding.
Show me on the doll where his noodly appendage touched you.
But what if app A doesn't use but 1 function in library A? And, app B only uses 1 other function from library A?
This is why Linux pages things in on demand. It doesn't read the whole library and load it into physical memory. The library is conceptually mapped into your address space, when you try to access a function foo(), if foo() is in a page that isn't currently loaded in physical RAM, the OS gets a page fault, and that page will be loaded.
Just because you're linked against libc, that doesn't mean you're physically loading every string function into RAM when your program runs. The granularity you're talking about probably isn't worth the gain in extra complexity.
Try this:
Write a backend app in Java, and one with the same functionality in C or C++. Make sure they both read and write data to an Oracle database. Now, with stopwatch in hand, make them both run on Win2K, Cygwin, Solaris, and Linux.
Guess which language will allow you to finish first.
Correction: generics are unglorified macros. Templates are glorified macros. Templates can add type safety at compile time with no runtime penalty. Generics macro expand their type safety into java casts, which incur a decent runtime penalty (especially for large container intensive algorithms).
Additionally, I once saw someone (saurik from saurik.com) use templates to do dynamic programming at compile time. He wrote an exponentially increasing algorithm to have an exponentially increasing compile time but constant run time when an arbitrary limiting value n was increased. Not actually useful, but still really damn clever and it illustrates the versatility of templates for meta-programming. And more importantly, I am pretty sure the same program is illegal for generics.
I would suspect that brininging a "managed environment" to system level programming would be a good step.
C/C++ have served us all well. However, I suspect that something a bit more portable and simpler may be relevant, especially with the byzantine complexity of C++ behavior.
On the application end, I would suspect aspect-oriented programming is next on the horizon. More structures to ensure quality (pre/post conditions). More programming by definition and constraint with glue (built in quality control).
-------- -------- Support Wesley Clark for president!!!
I posted this already... go see how blitz++ works.
It doesn't make the language butchered in the least, quite the opposite, the end result is very clear to use and the confusing part is hidden inside the classes, where it cannot cause trouble.
the thing about C++ is, sometimes things are hard, but the reason you do them anyway is because they are worth it, and you can get high levels of abstraction (arbitrarilly high) without taking runtime hits. You have the ability to control your overhead, templates are a great example, especially the examples the parent poster mentions, expression templates, and high performance math libraries.
Blitz++ uses templates in an elegant, mind blowingly cool way. It might not be clear how it works to many, but that doesn't change how it works. Truly beautiful. And it makes the code easier to read, not harder.
-pyrrho
Start up time should be a lot better in the 1.4.2 release. Last JavaOne they specifically said work was being done on that. Further improvements are in 1.5 (when it comes out).
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
Essentially: all languages have a lot of maturation to go through, and more optimizing. :) Hell, I will be impressed when a language runs well on EPIC, with it's lack of hardware support for things most procs do in hardware, as a design idea.
I look foreward to a reply.
I've done significant work in benchmarking Java programs versus equivalent C/C++ programs. I've found that garbage collection is the sole reason that Java is slower than C++; having a "virtual machine" imposes no performance penalty whatsoever. This is unsurprising, when you think about it; a JIT compiler simply moves the latter phases of compilation ("byte code->assembly") to runtime.
Contary to what many people think, even most traditional C compilers work by compiling source to byte code, optimizing the byte code, then compiling byte code to assembly. There's no reason to expect that the resultant assembly will be any slower just because the final phase is done at run time by a JIT.
Programs compiled using IBM's Java compiler routinely outperform equivalent programs compiled using "gcc -02", if garbage collection is not used in the Java program being compiled.
I agree completely: a lot of it is down to the maturity of optimisation technology for the language in question. This is part of the reason that some high level languages -- OCaml, for example -- can generate code of a comparable speed to low-level beasts like C and C++: with a simpler underlying model, it's easier to perform good optimisations. It's also the reason C is still faster than C++ for some things, even though theoretically, C++ should never be slower.
I was including dynamic optimisation (during the program run) within the "late optimisation" idea, but in practice, I get the impression it's not used much yet. It's far easier to do platform-specific optimisation on installation or loading, effectively, just doing the optimisation phase of a compile late. Effective dynamic optimisation is a very hard thing to do, because you have the overheads of monitoring code speed to overcome before you can even hold your own, never mind gain an advantage. I suspect that in time, dynamically optimising run-times will gain a much stronger foothold in the market, but probably not until a lot more research has been done.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
First, I'll ask you to please see my comments in the other response to you...
.NET claims it will support all programming languages. It doesn't. It doesn't even come close. Once you realize .NET is just another VM that can be more easily targeted by compilers, you realize that "hey, this is ... really ... not all that interesting or useful," as I said in the post which kicked all this off.
.NET or am I talking about Java? In this case, Java. (I can't confirm the 60+ languages bit, but that's the number I see. Last I heard, Java supported more languages than .NET, but this gap was rapidly closing and the numbers are a couple of months old.)
.NET interesting? It was interesting the first time Sun did it with Java. (Or, for us dinosaurs, it was interesting the first time I saw UCSD Pascal do it with their VM.) It's not interesting this second time around.
.NET useful? If you're married to the Microsoft platform, then I guess it's useful. But really, where's the huge win for .NET over Java? There isn't one. It's an alternative to Java, not really something new and innovative, not something which allows you to solve more problems than Java or even allows you to solve them all that much differently.
Done.
In fact, even his "brilliant" graph algorithms may have been top-class during his time.
As far as I can see, remember, or am concerned, Dijkstra's contributions to computational graph theory are fundamental to the field. If you think they're brilliant-in-quotation-marks, all I can ask is what you've discovered that's comparable.
That's not meant as an insult or a challenge, incidentally. It's meant to say that in hindsight many things become obvious which required real genius to see them in the first place. Dijkstra's graph algorithms are simple and straightforward, and in hindsight they're obvious--but let's not forget that the only reason they're obvious to us is because Dijkstra had the insight to see, in foresight, what's obvious in hindsight.
If in your academic mind you truly believe this,
You keep on calling me that, an "academic". The reality is I'm nothing of the sort except in the sense that I'm a graduate student. I'm a hacker, not an ivory-tower academic. I believe in solving problems and sharing those solutions with the world.
It's axiomatic that if you're faced with a problem, one of the worst things you can do is stubbornly insist that it be solved with X technique. You have to show some flexibility. You have to be able to approach the problem from different angles. For GUIs, I've found object orientation is almost always best. For scientific programming, I've found template metaprogramming best. For using computers in math theory courses, I use LISP or ML. For writing system-level software, I use C++. Etcetera.
My insistence on multiple paradigms is unequivocally not born out of "academia", a word which it seems you're using as an insult. My insistence on multiple paradigms is born out of my demand that I use the right tool for the job.
Why is it not all that interesting or useful? Because we already have that with Java. We've got a virtual machine which provides managed services and is targeted by over 60 different languages, all of which can use all the facilities of the other languages once their code has been reduced down to bytecodes. We've got a VM which allows you to interface with the native hardware to get a massive speed boost.
Am I talking about
So where is
Where is
That said, is it useful for Company A, which prefers VB, and Company B, which uses Java, to be able to collaborate on software, each using their preferred language, with their results able to be executed on a shared VM?
Sure it is. That's not what I mean when I say ".NET is neither useful nor intere
if you have some kind of auto-email thing turned on let me know, because I'm a relative /. newbie and have no idea how to set that up if it exists...
:)
Check your User Page.
You'll see a dropdown box saying "Comment Reply". Select "Email", then save your changes and you're done.
That said, I hope you enjoyed that act of friendliness, because I see nothing but disagreements in the near future.
What I really wanted to point out was the fallacy of the "language worth learning" quote, in that it only uses "worth" in once sense of value, when in fact the majority of people in the world who deal with technology use a completely different set of criteria on which to place the "value" of learning a language - and this usually comes down to $ in the end.
I'm utterly unconvinced that the software industry has any sensible valuation of worth, particularly in the management field. Paul Graham has a great essay on why this is--what it boils down to is management's knowledge of the field and languages is primarily imparted by marketing glossies and marketing departments (either Sun's or Microsoft's, it appears). Hackers' knowledge of the field is primarily imparted by catastrophic disasters.
As an example of this, Java is being used in a lot of places today where it really shouldn't be. In 2000 during the height of the Java hype, a friend of mine who worked for a major United States bank was driven up the wall by a management decision to migrate all their COBOL apps to Java. "After all," Management said, "COBOL is a dead language and these are fifty-year-old legacy programs."
To a hacker, COBOL may well be a dead language, but a program that has a fifty-year record of reliability basically swaggers around the RAID array menacing newer programs with <DenisLeary>"yeah, I may be written in COBOL, but I haven't crashed in fifty fucking years, guy, okay?"</DenisLeary>
So was this major U.S. bank wise in their decision to migrate all their legacy COBOL apps to Java? By your logic, yes, because industry knows the value of software and can properly evaluate things in a dollars-and-cents manner. I'm certain there was a great business case made for this mass migration. I can't imagine what else could make a bank decide to undertake something that risky.
And after about 150 man-years of work--optimistically, about $15 million of development--the program was abruptly cancelled due to the fabled dollars and cents failing to materialize.
Wherever you look in the industry there are all sorts of examples like this. In the commercial software industry, I've seen far more projects fail than succeed. How does the industry respond to this? By declaring any software project that comes in at under 500% cost overrun and a year late to be a "qualified success".
The thing is, we all know this. We've all read The Mythical Man-Month. Most of us--I imagine you do, I know I do--have horror stories about death marches and the Project That Would Not Die And Yet Never Truly Lived, Either.
Given the spectacularly poor state of software management nowadays, I'm deeply skeptical of any claims that the software industry is in a position to make accurate estimations of value, whether that value be in a financial or a technical sense.
I'm a hacker. I don't know about how to value software in a financial sense. (I'm heartened by the fact that nobody else does, either.) On the other hand, I do know how to value software in a technical and artistic sense. My estimations will differ from the next hacker's, but in general we can make certain agreements--that COBOL is crufty but COBOL legacy apps that run for fifty years rock, that LISP is woefully underused, that people keep on using C when they really want to be using something else, etc.
if they had the same skillset level and also the same level of mathema