Java Unsafe Memory Manipulation vs. Java vs. C

Question

are there any benchmarks available for comparing memory access to off heap memory in Java Unsafe vs. Java vs. C regions? For example the Java LZ4 (or L4Z?) compression library stated that their Java port using Unsafe is 66% of the speed of the native C implementation.

Q: Is there anything that can give me a (better) estimate?

I wonder if it is worth to go for a C solution of a certain library if one has Unsafe and what parts should I port. Using off-heap memory or heap memory with large arrays (megabytes) might not be such a big saver. The only thing worth mentioning is that using unsafe I can use what ever granularity I want by reading integers at any offset instead of bytes and so on. This would greatly improve the algorithm for one problem I try to speed up.

Answer 1

Yes. The only thing that can give you a better estimation is a trial, similar to what the author ran, but on the systems and using the programs you intend to use rather than the systems and programs the author intends to use to test.

I would assume the author who "stated that their Java port using Unsafe is 66% of the speed of the native C implementation" has the intention of selling his product using any means possible.

Consider that there is no "native C implementation", currently, nor will there likely ever be because C was designed to be portable. The only thing "native" is machine code, and even that invokes some debate on occasions. There are good C compilers and bad C compilers. Both qualities form "native" machine code. Which one was used in the test?

Once you translate C or Java to machine code or JVM bytecode, it's no longer C or Java. It's machine code or JVM bytecode. This brings me to my next point, which I'll phrase in the form of a question: If a program in C and a program in Java which perform the same task, are both compiled to the same JVM bytecode, which program is faster?

We can't measure speed until we have attribution of speed to instructions, cache misses and all of that. While their code might have been "66% of the speed of the native C implementation" (whatever that means anyway), they could have performed some very skewed optimisations, tailored to their own machine, to obtain those figures.

In summary, the tests the author has performed are only realistic if you intend to run those tests on the authors computer, which isn't necessarily your own software on your own computer.