search

ashkrit / blog

Java Performance
http://ashkrit.blogspot.com
83 stars 53 forks source link

Fixed benchmark to use all intermediate results(byte,int,long) to avoid ... #3

Closed bourgesl closed 10 years ago

bourgesl commented 10 years ago

...jvm dead code elimination

Optimized Heap test to cache values[index] and work on fields directly instead of calling getter/setter methods (more comparable data access)

added results

ashkrit commented 10 years ago

Juts had look at your result. Read time of heap has dropped.

Before: [2] HeapAllocatedObject - [Write 365.953245 ms , Read 34.60215 ms ], Op/Sec(Millions)[ Write 136 , Read 1444 ] [3] HeapAllocatedObject - [Write 365.848703 ms , Read 34.892261 ms ], Op/Sec(Millions)[ Write 136 , Read 1432 ] [4] HeapAllocatedObject - [Write 365.916296 ms , Read 35.123902 ms ], Op/Sec(Millions)[ Write 136 , Read 1423 ] [5] HeapAllocatedObject - [Write 368.515522 ms , Read 34.922363 ms ], Op/Sec(Millions)[ Write 135 , Read 1431 ] [6] HeapAllocatedObject - [Write 375.890758 ms , Read 34.901393 ms ], Op/Sec(Millions)[ Write 133 , Read 1432 ]

After change

[ 4] HeapAllocatedObject - [Write 371.410848 ms , Read 254.838899 ms ], Op/Sec(Millions)[ Write 134 , Read 196 ]: 50000000 965673536 [ 5] HeapAllocatedObject - [Write 387.390524 ms , Read 258.070131 ms ], Op/Sec(Millions)[ Write 129 , Read 193 ]: 50000000 965673536 [ 6] HeapAllocatedObject - [Write 370.643204 ms , Read 255.816964 ms ], Op/Sec(Millions)[ Write 134 , Read 195 ]: 50000000 965673536 [ 7] HeapAllocatedObject - [Write 382.227111 ms , Read 252.999659 ms ], Op/Sec(Millions)[ Write 130 , Read 197 ]: 50000000 965673536 [ 8] HeapAllocatedObject - [Write 374.282464 ms , Read 252.58534 ms ], Op/Sec(Millions)[ Write 133 , Read 197 ]: 50000000 965673536 [ 9] HeapAllocatedObject - [Write 385.28999 ms , Read 256.010758 ms ], Op/Sec(Millions)[ Write 129 , Read

Did you managed to profile the code to see why there is big drop in heap object allocation code ? Direct memory one now looks fair after your change , which is good.

bourgesl commented 10 years ago

As I explained, your benchmark was unfair = read values were not consumed so the JVM / hotspot can eliminate dead code ...

Look at the first 3 runs: +[0] HeapAllocatedObject - [Write 384.915928 ms , Read 264.488693 ms ], Op/Sec(Millions)[ Write 129 , Read 189 ] +[1] HeapAllocatedObject - [Write 374.290384 ms , Read 251.410685 ms ], Op/Sec(Millions)[ Write 133 , Read 198 ] +[2] HeapAllocatedObject - [Write 365.953245 ms , Read 34.60215 ms ], Op/Sec(Millions)[ Write 136 , Read 1444 ]

Like magic, the third run shows a very big performance boost for read ops: Read 251.410685 ms => Read 34.60215 ms Read 198 => Read 1444 whereas the write ops stay the same.

I call that hotspot is magic ! see https://code.google.com/p/caliper/wiki/JavaMicrobenchmarkReviewCriteria " 2. Could a compiler possibly optimize your benchmark away?

If a JIT compiler can detect that your code doesn't actually depend on the "right answer" coming from the code under test, it might perform optimizations that will prevent some or all of the code you meant to test from even executing. Make sure that your benchmark method returns a value -- it can be of any type you want -- that is dependent on actual correct execution of the method. "

ashkrit commented 10 years ago

Yes you are right , hotspot has done magic. I should start using JMH for my examples , it will give better results.