3 ms·

The answer is that if you're prepared to off piste, mainly by using sun.misc.Unsafe, you can get within a gnat's whisker of C++. For example: http://mechanical

The answer is that if you're prepared to off piste, mainly by using sun.misc.Unsafe, you can get within a gnat's whisker of C++. For example: http://mechanical-sympathy.blogspot.co.uk/2012/07/native-cc-like-performance-for-java.html http://mechanical-sympathy.blogspot.co.uk/2012/07/native-cc-... and http://mechanical-sympathy.blogspot.co.uk/2012/10/compact-off-heap-structurestuples-in.html http://mechanical-sympathy.blogspot.co.uk/2012/10/compact-of... It's interesting to look at what Java lacks to achieve this level of performance with less pain. The main issue, I believe, is control over memory layout. For example, avoiding boxing in arrays of objects. Avoiding GC is also an issue. I think Rust is interesting as it allows the programmer to talk about these things without going "outside" the language like one must in Java, while still retaining a modern programming style.

beagle3 13y ago
That's a good answer, but it isn't really Java - it's assembly in disguise. You lose basically everything Java can give you when you do that. And I don't know since when it actually works well - as of 2011 with Java 1.6, I had similar code that used memory mapped buffers, and crawled like a snail because (apparently, I couldn't directly verify) the optimizer would not inline the memory mapped access, meaning that every array access cost ~10 times as much as it should.
- noelwelsh 13y ago
  I agree it isn't great, but it works, and if you need that extra performance in a small part of your application it can allow you to stay on the JVM. I'd rather do that than write everything in C (YMMV.) The blog posts I linked compare performance to nio ByteBuffers, and show improvement for Unsafe over ByteBuffer. That might be relevant to your case.
  - beagle3 13y ago
    I rewrote in C, and got 10x speedup and x4 less memory. So, it's no longer relevant :)
- kasey_junk 13y ago
  You can say that about every technique that goes 1 level lower in abstraction. Personally, these techniques allow me to write the vast majority of my code in a high level JVM language (Scala in my case) and optimize the very small percentage of my code that needs to be this latency sensitive. Because I can get so close to native performance in that highly specific case, the idea of using C++ hardly ever comes up. If I need faster than this, C++ is probably not fast enough either and I need to look at "closer to iron" solutions. I for one appreciate that. But then again, I'd much rather program in C than C++. As far as claims like Java is 3x slower than C++, it is nearly impossible to quantify these things directly. For any given benchmark you will be able to find people who complain about the code in the benchmark not being optimized enough. Suffice it to say that there are some things Java is faster at and some C++ is and their are techniques in both that allow them to achieve near parity.
anonymous 13y ago
If you're prepared to do all that, why not write the hot code in C and use JNI?
- noelwelsh 13y ago
  If you go C/JNI you: 1. Have added an extra step to your build process 2. Pay the cost of doing JNI calls, which I believe is quite high. Look, I'm not saying doing this Unsafe stuff is rainbows and unicorns. It's a hack, but it's a hack that is extremely useful in a few niche applications.
- kasey_junk 13y ago
  JNI calls carry a very significant latency overhead. If the code you are trying to optimize would have to call the JNI methods repeatedly you very quickly lose any speed advantage you had from writing it in C. If on the other hand you only need to call the JNI a few times it probably does make sense to go the JNI route. Another common option (especially in server style programs) is to have 2 daemons, one in C (or C++) doing a very specialized role and communicating with a JVM daemon via memory mapped files.
qwerta 13y ago
Have look at my project: MapDB. It provides java collections on top of raw byte buffers or files.
- noelwelsh 13y ago
  Nice work! Never heard of this before. Looks like it might be a useful replacement for Redis in some cases.

beagle3 13y ago

That's a good answer, but it isn't really Java - it's assembly in disguise. You lose basically everything Java can give you when you do that. And I don't know since when it actually works well - as of 2011 with Java 1.6, I had similar code that used memory mapped buffers, and crawled like a snail because (apparently, I couldn't directly verify) the optimizer would not inline the memory mapped access, meaning that every array access cost ~10 times as much as it should.

noelwelsh 13y ago
I agree it isn't great, but it works, and if you need that extra performance in a small part of your application it can allow you to stay on the JVM. I'd rather do that than write everything in C (YMMV.) The blog posts I linked compare performance to nio ByteBuffers, and show improvement for Unsafe over ByteBuffer. That might be relevant to your case.
- beagle3 13y ago
  I rewrote in C, and got 10x speedup and x4 less memory. So, it's no longer relevant :)
kasey_junk 13y ago
You can say that about every technique that goes 1 level lower in abstraction. Personally, these techniques allow me to write the vast majority of my code in a high level JVM language (Scala in my case) and optimize the very small percentage of my code that needs to be this latency sensitive. Because I can get so close to native performance in that highly specific case, the idea of using C++ hardly ever comes up. If I need faster than this, C++ is probably not fast enough either and I need to look at "closer to iron" solutions. I for one appreciate that. But then again, I'd much rather program in C than C++. As far as claims like Java is 3x slower than C++, it is nearly impossible to quantify these things directly. For any given benchmark you will be able to find people who complain about the code in the benchmark not being optimized enough. Suffice it to say that there are some things Java is faster at and some C++ is and their are techniques in both that allow them to achieve near parity.

anonymous 13y ago

If you're prepared to do all that, why not write the hot code in C and use JNI?

noelwelsh 13y ago
If you go C/JNI you: 1. Have added an extra step to your build process 2. Pay the cost of doing JNI calls, which I believe is quite high. Look, I'm not saying doing this Unsafe stuff is rainbows and unicorns. It's a hack, but it's a hack that is extremely useful in a few niche applications.
kasey_junk 13y ago
JNI calls carry a very significant latency overhead. If the code you are trying to optimize would have to call the JNI methods repeatedly you very quickly lose any speed advantage you had from writing it in C. If on the other hand you only need to call the JNI a few times it probably does make sense to go the JNI route. Another common option (especially in server style programs) is to have 2 daemons, one in C (or C++) doing a very specialized role and communicating with a JVM daemon via memory mapped files.

qwerta 13y ago

Have look at my project: MapDB. It provides java collections on top of raw byte buffers or files.

noelwelsh 13y ago
Nice work! Never heard of this before. Looks like it might be a useful replacement for Redis in some cases.