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?"
How about Eclipse?
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
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
You claim to have worked on numerous Java projects, then complain only about GUI apps? 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).
I've worked in a variety of Java development projects in the past and not once has it ever risen to the task to show itself as a worthy choice and/or a mature language. Instead it has invariably wasted companies time and money.
I would be willing to bet the reason they failed is because you do not understand how to use Java correctly. As long as we're playing the personal experience game, it has been my experience that hardcore C/C++ programmers tend to make horrible Java programmers because they think Java should behave like C/C++. It doesn't (obviously), and when you try to shove that round peg into a square hole what you get is a huge mess.
At my company, we have a bunch of old school C/C++ progammers and a few Java programmers. As our Java products started to take off (now our #1 selling product line), we wanted to move some of those developers over to Java to help out.
It was a disaster. They made object pools in order to try to manage thier own memory. They were calling System.gc() and yield() instead of using a Java profiler to find bottlenecks. The never used lazy loading. They never used failfast ("exceptions are too slow!", they said). The result was all the projects they worked on were extremely brittle, used twice as much memory, and ran much slower than our original Java stuff because they were constantly fighting against the system instead of working with it.
Try reading Effective Java by Josh Bloch and Thinking in Java by Bruce Eckel. Do what these guys suggest and your Java apps will run just as well than as anything written in C or C++.
Linkers already do this. At this point, it is ubiquitous functionality. The linker has a list of functions that are referenced, and functions that are not referenced. Functions and libraries not referenced are discarded. I know for MSVC, this is done by using /opt:ref which is part of the default RELEASE builds. This all works for OO code like C++ as well since the methods boils down to functions as far as the linker is concerned.
There are some special cases:
1) You mentioned strcat() which can be inlined by many compilers. In this case, you trade speed for code bloat - the library isn't really used at all here. In MSVC this is an "intrinsic" function.
2) Dynamic libraries may be treated differently. It is more difficult to try to partially load them. I'm not sure how Linux handles this. Windows allows for a DLL to contain multiple code and data segments, which can be loaded individually if needed.
I do a lot of ASP3.0/SQL2k and some utility development on Win32, taking a stab at .NET. It would be nice to move over to Mono.
Anyway, I've done a bit of poking around and ran across SharpDevelop - AKA #develop . It's open source a la GPL and looks a lot like Visual Studio, and compiles C# and VB.NET; has C# => VB.NET code conversion; does projects or files; has syntaxing for the whole MS shebang. It's a .97 - this build was released Friday 9/12/2K3, officially in beta, and you can get the binaries here, go snag the source here, and get the MS.NET1.1SDK here.
To those folks who hiss and moan about the whole GNOME/.NET/Mono thing, take a gander at the rationale before playing jump to conclusions (mp3).
SharpWT - AKA #WT is a .NET port of Java SWT on both Windows/.NET and Linux/Mono platforms. So...you can develop your .NET apps to run on both Win32 and Linux with pretty much the same GUI. Neat, eh?
Anyway, intrepid Windows Developer, if you can pry yourself away from the MSDN Library for a few minutes, you might find there's something to this Mono business.
Server side tasks are just great for java; your arguments don't add up.
Any platform I've heard of for server stuff will run java. C/C++ may have a wider distribution; but not amongst relevant platforms. Irrelevant to the discussion are portable/client side/ small / light platforms, and the computation heavy things. Servers are about "service" - the naming is not a coincidence.
Most server processes run forever, or as close as possibly; not very short lived at all. Starting a new process (aka application) for every client is generally not best practice - those are threads, and don't require constant re-JIT-ing or other JVM/CLR overhead.
Rather, the larger the system, and the more data, generally the less code in relation to that data, and even less JVM in relation to data. So for the quintessential server with tons of data gunk, the c/c++ advantage is much smaller than in the GUI.
Furthermore, it is a mistake to compare the portability of java to that of c++ in the manner you do. c++ implementations aren't generally compatible. Take a look at the mozilla coding guidlines for portable c++: http://mozilla.org/hacking/portable-cpp.html
c++ isn't portable, normally. C++-- might be though. Then again, it might not be. The java language is very standardized; and in case you shouldn't have a compiler on that platform, the bytecode is too!
In conclusion, if you're using c++ for a server-side task you should consider using java instead. As a matter of fact, most scripting languages are probably better suited than c++, I can hardly image a worse fit.
Very complicated question. Ughh, there are answers at many levels, and they are all different. But here goes.
Any decent linker nowadays is "smart." This means that it already does what you are asking for -- it knows how to figure out exactly what the dependencies are, and bring in only the symbols (a symbol in this context is a chunk of code or data) that are (directly or indirectly) referenced by your code. Even though you link against all of the C Runtime, or all of the string library, the linker realizes that you are only using strcat. For this example, we'll assume that strcat uses strlen and strcpy. So your call to strcat pulls in strcat, strcpy, and strlen, but nothing else. So what you mention actually is already happening. (Unless you turn off the "smart" linking, as is common for debugging purposes.)
However, there are some additional factors at work. The first is the C Runtime (CRT). ANSI C has some very specific requirements about how the environment is to be set up before main() is called, and how the system is to be cleaned up after main() exits. C also has specs about how to prepare the system for unexpected termination and signal handling. Setup and cleanup reference a bunch of additional symbols, so you end up with much more than just main(), strcat(), strcpy(), and strlen() -- you also have atexit(), exit() and etc. There is usually a process by which you can get rid of this and start directly in main with no setup code, but then you can't use any of the CRT-supplied functions (since the CRT isn't initialized) -- you have to set up your process yourself, handle signals yourself, and are limited to calling OS functions directly (no nice wrappers like fopen, printf or such).
Then there is the issue of linking. Static or dynamic? Static linking means that all of the symbols you reference, directly or indirectly, are compiled into your binary. Dynamic linking means that all of the symbols are converted to references to external binaries, and when your binary loads, the external binaries will also load and you will use the symbol as defined in the external binary. Static linking means everything you need (and nothing you don't) is right there, compiled into your binary, so you'll never load anything you don't need. On the other hand, every program that is statically linked has its own copy of the linked-in routines, which can be wasteful of disk space and memory. With dynamic linking, the entire external binary has to be available, even if you only need one symbol from it. On the other hand, there only needs to be one copy of the binary on disk, no matter how many times it is used. And most of the time, the operating system can arrange things so that only one copy of the binary's code is loaded into memory, no matter how many processes are using it. This can save a lot of memory. For most systems, it turns out to be much more efficient to load a multi-megabyte dynamic link library into every process rather than statically link just the 200k that you actually need from that library.
Finally, there is the OS involvement. The OS has to do a certain amount of setup for any process, no matter how trivial that process is. It has to allocate a stack, map the process into memory, set up virtual memory tables for it, etc. On a modern OS, in order for it to provide the services we expect, it has to set up a bunch of stuff just in case the process decides to make use of it. It is the price we pay for having a lot of power available to us.
So for an example, I wrote up two test programs. I'm a Windows guy, so everything was done using Visual C++ 7.1. The first test was just an empty main(). Compiled and linked statically, it takes 24k on disk. That is basically just the CRT startup and shutdown code and the signal handlers (plus error message strings, etc.). It also links (dynamically) to kernel32.dll, ntdll.dll, and the OS itself. It allocates 568k of user memory/136k VM, 7k of kernel memory, and holds 14 kernel objects (thread handle, process han
Time flies like an arrow. Fruit flies like a banana.
Sure there is. Have a look at jawt.h header file that's included in your SDK installation. It allows you to access native window system primitives from JNI.
"The deluded are always filled with absolutes. The rest of us have to live with ambiguity." - Aristoi, Walter Jon Willia