Does C# Measure Up? 677
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?"
Re:In Java's case ... (Score:3, Insightful)
Templates. [josuttis.com]
Any other questions?
Re:But there's just one problem... (Score:2, Insightful)
(b) VB isn't the topic; and
(c) That isn't even true.
Wow, none out of three!
Duh (Score:5, Insightful)
Mono risks (Score:3, Insightful)
Well, why didn't you say so before?!
That way we could have avoided all that tedious discussion about IP infringements, functionality etc. in yesterday's [slashdot.org] Mono debate. Clearly some dude's performance figure should override all other considerations when choosing a platform.
Languages are not application-neutral (Score:5, Insightful)
This is just one way to slice the pie.
Languages are appropriate for different uses. I use C while kernel hacking. I use C++ for its template abstractions. I use PHP for web pages, Perl for command-line scripting. I use bash/tcsh for boot-scripts. I respect VB as an accessible language, but I have no use for a single-platform language.
What language you use depends on your application. Comparing C, C++, and C# is like comparing a wrench and a screw driver. And concluding they can both be used as a hammer.
Competition is important. Whats really needed. (Score:0, Insightful)
C# is good because it competes with java and therefore will make SUN competitive.
Whats really needed is a FAST language that can be run on all computers so the software developers don't have to develop different code for each OS so applications don't need porting and speed and memory consumption wont be noticed by the user like they do with java. Something that can also be run on all handhelds with speed.
Java will never be able to do that.
Re:In Java's case ... (Score:2, Insightful)
I've been coding most of... (Score:5, Insightful)
The problem gets even worse with C++ and objects. Huge numbers of member functions and public variables that will never be used. Microsoft's
Is there a program out there that can tell the efficiency of the operating system environment, apps and OS, by how many functions "aren't" getting used in a normal day by a user? I'm going to go out on a limb here and suggest that most RAM isn't being utilized by apps.
What I would like is an extremely efficient programming environment that compiles my six line x++ program down to a few hundred bytes total...that's in-memory while running. I want to use my RAM for data and number crunching, not unusable code.
+1-1
Re:jump off the bandwagon (Score:3, Insightful)
We're going to have to point out the separation of language and platform for you again. If the Perl community can figure it out, then anyone should be able to.
Java 'the language' is good. Java 'the machine' is good. Java 'the platform' blows presumably because all the people who could make it better are sitting on Slashdot whining about Java's performance instead of doing something about it.
What is "good"? (Score:5, Insightful)
When I started out in this business, a language like C was a high level programming language. It did a lot for the programmer, especially compared to assembler and FORTRAN.
Everything we did every day was to save memory and CPU cycles. Can we squeeze a date field into 8 bits? You bet we'd try! And we did! Heck, we could ignore weekends and holidays. Phew!
At the same time, databases were heirarchical. The databases were very close to the machine, so they were darn fast. As long as you didn't do any unexpected queries (like "sort by first name"), everything was blazing fast and tight.
Then came the higher level systems. Ouch, they sucked! We were the very first customer to run DB2 in production (quiz- you know which one?) Anyhow, it sucked rocks compared to the heirarchical databases - they were just optimized for speed! Why would anyone ever want a relational database?
But over years we came to see the light. With faster and faster machines, the number of cycles was less important. With bigger memory and disk, storage was less important. And it was butt-easy to use these tools. Easier and MUCH more maintainable.
So yeah, Java and C# are going to use more memory and more cycles than plain old C (if using the languages as expected). But for most tasks, that isn't the whole story.
The whole story is that Java and C# result in less expensive programs. And those programs should run fast enough. Yeah, not in EVERY case. But in most cases.
Performance comparisons be damned.
Re:I've been coding most of... (Score:3, Insightful)
Because strcat can call another string library function, which can call another, etc...
Code duplication is bad, remember?
Re:jump off the bandwagon (Score:5, Insightful)
As far as GUI applications are concerned, the only thing that is slow about running Java GUI apps on modern hardware is the startup time. This can supposedly be taken care of with accelerator apps which keep a JVM running in the background just waiting for Java apps to be run. Even without such acceleration, I still use jEdit as my text editor of choice for all my programming needs (http://jedit.org/), and as a sysadmin I don't even program in Java (where jEdit is best applied). I usually stick to Perl/Python for automating systems administration scripts. Nevertheless, I find that the features, performance, and overall ease-of-use in jEdit save me loads of time (nice CVS integration too).
Bottom line, Java is already in enterprise computing environments and, with an experienced developer, ready for primetime in smaller applications as well.
-- Gun
Re:I've been coding most of... (Score:2, Insightful)
Some versions even recognize classes have functions that are never referenced, and these class functions are eliminated.
You get used to using a smart linker (I've been using Delphi a lot and it has one), it changes your programming style as you build larger modules/libraries since the bloat penalty is not there.
Re:jump off the bandwagon (Score:4, Insightful)
Although true (in my experience), the idea itself has sooooo many things wrong with it...
Portability - Server-side Java, by nature, does not involve any OS-specific activity. So, with no loss of portability or functionality, you could do the same in C/C++. Which, incidentally, will run on any platform for which GCC exists - About 30 *times* the number of platforms for which a JVM exists.
Performance - Yes, servers tend to have fairly impressive hardware resources available to them. So lets cripple that hardware by making it run an interpreted language. JIT? Server-side apps also tend to have very short process lives, doing a small task and exiting. In such situations, JIT causes worse performance, as it wastes time optimizing something that will never execute again during this process' invocation.
I believe (though I do not wish to put words in his mouth) that CurtLewis only mentioned GUI programming because if you use Java anywhere else, you have misused it. It makes it easy to write an app with a similar user experience on any hardware with the resources to run the JVM. If the idea of a "user experience" has no meaning to your app, using Java means you have made a suboptimal choice.
Look at the game industry (Score:1, Insightful)
A good indicator is the game industry. Game developers are notorious early adopters and tend to care little and even hold contempt for backward compatibility. But they also require performance. There are plenty of Java puzzle games but any major game with fancy graphics that you find on a store shelf is C or C++ (with various graphic specific languages and custom game scripting type languages).
If you start seeing competitive cutting edge 3D engines written in Java, then you will know the performance difference has become moot.
There are plenty of non-game examples but that is the easiest to see.
Java and C# are great languages. Eclipse is awesome. But the performance, of Java at least, still isn't there; even with native code compilers.
But, the compiler/os should... (Score:3, Insightful)
I'm saying that the compiler/OS should be smart enough to "itemize" your entire application in terms of absolute functions/variables needed at compile and run-time.
Where is that capability? Why aren't compilers smarter?
-1+1
C is faster than Java, C#, etc. (Score:3, Insightful)
Does the speed matter? Does anyone care? No. Well, not for a vast majority of applications. Most of the time the I/O speed is the bottle-neck, not the "code" speed. So if you write a word processor, or some database app in C#, or C++, or C, or Java, more often than not, their 'apparent speed' will be comprable to each other.
A better question to ask is: Would you do numerical analysis, or number crunching/factoring algorithms in Java or C#? Would you even do them in C? (or would you go for Fortran or distributed Haskell?)
Re:Duh (Score:4, Insightful)
Re:In Java's case ... (Score:2, Insightful)
Shared libraries (Score:4, Insightful)
If the functions are in a shared library, they shouldn't be. Each library (including, for example, the C runtime) is loaded once into memory and every process uses the same code. If you modify that code in memory, Windows makes an individual copy of the page for the modifying process. I couldn't tell you exactly what the overhead is used for, but the OS isn't loading 20 copies of strcpy or whatever as long as each executable is dynamically linked.
Limbo languishes, sadly (Score:3, Insightful)
Too bad Limbo [vitanuova.com] is too deeply tied to Inferno [vitanuova.com]. It's unfortunate. From looking at how it's been designed it seems that Dennis Ritchie still hasn't lost his touch as an exceptional language designer. The Dis virtual machine that goes with it is supposedly designed to make a JIT simpler and more efficient, and well, according to Vita Nuova it gets something like 50% to 75% of the performance of compiled C/C++ code, which, if the article and Vita Nuova's benchmarks are accurate, totally blows C# and Java out of the water performance-wise. Now if only Vita Nuova would care to make it half as platform-neutral as Java... But hey, who cares, I'm already trying to do that [sourceforge.net]. :)
Re:C is faster than Java, C#, etc. (Score:1, Insightful)
AAAAHHHHHH!!! When will you learn??? C# is NOT AN INTERPRETED LANGUAGE! At worst, C# is a JIT language.
With .Net, the developer can set the program to be compiled to native code on installation. A C# loop compiled to native code on installation will be just as fast as a C loop. (Assuming that both compilers are equal in quality, which is a different argument altogether)
The problem is: that's not the problem (Score:5, Insightful)
There are plenty of dinosaurian programmers like myself who remember hacking away on small machines. Save a byte by referencing a constant stored as an opcode in the instruction stream? Excellent! SLR R1,R1 is 60ns faster than SL R1,R1? Excellent! Decrease the size of the PDP-8 bootstrap loader by one word? Excellent! (Flipping those toggle switches took a lot of time.)
In 'the old days' hardware was expensive and programmers were cheap. Hard problems were solved by incredible brainpower from great engineers. As a result, by the early 70's software had made huge advances over the punchcard/paper-tape era, and we had learned a lot about how to build quality systems.
But there was a magic moment when the curves crossed between the cost of programming time versus the cost of hardware. Suddenly, it became easier to solve a problem by adding iron rather than by thinking harder. And so we slid backwards down the slope.
As far as I'm concerned, hardly anything significant has happened in software architecture or praxis for a few decades. Sure, we have a bunch of fancy new widgets, and the common man's programming paradigm has changed. And the Open Source movement finally has given substance and a PHB-understandable framework to what Unix, LISP, Smalltalk, and other hacker communities used to do behind the scenes.
But most of today's 'new' language, compiler, data management, operating system, and other computer science paradigms had their fundamental elements invented back in the 60's and 70's. We're finally RE-discovering many great concepts of the past. But it seems we've totally forgotten the importance of efficient, defect-free code, and the methods that might be used to create it.
This is not to say that only great systems were built in 'the good old days' -- those days weren't that good, and there was plenty of crap. But the really bright folks figured out how to do things RIGHT; and yet they wound up being ignored, because 'doing it right' became less important than 'letting Bruce the part-time lifeguard do it over the weekend in Visual Basic.'
So while I totally agree with your rant, and I've made a hundred similar rants of my own, the fact is we probably won't see fundamental improvements in software platforms until subatomic physics finally provides a wall against which hardware advances can bounce. As long as the answer to every performance/capacity complaint is "wait six months" there's no incentive to invest the man-centuries it will take to revamp our software environments. We probably need to build intelligent software that can optimize itself, because WE NEVER WILL.
</rant>
Re:In Java's case ... (Score:5, Insightful)
Because it forces down your throat the concept that everything is an Object. Many people find this counter-productive as object-oriented programming is only well adapted to a subclass of problems (and trying to use that methodology when it just doesn't work is downright ugly).
Besides inheriting from Object does not solve the same problem as templates do. Templates are super-macros designed for fast runtimes. Universal object orientedness with default virtual methods causes extra overhead that C++ programmers want to avoid a lot of the time.
Notice that single-object-derived libraries for C++ exist, for example the NIH library, but that they were never as successful as the STL is.
Inheriting from Object only solves the absence of multiple inheritance in Java.
Who cares? Machine cycles are cheap... (Score:3, Insightful)
Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post [artima.com] by Bruce Eckel [mindview.net] on artima.com [artima.com].
Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python [python.org], with the performance bits in C. For a real-world example, Zope [zope.org] does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).
Not from my recent experience (Score:5, Insightful)
I have been developing on Linux. All in all, to date I've coded around 30,000 lines of code. Because of the high level of portability of the APIs, I had to change all of about a dozen lines of code to get it up and running on Windows. That's one dozen out of 30,000. There's now way you could even come close to that using C or C++, regardless of how cross-platform the library developers say their libraries are.
As far as performance, Java may have been slow three of four years ago, but the last several versions of the JDK and the HotSpot JVM have seen a steady and rapid improvement in performance and stability. SWING, although it has improved, may still be a bit slow, but computational code written in Java is only slightly slower than in C++. Even current versions of SWING, although arbuably slower than native GUIs like GTK+ or QT, are fast enough so as to not be noticable on any machine faster than 800MHz or so.
Most people who say Java is unstable or slow are remembering their experience from the JDK 1.1 days. The current JDK 1.4 bears little resemblance to that in terms of performance and maturity.
Re:What's with all of the bellyaching about speed? (Score:1, Insightful)
Re:In Java's case ... (Score:3, Insightful)
Of course it is. That's why Java's adding generics now, I guess: to fix the loopholes that approach didn't cause.
Not everything is an Object; didn't you first textbook tell you?
Re:Look at the game industry (Score:1, Insightful)
Having said that, I should clarify my position: I'm a huge C# fan [microsoft.com]. I think the language itself is tremendous, and the
Re:But there's just one problem... (Score:3, Insightful)
And both generics and templates are kiddy toys... (Score:5, Insightful)
Re:In Java's case ... (Score:5, Insightful)
In C++, casts are rarely necessary. When they are, tools like dynamic_cast allow for the same useful run-time type checking as Java et al support.
In Java, you can't even pull an object out of a container without a cast, and you can't even use a basic type in a generic container without some sort of wrapper object.
In C++, the RAII idiom lets you ensure the safe release of any resource type. In Java, you have to write the same finally blocks all over just to make up for the fact that finalizers don't work.
Java is "more safe" than C++?
Now that was funny.
Re:Duh (Score:4, Insightful)
You're missing something (Score:3, Insightful)
Actually, in practice, no it's not and yes you can.
What you're ignoring is the "late optimisation" effect of virtual-machine and intermediate language execution models. The installer or run-time can take intermediate code and convert it to native code, just as a C compiler would, but with full knowledge of the environment in which that code is going to run. That allows for specific optimisations based on the execution environment that are rarely, if ever, practical for C-based programs. (How many C programs ship with different optimised executables for each Pentium and Athlon series processor, for example?)
You seem to be writing as someone who knows how things are supposed to work, who has a certain mindset and isn't prepared to look outside it. So-called just-in-time compilers actually have a lot of potential. They aren't, in general, as fast as something like C or C++ yet. However, in theory they could actually be faster once they've matured and caught up, because they can do all the same low-level optimisation tricks as a C or C++ compiler, with more knowledge of the target environment to get the best out of them.
How about Python? (Score:3, Insightful)
I've found that almost all the programs I've written I could've written smaller and better and more obvious (and therefore easier to debug and maintain) with Python. None of those that I have rewritten show any noticeable performance penalty for having done so either.
Just wondering if you've dealt with it at all yet.
Re:In Java's case ... (Score:5, Insightful)
What many C++ programmers fail to recognize is that Java and C++, though similar, are not the same language, and the paradigms they use in C++ will not work in Java.
Good programmers learn the new paradigms, bad ones simply criticize that it doesn't work the same.
Re:C# is not the only .NET language (Score:3, Insightful)
1) to allow anyone accessibility with there skillset.
2) allow the integration and migration of legacy codebases.
3) Not piss of VB customers who are perfectly happy with their ugly piglatin language
Serious, there are large Fortran libraries out their. Microsft's approach allows easy integration.
A cobol implementation exists. Though, COBOL is almost always spagetti code riddled with non-modular entry points. But I suppose well written COBOL code can be migrated into a mixed
Ultimately, distilling it all into cross-platform IL is a thing of beauty. Managed code that can be accessed from any language and run on virtually any platform.
Re:I've been coding most of... (Score:1, Insightful)
When a DLL is loaded, the file is mapped into memory, however pages are only loaded from disk when the page is touched. So if I load a 10 MB DLL, (pretend it doesn't need to be rebased, it's already bound to all its dependent DLL's, and it doesn't have a DllMain), and I call one function that happens to live on a single page, only that touched page will be in memory. The remainder 9.96 MB will sit on disk.
Dubious choice of benchmarks (Score:2, Insightful)
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
string comparison, string concatenation, string tokenization
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with
Could C# FAIL to measure up? (Score:1, Insightful)
This study shows C# isn't so bad... how many are being censored by MS?
C# is NOT what's being tested (Score:3, Insightful)
When are people going to learn that languages that target the Common Language Runtime (CLR, only part of the .NET Framework) compile to the same thing (Intermediate Language - IL)? C# is not being tested here. The C# compiler optionally optimized and compiles source code into IL which is later JIT'd and executed. Because of this, it's the CLR and the base class library (BCL) that are being tested.
This could just as easily been done with VB.NET (not that I condone anything resembling VB) or J#, although MC++ is a different monster because it can (but doesn't have to) use native code in mixed mode and, thus, is not verifiable).
The only differences besides language syntax is the specific language compiler and the optimizations it makes. The C# compiler does - as far as I've tested - a better job of optimizing. The VB.NET compiler, for instance, automatically adds an extra local var to support the syntax FunctionName = ReturnValue whether or not you use it!
So, let's get the facts straight. C# is not being tested here. The .NET CLR and BCL are.