Slashdot Mirror

because it is an run time interpreted language

Wrong. This hasn't been true for more than 15 years 1996. It's a JIT-compiled language, which means it has a slow startup time, but once the VM is warm, it can actually outperform C on numerical code. Really.

Benchmarks have been done and Java can often out-perform C

Cite? I've often seen that claim but don't recall many benchmarks. Maybe somebody found a ten line loop that a JIT optimizes the hell out of, but I'm very skeptical that Java can regularly outperform C.

Lies, Damn Lies, and Benchmarks, as they say. Actual mileage may vary. For short runs, the sheer overhead of setting up a JVM puts it out of the running. For server systems running more or less continuously, the startup time becomes negligible. Loop optimization is probably not one of the things that Java can optimize better than C. On the other hand, on a lot of systems, there's a significant difference in the amount of time that it takes a conditional branch instruction to take the branch versus going straight. A C compilation produces static code and if the worst-case optimization (branch taken) is selected, that's the end of the story. A JVM monitoring performance can detect this sort of thing and rewrite the code to minimize the number of times the branch is taken. Needles to say, a 10-iteration loop run once a day isn't going to benefit, but a routine that runs millions of times an hour will.

For some actual numbers, I asked my friend Google and managed to find some cases where people did a head-to-head with a greater or lesser degree of honesty (Lies, Damn Lies, ...).

Here's one:

http://keithlea.com/javabench/

A Wikipedia discussion, for contemplation by those who don't knee-jerk reject Wikipedia:

http://en.wikipedia.org/wiki/Java_performance

And something a bit more scholarly:

http://scribblethink.org/Computer/javaCbenchmark.html

And something from IBM on Java's memory-management performance:

http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

Something I read a while back and cannot recall now asserted that Java won most of their benchmarks except for those involving floating-point numbers. The reason being that C could use the processor's native FPU, but Java's "Write Once/Run Anyware" requirements forced it (unless overridden) to use IEEE Floating-point, which often had to be done in software.

IBM is a big Java proponent. The modern zSeries machines include 2 FPUs. One for the original, rather strange S/360 FP format and the other for IEEE. Not a co-incidence, I suspect. Reminds me of how a group of Honeywell engineers got together with an OS that had been written under government contract for NASA (thus available for public use), and designed a computer whose instruction set was optimized to run FORTRAN. They called they company Prime Computer.

See http://scribblethink.org/Work/kcsest.pdf and http://scribblethink.org/Work/Softestim/softestim.html

