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!
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...
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.
...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.
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.
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.
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.
... 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.
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.