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?"
Templates.
Any other questions?
taken! (by Davidleeroth) Thanks Bingo Foo!
(a) That's not the only problem;
(b) VB isn't the topic; and
(c) That isn't even true.
Wow, none out of three!
This really makes sense if you understand how JITs work, and understand the nature of the benchmarks. These benchmarks are mostly microbenchmarks that test a particular operation in a tight loop. JITs can compile this loop once and run it directly on the CPU afterwords. This doesn't extrapolate well to situations where the JIT gets involved more often in the benchmark.
A deep unwavering belief is a sure sign you're missing something...
Mono is a bit faster than Java, for some benchmark?
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 Mono debate. Clearly some dude's performance figure should override all other considerations when choosing a platform.
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.
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.
Yay! All the power of Java's Generics but with 10 times the code bloat.
Karma: It's all a bunch of tree-huggin' hippy crap!
...my life. It's been mostly C/C++ but also a good amount of assember and VB. Maybe someone here can answer one of the questions that keeps poping up when I write anything. My question is, why do we always end up creating libraries/classes that contain other code we will never use? What I would like is a compile environment where each function or object that I use is individually addressable, without having to pull in other "stuff" I don't need in my specific app. Is that so hard? Why doesn't the OS manage code better than pulling in a whole library? If I use only strcat() for example, why do I need to load in the entire C string library?
.NET and Suns Java take the cake by making you load an entire "run-time" engine. This consists of vast numbers of "ready-to-go" objects that make your simple "Hello World!" app into an 11 Meg progam. Java can't even share the "run-time" between apps very well!
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
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.
Karma: It's all a bunch of tree-huggin' hippy crap!
I don't know if anyone has done any formal study on the complexity of development tools over time - but the fact is that programming tools are getting "lower" over time.
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.
I'm afraid I'll have to agree with Cnik70 on this one. I can remember struggling through Java programs back in the day and thinking to myself, "No way in Hell this will ever become what everyone is saying it will be." That was then, this is now. Internal benchmarks of our code under mod_perl, PHP, Python (Zope), and Java for our web development show Java (Tomcat) to be the winner by a landslide when it comes to scalability, performance, and rapid development. From what I understand, even eBay is switching to a Java platform (anyone know more about this?). Of course, this is all on the server side...
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
-- Stu
/. ID under 2,000. I feel old now.
The large majority of Java projects are server-side, which is where it really rocks. Write once and deploy on your choice of platform (Linux, Solaris, or Windows if need be).
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.
These tests are very trivial. Basic string tests are one thing but they are very different from the complex performance implications of larger scale software.
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.
...be smart enough to "know" what sub-functions each function you are using needs to be loaded. If strcat() only uses 3 sub-functions, then those should only be loaded for "it". And, if those functions are already loaded "somewhere in memory", the OS shouldn't load them again, and again, and again, as so often happens these days.
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
No matter what you say, C is *always* faster. You *cannot* write a loop in C#, and claim that it will run faster than a comprable loop in C. For one, the interpreter for Java or C# is very likely written in C itself.
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?)
"If anything can go wrong, it will." - Murphy
Ugh. You must *love* casting variables... This would drive me nuts. It also removes the ability of an IDE to know member fn's/vars, as well as the ability of anyone to read your code...
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
And, if those functions are already loaded "somewhere in memory", the OS shouldn't load them again, and again, and again, as so often happens these days.
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.
Too bad Limbo is too deeply tied to Inferno. 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. :)
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software.
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>
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
I was going to moderate, but there you go.
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.
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 by Bruce Eckel on artima.com.
Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope 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).
I am in the process of coding a data collection server application in Java which collects data from remote devices that dail up over a phone line. The application must interface with the serial port at a low level, send email, generate XLS files, send faxes, create charts, and, of course, communicate with a DBMS. It also has a significant GUI component as well. Oh yes, this application must be able to run both on Linux and Windows (2000 or XP).
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.
You blame Java for one application that you run that performs poorly? I assume you blame the entire McDonald's corporation when you get one bad hamburger and never go there again do you? Any language can produce bad code.
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?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Possibly true for pure VB, but major VB apps aren't. In order to do a lot of things that aren't intrinsic to the language, you end up calling C/C++ or Windows API functions to get the job done. That tends to blow compatibility with non-Windows runtime environments (hell, it tends to blow compatibility with Windows environments.)
The higher the technology, the sharper that two-edged sword.
... compared to the code-generating power of lisp macros.
To a Lisp hacker, XML is S-expressions in drag.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I know the article is about C#, but every time I read something about C# I think to myself "I can do that in Python". Python is cross-platform, interpreted, object-oriented, fast, easy to extend with C or C++ and even more exciting for some people, usable transparently with Java as Jython.
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.
- Michael T. Babcock (Yes, I blog)
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.
Show me on the doll where his noodly appendage touched you.
The multiple language angle is
;-)
.net environment.
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.
-------- -------- Support Wesley Clark for president!!!
Since registration is required to read the article, I have not read it. But given the title of the publication I was alert to the possibility of bias, and I think it's quite strongly present in the introduction. Java is the platform against which .Net will be measured for the forseable time and I think that the choice of benchmarks in Part 1 strongly favour .Net.
.Net libraries can't do better than the Java libraries then I'm appalled.
.Net
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
Programmers of the world unite, you have nothing to lose but your strings.
Seriously, the MS EULA's forbid publishing benchmarks of any .net components unless MS approves of them. And this isn't even the .net EULA, its standard in all of their security updates.
This study shows C# isn't so bad... how many are being censored by MS?
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.