Linked by Thom Holwerda on Sun 20th Apr 2008 15:43 UTC
Geek.com 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 310615
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-08-26
It may not be 200 times slower, but it is slower. It's on average in the same order of magnitude as C/C++ across a series of benchmarks, which for most people is about the same speed. For a good idea of actual relative performance, see the Great Computer Language Shootout. The issue of speed being in the same order of magnitude doesn't matter for applications centered around small packets of work interrupted either by I/O or user think time. But even that depends on the application.
In graduate school I did quite a bit of Genetic Algorithm related classwork. This was purely compute intensive code. In some of the more interesting applications the fact that Java is 2x the speed of similar code under C means 2 weeks of runtime instead of 1 week of run time. If the code was largely computational, that didn't do a lot of I/O, I would use Java because it's a very productive language to work in. JDK 4/5 didn't seem to have the same I/O performance as straight C. Having no evidence, I always assumed this had to do with the layers of library code surrounding Java I/O.
If you start adding in issues like memory usage, the picture becomes murkier. Java requires significantly more memory than the equivalent C code. Depending on the version of the VM started up, the difference can be megabytes (for the VM and program) versus kilobytes (for the C code). The libraries layered on top of all this burn even more memory. For example, Rails using C Ruby versus JRuby. They both execute Ruby code, but JRuby deployed in a J2EE environment easily requires 512 of megs of memory to do what C Ruby does in about 20-50 megs of Ram.
Like anything in life, it's a trade off. Java is a very productive language with a huge world of libraries. For many businesses this represents a real cost savings for their custom, line of business applications. It is not the panacea that most Java developers pretend it is. In some cases the speed difference is real and can't be ignored. In some cases Java is actually faster than C due to run-time optimizations that C can't do (as it stands). However, it seems like we have to buy large, more capable servers (in some cases with 4 times the ram and 2 times the speed) just to do the same or a little bit more work than what we did last year. Part of that is the result of these huge frameworks that are not intrinsic to Java but come along for the ride (weather we want them or not).