On 22 June 2011 16:24, Oliver Jowett <oliver@opencloud.com> wrote:
> I've seen enough weird performance behavior from the JIT in the past
> to be inherently suspicious of anything that claims to be a speedup
> without numbers to back it up.
> If we have a benchmark to work from, then I'm sure there's even more
> performance we can squeeze out of it.
FWIW here's a quick microbenchmark.
Andreas' patch is about 5x faster than the current code.
A version using a one-dimensional lookup array is marginally faster again (7%).
$ java -server -version; uname -a; time java -server -classpath . Benchmark 5
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Linux downpour 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
original code, 1000 1161632 iterations in
5018679 us 4.32 us/iteration
2D array lookup, 1000 6025844 iterations in
4948308 us 0.82 us/iteration
1D array lookup, 1000 6361396 iterations in
4996605 us 0.79 us/iteration
original code, 100000 9196 iterations in
5019373 us 545.82 us/iteration
2D array lookup, 100000 57049 iterations in
4999200 us 87.63 us/iteration
1D array lookup, 100000 61162 iterations in
5000197 us 81.75 us/iteration
real 1m55.117s
user 1m55.400s
sys 0m0.210s
(I also tried some variations with induction variables but got no real
speedup and enough weird results to make me think it's confusing the
JIT)
There is also a bug in the original patch that I noticed along the way
(the initialization of HEX_LOOKUP doesn't use lo2/hi2) - fixed in the
benchmark code.
Oliver
