Will the Eclipse compiler automatically convert multiplication by a power of two into a bit shift, or should I do that manually? Thanks for the help.
+1
A:
I think it is safe to say that any decent java compiler will do such trivial optimizations if they are proven to be beneficial. As usual, the advise is to write things clearly and effectively. If the program proves to be too slow, then profile to find where you spend the most time and then look for optimizations you can do. I think the best way to put this is:
"Before you make it fast, make it work"
This is a clear cut case of premature optimization.
Evan Teran
2009-10-03 21:56:05
re being beneficial, I should hope that the rest of the compiler is not so bad that the 5-cycle latency of a multiplication (as compared to 1 cycle for a shift) on the most moderns of processors isn't noticeable. http://www.agner.org/optimize/instruction_tables.pdf
Pascal Cuoq
2009-10-03 22:01:05
Note, that's latency. Old ARM2s from 1987 could multiple by two in one cycle, IIRC (although you had to get it the right way around).
Tom Hawtin - tackline
2009-10-04 00:28:44
That's a good idea. But in this case (and in any case really), the benefit of using a bit shift instead of multiplication is minor -- unless you're doing a ton of multiplications for some reason -- and readability is barely hurt.
Michael Dickens
2009-10-05 01:01:58
+7
A:
Don't second guess a modern java compiler unless you know exactly what you are doing. This not only applies to simple math like you question, but everything. E.g.: like flow control.
People waaaaay smarter than us have put lots of effort into making it all super fast.
Stu Thompson
2009-10-03 21:57:24
+11
A:
Short answer: No. The source code compiler won't replace a multiplication by two with a bit shift.
Long answer: It won't, because it can't know if a bit shift is faster than a multiplication on the platform the code eventually will be running. So, the question should rather be if a specific VM will replace the multiplication with a bit shift, and it probably will. I experimented a little bit with this to optimize a code block and it's interesting that Sun's Hotspot shows different behaviour here, depending on if the program runs on an AMD or on an Intel CPU (at least with the CPUs I tested). In either case, a multiplication with a power of two is replaced with a bit shift, but for multiplications with a power of two +/- 1 (3, 5, 7, 9, 15, 17, ...), Hotspot will generate a bit shift and an addition or a subtraction for Intel CPUs, while generating a multiplication for AMD CPUs, since the AMD CPU executes a multiplication much faster than the Intel CPU. It's of course possible, that this behaviour differs between different CPU models from each vendor.
If you are interested in knowing what the VM actually is doing, it is quite benefical to get the debug build of jdk7 and enable dumps of the assembler code generated by the Hotspot compiler.
jarnbjo
2009-10-03 22:09:14
+1
A:
In general you cannot outsmart the JVM unless there is something very high level you know that cannot be deduced automatically. This usually means a better algorithm is available than the one which is currently used instead of having to handtweak your source. You can use the jvisualvm profiler available in the latest Java 6 JDK's to investigate your program and see where the bottlenecks are.
For instance, the expense of creating new objects instead of reusing old ones has diminished radically then last 10 years, so you should not take any old advice for tuning your java program without examining if it still holds.
You will, however, find that keeping your program simple and above all - readable - will make it much easier to maintain both for you and for future programmers. Any unneccessary complexity will baffle your future readers, and you will need to say in a comment why it MUST be like that (otherwise they will just refactor it back into its original form :)
Thorbjørn Ravn Andersen
2009-10-04 12:01:37