Java faster than C | Hacker News Reader

Java faster than C

paulbuchheit.blogspot.com

23 pointsSam_Odio16 comments

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.

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

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

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.

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."

C++ slower than C? Isn't that the same thing? Most of the time when I hear "C++ is slow" it usually means someone ran into slow STL+compiler combination. And according to my knowledge GCC is the worst performing compiler out there when it comes to optimizations. BY FAR. Intel and MSVC++ 7.1 eat it for breakfast, even with microsoft's profile-guided optimization turned off.

And by the way, why is it always Java guys who's playing with these benchmarks? Looks like an "inferiority syndrome" to me, C++ hackers just don't seem to care. Do you know why? 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++.

STL does have a few tarpits and once you know which classes to avid, it's smooth cruising. I recommend Scott Meyer's Effective C++ books if you want to learn how to avoid a lot of C++ performance black holes: http://www.aristeia.com/books_frames.html

Yes, the choice of a C++ compiler does make some difference in algo heavy functions/methods but the art of writing high performance C++ programs has a lot more to do with overall design (which is sometimes C++ specific) and your programming style. I left C++ programming but if that's your cup of tea, look into Meyer's books. They're the best.

Java guys care because of Java's history: it was always slower than compiled languages and Java dev got a lot of crap for not having fast runtime. That's all history but there's still a ton of people out there who refuse to download Java-based programs because of 'slowness' myth.

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++.

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).

No offense, but did you carefully read what Jay said? C and C++ is essentially same language, extended with OO+templates. And you can implement virtual method call in C as well.

I would even argue that C++ is faster than C because latest compiler optimization techniques and modern approach to templatized designs yield very impressive performance not typical for ligher-level languages.

The biggest issue with C++ (as a language) in my opinion is it's total lack of modules. In the end, everything needs to be included into every cpp file.

Speed is certainly not an issue. The only language that gets a chance of beating C/C++ is probably OCaml since it gives more information about your intentions to an optimizer/code generator.

I agree with tx. With C++ you can often avoid what would be virtual method calls in Java / if statements in C by using templates. This lets you effectively inline every function call. It'd be hard to do this in a clean way in C.

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.

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.

I don't think it's the pointer dereference so much as the fact that you can't inline virtual methods.

LLVM is outstanding, but little known. One example, a C program that uses a malloc-per-node linked list implementation might be compiled into an executable that uses an array, saving the space occupied by the pointers, and improving locality, because LLVM can analyse the whole program.

http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html

http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html

Yeah, everyone please go contribute code to LLVM! LLVM is very pleasant to hack on with a genuinely clean design, unlike GCC, which is just a big nasty mess. Hacking on LLVM is fun, hacking on GCC is a chore.

"Reload is the GCC equivalent of Satan." http://gcc.gnu.org/wiki/reload

GCC's internal garbage collector. Yes, they really wrote a garbage collector for a C app, and dealing with it is just as pleasant as you'd imagine. http://gcc.gnu.org/wiki/Memory_management

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.

Reply on news.ycombinator.com