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?"
C# is higher pitch than C but less so than D.
--
How about Eclipse?
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...
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?
:-D
VI.
C,D, I feel bad for the F Programmer.
Java SDK v1.5 (not yet released) contains support for 'generics', which are very much like C++ templates for Java:
l
http://java.sun.com/features/2003/05/bloch_qa.htm
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.
You apparently haven't taken the time to work with any of the newer releases of java (1.3 and 1.4). Java is a very mature and worthy language, especially when it comes to developing non platform dependent applications. I prefer java since I CAN program it on a Linux box, transfer it to a windows, mac or even a mainframe and the program will still run exactly the same without changing a single line. lets see c, c++, .Net or c# do that...
Also don't forget about a little thing called J2ME which is slowly but surely making it's way onto cell phones and other small devices.
You may want to take another look at todays Java before declaring that it sucks.
-Cnik
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.
...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
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.
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.
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.