C/C++ is compiled – STATICALLY – against a range of CPUs. Java bytecode is loaded at runtime, quickly JIT compiled, and then compiled dynamically as the program “ages.” This means that Java code can not only be compiled against a very specific processor, but it can also optimise things like “branch prediction,” because it can watch the program run for a while before it optimally compiles the code. This is why the “-server” JVM waits until a piece of code has been called at least 10,000 times (by default) before compiling it to machine code.

One of the main reasons that Java can be faster than C++ in real world applications is that malloc is a very slow way of managing memory. Predictable, yes. Fast, no. Java, by default uses very fast, very low overhead allocation and collection algorithms. Although C/C++ can allocate some memory on the stack, the heap portion kills it. There are alternate memory management schemes for C/C++, and some of these are much faster than the default malloc.

The bottom line here is that with Java 6, the running code is very close in performance to C/C++. With Java 6u10, the startup penalty has been significantly reduced. I use some very heavyweight Java applications in my day-to-day work. Eclipse (Java on SWT), Oxygen Author (Java Swing), and NetBeans (Java Swing), to name a few. These are seriously complex applications that are quite usable.

In my current work, we have an application that is composed of about 50 individual projects, and has to be customized at the code level for each of a dozen or so customers. We’d never be able to handle the kind of complexity we have without Java (or without a whole lot more very talented programmers). Every time I have looked at integrating C/C++ code to speed things up, I have found that Java seems to be about the same speed. Why add more complexity?

“I see no advantage to using java except maybe through pure laziness. With gcc, and sensible coding, it is possible to produce cross platform code relatively easily in C/C++.”

Take a look at .NET. Microsoft has put many billions behind this Java-like project. There are significant advantages to be gained from the programming model used by Java. But you would have to not be “lazy,” and actually go and study Java and/or .NET with an open mind.

Not true!

First, C does not have actual objects per se–things like strucs are much lighter weight, at the cost of being less useful than objects–so lets consider C++.

For apps that generate lots of objects, java is actually faster than C++ because java’s automatic memory management is just so much better than what most people in most real applications can do by hand nowadays.

The main complaint from people who seriously look at languages is that java usually uses more memory than the equivalent C++ app (and both use more than if you wrote it in C). Depending on the context (e.g. supercomputer versus tiny embedded device), this memory difference may/may not matter.

But memory intensive apps are a performance win for java.

Where C/C++ can still win over java is in certain numerical apps where hand tuned optimizations for certain cpus can make a difference.

The biggie is even jdk 6 still does not make great use of vector type of instructions; here are some links:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340864
http://forum.java.sun.com/thread.jspa?threadID=5148725&messageID=9564641
http://forums.java.net/jive/thread.jspa?threadID=18675
This will undoubtably be rectified in the future, but for now it sometimes can be an issue.

But C/C++’s days are numbered; the sweet spot of apps for where you really need C/C++ has and continues to shrink a lot to java’s favor. And java is so much more productive to program in, crossplatform, maintainable, etc.

I would expect C to be a bit quicker that java inherently.
But the advantage of bytecode on a vm is as the vm improves so does the byte-coded
application.
That is not always the case for compiled applications.

For example a comp.lang.forth post giving this some credibility.
http://tinyurl.com/yvnh4t

Would be interesting if gcc-2.9.5 rocked ICC on any of the tests.

Oh? I am surprised(though maybe not much since you are using a Core 2 Duo…). Here are my numbers for one of the benchmarks, with gcc 4.3 snapshot, and icc 10.0.023 on a P4.

fannkuch 11 runs:

icc -xN -O3 -ipo -static: 5.9s
gcc -O3 -march=pentium4 -funroll-loops -fomit-frame-pointer: 5.5s
gcc as above with profile-generate/profile-use: 5.0s

The results were:
3342 msec for java -server -XX:+AggressiveOpts -XX:+DoEscapeAnalysis -Xms128M -Xmx128M -XX:NewRatio=2 -XX:NewSize=64m -XX:CompileThreshold=1500 -XX:+UseThreadPriorities -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=32 -XX:TargetSurvivorRatio=70 -XX:+UseTLAB -XX:MinTLABSize=4k -XX:TLABSize=256k -XX:+ResizeTLAB -XX:+UseBiasedLocking -XX:+UseSpinning -XX:PreBlockSpin=80 -XX:MaxInlineSize=200 -XX:FreqInlineSize=200 mandelbrot_long 4000 4001 4002 4003 4004 4005

3291 msec for java -server mandelbrot_long 4000 4001 4002 4003 4004 4005.

I also had to change the JRockit setting such that they work on my notebook (without a commercial JRockit license):
/home/stef/progs/jrockit-R27.3.1-jdk1.6.0_01/bin/java -server -Xms:128m -Xmx:128m -Xns:32m -XXaggressive:memory -Xgcprio:pausetime -XX:+UseNewHashFunction -XXallocPrefetch -XXcallProfiling -XXtlaSize:min=8k,preferred=512k -XXlazyUnlocking mandelbrot_long 4000 4001 4002 4003 4004 4005

The results were indistinguishable for your settings and just using -server and were about 3200 msec.