Linked by Thom Holwerda on Sun 20th Apr 2008 15:43 UTC
General Development is running an opinion piece on the extensive reliance of programmers today on languages like Java and .NET. The author lambastes the performance penalties that are associated with running code inside virtualised environments, like Java's and .NET's. "It increases the compute burden on the CPU because in order to do something that should only require 1 million instructions (note that on modern CPUs 1 million instructions executes in about one two-thousandths (1/2000) of a second) now takes 200 million instructions. Literally. And while 200 million instructions can execute in about 1/10th of a second, it is still that much slower." The author poses an interesting challenge at the end of his piece - a challenge most OSNews readers will have already taken on. Note: Please note that many OSNews items now have a "read more" where the article in question is discussed in more detail.
Permalink for comment 310568
To read all comments associated with this story, please click here.
He's making the wrong point
by tristan on Sun 20th Apr 2008 17:08 UTC
Member since:

Yes, managed code executes slower than native code, but in a great many cases, this really doesn't matter. GUI programmes spend the majority of their time doing nothing, waiting for user input. Sending some data across a network could easily take several orders of magnitude longer than processing that data, even if you're using managed code. And in the cases where it does matter, most managed languages make it easy to call native code to do the hardcore number-crunching.

No, the problem with managed environments is memory use. A poorly coded native app can eat memory (hello, Firefox!), but with managed apps memory use really is beyond the joke. Banshee, written in C# and running on Mono, is currently using 75MB on my system. Azureus, written in Java, is using 92MB. Memory use for Beagle (C#/Mono) is more than ten times that of Tracker (C), in my experience. And this just gets worse when running in a 64-bit environment.

Lastly, I have to take issue with this from the article:

And all because the real software developers out there, the ones who can program in assembly, or C or even C++ (though even with C++ you begin to lose so much over C, about 10% in performance or more)

Without wishing to start a flame war, it's simply not true that C++ is slower than C. In fact, if you let the compiler get clever with templates, it can sometimes be faster.

Reply Score: 18