(No, I'm not being serious. The topic just reminded me of when I once jokingly justified a poorly estimated ETA on a "simple" development project by referencing the above paper.)

See http://scribblethink.org/Work/kcsest.pdf and http://scribblethink.org/Work/Softestim/softestim.html

(No, I'm not being serious. The topic just reminded me of when I once jokingly justified a poorly estimated ETA on a "simple" development project by referencing the above paper.)

The limit to any organisational scheme that you're going to end up using is where, after drilling down through whatever directory-structure you come up with, you end up in a folder with a bunch of files in it, and then the *parcticular* file that you want is somewhere in that folder--sitting right in front of you, along with all of the other files that ended up in the same group, and the question at that point is how long it's going to take you to recognise the one among all the others.

Different types of organisation-schemes basically try to minimise this problem by reducing the number of not-easily-distinguishable items that you have to deal with at any given time.

The obvious approach is to try splitting-up large, flat collections into smaller collections and adding levels of indirection when a given tier has too many items in it to be maneagable, so the first task is to figure out what `too many items to be manageable'--and you want to avoid splitting things up too much beyond the point of `small enough to manage', because there's really a trade-off going on: in order to reduce the complexity at each particular level of your structured collection of stuff, you add some navigational complexity.

So, while that will help you tackle the `number' part of the problem, there actually be some interesting (and useful!) work done toward figuring out ways of making larger collections more manageable without splitting them (i.e.: tackling the `not-easily-distinguishable' part); one of the more notable ones is a scheme for fixing the homogeneity of file-icons--because it's significantly easier to recognise a thing when it actually appears distinct from its surroundings; J.P. Lewis et al. published an essay on this, a while back, called "VisualIDs: Automatic Distinctive Icons for Desktop Interfaces", and included the results of their user testing; Lewis has a website (with the title, "VisualIDs: Scenery for Data Worlds") that's worth looking at:

        http://scribblethink.org/Work/VisualIDs/visualids.html

There's even a link, at the bottom of that page, to a reference implementation--and even patches to integrate VisualIDs into Nautilus.

Native code is always going to be 'potentially' faster than any interpreted language, but Java has quite a few optimization advantages because it doesn't use pointers. Interpreted has a lot of weak points(like overhead when all your program is doing is just calling native methods), but lack of pointers isn't all bad. http://scribblethink.org/Computer/javaCbenchmark.html

The GP was responding to whether Dalvik is really faster than Java on other phones. A LOT of optimization has gone into the Java VM. Since Android doesn't run Java(which is why they are getting sued), this is difficult. There is a post comparing the Sony Ericsson Xperia X1 and the T-Mobile G1, which have nearly identical hardware specs. In that case, Dalvik was 8x slower. http://groups.google.com/group/android-platform/browse_thread/thread/ede9ba8c787661a1/f155644d757f7bbf?#f155644d757f7bbf

When the industry as a whole moved from C and C++ to Java in the late 1990s, one of our main problems was the bloat that Java brought to the table. Memory consumption was a real issue, as was its slow nature. Things have improved somewhat, mainly driven by vast hardware advances.

Interesting take - unfortunately incorrect. Java's performance issues were almost entirely due to the interpreted nature of its code. When it was originally released, all Java code was interpreted by the JVM. The result is similar to running code through an emulator ... often usable, but certainly not competitive with native applications. The introduction of Just-in-time compilation to Java (via HotSpot and similar runtime engines) made all the difference in the world. By Java 1.2 (1998), the JRE came equipped with HotSpot and basic performance became an (often inappropriately cited) non-issue. Hardware advances played as much a role in speeding up Java as it did any other language.

Now, when we moved from C and C++ to Java, we did get a huge productivity boost, even if our apps themselves were more bloated and ran slower. Apps that would've taken us a year to develop using C++ could be finished in a couple of months using Java. We could also develop much more complex software than we could using C++. So Java did offer some real benefits, and that's why it became popular.

More info can be found with Google.

Most of the benefits offered by Java are those bestowed upon an application by virtue of running in the Java Runtime Environment (JRE), including automatic memory management (garbage collection), strong exception handling, cross-platform portability, sandboxed code execution, security controls, dynamic class generation, to name a few. Java's syntax is also familiar and effective, and caters to many newer programming models and paradigms. Nothing about Java allows applications to be more complex than they were before... I dare you to find something as complex as the Linux Kernel, or something whose complexity is handled better in Java than via a C++ toolkit like QT. Java's advantages have always been related to its abilities to simplify coding challenges, allowing more effective, secure, and functional code to be produced faster (and with a lower learning curve).

We can't say the same for Flash and HTML5, however. They both suffer from far worse bloat than Java ever did. For instance, take watching videos on YouTube. I just did that using Firefox on Linux, and the Firefox process is now using 3966 MB of RAM. That's its resident usage, not virtual usage, as well. Its virtual usage is currently 4512 MB.

This is certainly a bit subjective. For example, my Firefox running on Linux watching YouTube is only using 80MB of memory, with Flash's "npviewer.bin" adding another 10MB. However, RAM usage is not a bad thing. Traditionally, when RAM came in far smaller quantities than it did now, developers frequently traded extra CPU cycles and disk I/O to conserve memory. Now, it's almost the opposite. A good application, especially a foreground application like a web browser, will use RAM liberally to conserve bottleneck resources like CPU, bandwidth, and I/O. Most of the time, the application profiles the environment that it is running in and chooses how much RAM it will use for optimization based on that profile. A system with 1GB of RAM will likely have big applications like Firefox use significantly less memory than one with 8