In what cases is Java faster than C++?

Re:In what cases is Java faster than C++? by goalieca on Wednesday February 16, 2011 @10:15AM (#2226638)

Well, note how the article said "naive" memory allocation and even then it was specific to a microbenchmark. I've written very high performing memory allocation routines for multi-threaded scenarios and if you know the types of allocations you will be making you can leave any GC or standard memory allocation routines in the dust!

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by agazso on Wednesday February 16, 2011 @10:36AM (#2226730)

In C or C++ you can even allocate objects on the stack, which has only the cost of increasing the stack pointer (meaning it is very cheap), and also you have precise control over the object's lifetime.

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by akeefer on Wednesday February 16, 2011 @11:26AM (#2227004)

Note that by using a technique known as escape analysis, a virtual machine like the JVM can detect that the lifetime of an object is such that it doesn't leave the context of a particular method and then stack-allocate the object implicitly. That may seem like a limited optimization, but when you combine it with method inlining it gets a lot more useful. I believe the optimization is turned off by default in the Sun/Oracle JVM but can be enabled via the -XX:+DoEscapeAnalysis option. For programs that allocate large numbers of short-lived objects, it can make a significant performance difference.

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by whakojacko on Wednesday February 16, 2011 @01:03PM (#2227448)

Note: If you use scala, escape analysis can be particularly helpful. The "pimp my library" pattern for extending classes involves creating wrapper objects, and these can often be optimized away. http://www.decodified.com/scala/2010/08/27/scala-rich-wrappi... has more details

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by repsilat on Wednesday February 16, 2011 @07:43PM (#2229108)

Often that allocation should be free - when you do a "proper" function call you'll be increasing that pointer already, and the total size of stack-bound objects in many functions can be determined at compile time.

(Erm... I think. Need to read more...)

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by stcredzero on Wednesday February 16, 2011 @10:31AM (#2226710)

Exactly. What a lot of dynamic VM languages provide are very clean semantics and the ability to prototype very quickly. Competently tuned GC with a modern VM will get you beyond the ability of a bad or mediocre C coder, calendar-time faster, though at the price of more machine resource use.

I'm waiting for technology that makes this trade-off obsolete. One should be able to transition from fast prototyping to solid and optimal production code -- incrementally and without great pain. We as an industry are just about ready for this.

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by JoeAltmaier on Wednesday February 16, 2011 @11:03AM (#2226899)

I'm lost - what does "competently tuned GC" mean? There is some way to get the GC to NOT ever run? not take forever? What?

And even if you contrive your app to use memory very very carefully, with a shared runtime with 100 other apps (e.g. on a server) not everybody is as nice and GC still runs/stalls the system.

[ Parent | on HN ]

Re:In what cases is Java faster than C++? by stcredzero on Wednesday February 16, 2011 @11:19AM (#2226965)

I'm lost - what does "competently tuned GC" mean?

You can easily get generational GC to be an order of magnitude slower than it should be by changing just one or two settings.

There is some way to get the GC to NOT ever run?

Yes, this actually came up at Smalltalk Solutions many years ago. One presenter was using Squeak as an advanced debugger at a company producing a FPS game. If all your functionality happens between frames, you can rig it so you never GC. You just throw away all of your memory outside of "perm" space every time.

With VisualWorks Smalltalk, you can change the settings so that the bulk of your GC work happens using incremental GC. It's not uncommon to get to the point where GC never takes up more than a few milliseconds. That's plenty good for most people. Admittedly that's not so good if your "light" request load is well over 1000 transactions per server per second.

And even if you contrive your app to use memory very very carefully, with a shared runtime with 100 other apps (e.g. on a server) not everybody is as nice and GC still runs/stalls the system.

When you need enough virtual hosts to be running 100 server processes -- that's likely when you need to be transitioning out of "rapid prototyping" mode and onto processes with just a little more rigor.

What I'm advocating is a language where both the rapid prototyping and running optimized mature code efficiently is possible. Not only possible, but easy to transition between.

[ Parent | on HN ]