

Java vs C performance, from Cliff Click of Azul - bensummers
http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html

======
rjurney
I was looking at doing BLAST searches on genetic data in Erlang and checked
out the benchmarks for the algorithms on different languages. I was shocked to
see the performance benchmark for FASTA on one of the benchmark sites: Java
was only slightly slower than C++, about 20% off the mark.
[http://shootout.alioth.debian.org/u32q/fulldata.php?test=fas...](http://shootout.alioth.debian.org/u32q/fulldata.php?test=fasta&p1=java-2&p2=java-2&p3=java-2&p4=java-2)

Found the url:

Java -server: 7.54 seconds

C gnu gcc: 9.33 seconds

C gnu gcc #4: 5.29 seconds

C++ GNU g++ #4 6.21 seconds

I'd always thought of Java as slow, from the early SWING days. Nope. Java is
really fast. Not sure how globally applicable this is, but I thought it was
neat. Considering what its features buy you... 20% for this algorithm is
pretty cheap. Although for C I guess its a bit more.

~~~
blub
I've noticed a curious trend with managed language programmers: they tend to
say that language X is almost as fast as C, or has C-like speed when in
reality it is significantly slower. In your case, "slightly" means 20%.

~~~
ilyak
Speed is logarithmic.

20% is logarithmic-speak is "tiny".

~~~
blub
We have two numbers: X, and Y, which is 20% larger than X. Where is the
logarithm?

~~~
ilyak
It's in axes, obviously.

You draw those X and Y according to them.

------
ZeroGravitas
Slight tangent: why does Android use a VM, but not a standard JVM?

As said in this article: _[C/C++ is better than Java when] very small
footprint is required (these days that does not include most phones). You can
get JVMs that run well in a few hundred KB._

The situations where a VM, but not a JVM are sensible seem to be totally
squashed between C/C++ on one side and the JVM on the other.

There was some theory that it was to do with licencing
(<http://www.betaversion.org/~stefano/linotype/news/110/>) but the argument
got a bit obscure for me. Something along the lines of Google couldn't
officially call it Java because it wouldn't meet the licencing requirements of
the test suite.

But not being able to call it "JavaTM" seems like a small price compared with
having an incompatible VM.

~~~
blub
These days, that INCLUDES most phones. Even if Symbian C++ is painful to write
(weird API, Qt will make it much better), most programs are written in C++ and
not Java. Java is as slow as a dog on S60 phones.

WinMo phones? It's not even available, but I've run .NET apps on a pocket PC
with 500Mhz+ processor and ~128MB RAM and the GUI is sluggish.

iPhone? Not available, but the memory constraints are drastic. See Noel
Llopis's blog posts about this.

~~~
ilyak
There is J2ME for WinMo.

I guess it runs pretty J2MEy.

------
cnlwsu
I worry when people do benchmarks like this. People ignore the context that
half the post is about and picks out the 3 lines where X performs better then
Y. The Y crowd dislikes this so jumps at the article attacking it (eventually
degrading into flamewar) Ignoring of course that the first thing the author
says is "it depends" and does everything he can to establish he is NOT saying
that X is faster then Y rather that the optimizations or something that X
provides does increase the performance of that operation (backed with some
simple benchmarks).

------
jrockway
Many of these points apply to programming languages that are arguably more
enjoyable than Java, including JavaScript (TraceMonkey), Python (PyPy), Common
Lisp (SBCL), and Haskell (GHC).

For most workloads, even hard-core number crunching, it is pretty
straightforward to get near-C performance out of those languages. I am not
sure why anyone would even bother with Java.

~~~
zmimon
If it's straightforward to get near-C performance out of those languages, why
do they lose out so badly in the language shootout? eg: Tracemonkey vs Java -

[http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javasteady&lang2=tracemonkey&box=1)

Java varies between 10 and 100 times as fast as Tracemonkey in all the tests.
If you think it is straightforward to write code that equals C performance,
you should do so and submit it to the shootout to prove your point.
Personally, I don't believe you can :-)

~~~
blub
It's straightforward because talk is cheap. Maybe jrockway could write some
near-C speed Python or JavaScript code to enlighten us. And by near-C speed I
don't mean 20% slower...

~~~
berntb
I assume he was thinking of an area like web programming, where a DB mostly is
the practical limiting factor for speed.

(Or rewriting the (often small) speed critical parts in C, after
benchmarking.)

~~~
jrockway
No, I wasn't. I was talking about the speed-critical tight loops. Once you let
GHC or TraceMonkey or PyPy or ... know what the machine types of your data is,
they will generate very fast code; often the same instructions that the C
compiler would generate.

C is fast because the programmer explicitly names the machine types to be
used. Other languages are slow because their operations can't always be
expressed in terms of operations the machine can do. (Consider Perl and "2 +
2". This is "slow" because 2 is a "SV", and that means before anything can
happen, the integer 2 has to be unboxed from the SV, the runtime has to decide
which "+" to use, and then the result has to be boxed in a "SV". This is much
slower than running the "ADD" instruction. But if you can somehow specify,
"this is not a special boxed value, just treat it as a machine integer and
don't worry about overflow or anything special", then you are doing the same
thing as C. Modern VMs (and static compilers) can guess this for you and
generate the right code.)

