Java running faster than C (2007)
paulbuchheit.blogspot.com
paulbuchheit.blogspot.com
At http://shootout.alioth.debian.org/, an up-to-date list of the most popular languages are benchmarked. Tests are standardized, and code is optimized for the tested language and particular benchmark. Also, for each benchmark, not only execution speed, but also memory consumption and code size are measured, and the processor architecture is taken into account too.
http://shootout.alioth.debian.org/u64q/performance.php?test=...
Next time someone is tempted please remember:
- You are comparing apples to oranges (interpreters to compiled languages, bigint libraries to hardware-level ints, etc.)
- What a C compiler does on one particular architecture running under a particular OS is not representative of C performance
- You are most probably benchmarking just a tiny subset of what the language can do, and in most cases that subset is irrelevant in 99% of uses (e.g. "float comparison faster in Blub". Who cares if most people are using Blub to build webpages?)
- Finally and most importantly: WHO CARES? Unless it affects a part of the code I'm using extensively it will only affect performance tangentially, if at all.
EDIT: formatting
The two big managed languages (Java and C#) are now getting fast enough that there is only one place where slower performance can be assumed. That's the startup time - bootstrapping the managed runtime and JITing the code takes a while, so languages like C will always rule for execution patterns along the lines of a CGI script.
It can also be said that they'll always be bigger memory hogs, which is something to think about when you're working in a constrained environment. That's a side effect of the garbage collector - objects aren't cleaned up right away, so there's always a "queue" of objects that are waiting for cleanup that's just sitting around occupying RAM.
However, in terms of overall performance the story gets murky. In many real-world applications C or C++ is unlikely to outperform the managed languages (certainly not by a significant margin) unless significant spent on careful optimization. All that work increases both initial development and continuing maintenance costs, though, so it is unlikely to be worthwhile unless you're in a situation where a small amount of execution time really is worth a large amount of money.
This is a difference you're never going to be seeing on the benchmark sites, though. Benchmarks are by necessity small programs, which means that are easy to carefully optimize to an extent that doesn't necessarily reflect what is practical in the real world.