
Java faster than C - Sam_Odio
http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html
======
nostrademons
That's been my experience too, for heavy numeric computation. Hotspot can
optimize the hell out of plain Java SE.

Something to keep in mind though: architectural considerations matter a whole
lot more than the particular programming language you use to implement them.
If you keep your programs simple and use tools like Java NIO when appropriate,
you can write _really_ fast code in Java. If you pile on framework after
framework, of course it's going to be slow, because it's doing a whole lot
more work.

It's very easy to write a screamingly-fast Java backend and then lose all your
speed gains by sticking it behind Hibernate, JSF, and a half-dozen JavaScript
libraries.

------
gibsonf1
It's nice to see SBCL Common Lisp tying for top speed honors with C :)

<http://news.ycombinator.com/comments?id=26136>

------
henning
With contrived benchmarks you can prove anything.

Pick something with weird bit twiddling where C is better. I pick some
business computing task involving lots of systems integration or some shit
where Java is better. And on and on.

Garbage collection is a megawin and you have to be retarded or working on
microdevices with 168 bytes of RAM to use C over Java. And that's really where
anything on the JVM wins.

------
nickb
That's my experience with Java as well. Also, Java is much faster tan C++. C++
is slower than C.

Here's an interesting link: <http://kano.net/javabench/>

"JVM startup time was included in these results. That means even with JVM
startup time, Java is still faster than C++ in many of these tests."

~~~
jey
No, C++ is not slower than C. Both C and C++ are effectively macro assembler
languages, and if you know what the 'macro' expands to, you can gauge the
performance. You could implement everything that's in C++ using just pure C
and get the same effect, but I surely do not want to manually lay out my
vtables nor do I want to replace my C++ templates with C preprocessor macros.
:-)

It should also be no surprise that Java, with its _runtime_ dynamic
optimization, is able to more strongly optimize code based on _runtime_
performance characteristics than _compile time_ optimizations performed by
traditional C and C++ compilers. This is just a guess, but it's also possible
that the Java JIT compiler is able to more aggressively optimize the generated
code by having more insight into pointer aliasing, whereas you'd need to do
whole program compilation to get the same effect with C++. (Plug: LLVM can do
whole program compilation. <http://www.llvm.org> )

As tx said in a sibling post: _Because good (performance-minded) C++
programmer has very good idea what kind of assembly instructions his code will
turn to. This is why performance-critical code is still written in C++._

~~~
nickb
Yes, C++ is unquestionably slower than C when you use it to the full potential
and when you program the C++ way! A lot of people still program in C++ using
the C style. I've used C++ for 7 yeas and have plenty of experience with it
and I've seen its slowness in many instances. Main thing to avoid with C++ is
virtual methods. Once you understand how they're implemented, you will
understand why (hint: vtables).

~~~
jey
_Main thing to avoid with C++ is virtual methods. Once you understand how
they're implemented, you will understand why (hint: vtables)._

Why? Are you concerned by the additional pointer dereference? In a tight loop
(or other performance critical repetetive code), the vtables for all the
derived types and the target piece of code would be sitting in cache already,
and the code pointed to by the vtable entry would also be in cache. You have
to fetch the object/class/struct instance that you're operating on regardless
of whether or not it has a vtable, so that's an unavoidable cost. So I don't
see how it's all that expensive. It's just a freaking pointer dereference. I
do agree that it can matter in some instances, but I generally have a long
list of things to improve before I would try to minimize pointer dereferences
on vtables. If you really are having to optimize on such a low level, you'd
probably do better to worry about cache hits/misses and data layout in-memory
first.

~~~
jadams
A pointer dereference can make all the difference in an inner loop. As usual,
the answer is to profile, then to optimize.

No other dogma really applies.

------
snorkel
Interesting but Mandelbrot is a specific math process. I'd be more impressed
if a large application with network I/O, disk I/O, threading, etc was proven
to be faster in Java than in C.

