[
https://issues.apache.org/jira/browse/HBASE-20716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524578#comment-16524578
]
Sahil Aggarwal commented on HBASE-20716:
----------------------------------------
Here's small benchmark for Bytes.toShort
@Benchmark
public void testGetShortCheckAndDispatch() {
if (UNSAFE_UNALIGNED) {
UnsafeAccess.toShort(bytes, 0);
} else {
getShort(bytes, 0);
}
}
@Benchmark
public void testGetShortDispatch() {
UnsafeAccess.toShort(bytes, 0);
}
private short getShort(byte[] bytes, int offset) {
short n = 0;
n = (short) ((n ^ bytes[offset]) & 0xFF);
n = (short) (n << 8);
n = (short) ((n ^ bytes[offset+1]) & 0xFF);
return n;
}
Benchmark
Mode Cnt Score Error Units
UnsafeAccessBenchmark.testGetShortCheckAndDispatch thrpt 4
2195811074.302 ops/s
UnsafeAccessBenchmark.testGetShortDispatch thrpt 4
2196669275.206 ops/s
Was curious on affect on inlining too, disabling the inlining on
UnsafeAccess.toShort:
Benchmark
Mode Cnt Score Error Units
UnsafeAccessBenchmark.testGetShortCheckAndDispatch thrpt 2
474847927.534 ops/s
UnsafeAccessBenchmark.testGetShortDispatch thrpt 2
486521295.364 ops/s
~ 78% reduction on disabling inlining.
And, size difference b/w these methods:
org.sample.UnsafeAccessBenchmark::testGetShortCheckAndDispatch (27 bytes)
force inline by CompileOracle
org.sample.UnsafeAccessBenchmark::testGetShortDispatch (9 bytes) force inline
by CompileOracle
> Unsafe access cleanup
> ---------------------
>
> Key: HBASE-20716
> URL: https://issues.apache.org/jira/browse/HBASE-20716
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: stack
> Priority: Critical
> Labels: beginner
> Attachments: Screen Shot 2018-06-26 at 11.37.49 AM.png
>
>
> We have two means of getting at unsafe; UnsafeAccess and then internal to the
> Bytes class. They are effectively doing the same thing. We should have one
> avenue to Unsafe only.
> Many of our paths to Unsafe via UnsafeAccess traverse flags to check if
> access is available, if it is aligned and the order in which words are
> written on the machine. Each check costs -- especially if done millions of
> times a second -- and on occasion adds bloat in hot code paths. The unsafe
> access inside Bytes checks on startup what the machine is capable off and
> then does a static assign of the appropriate class-to-use from there on out.
> UnsafeAccess does not do this running the checks everytime. Would be good to
> have the Bytes behavior pervasive.
> The benefit of one access to Unsafe only is plain. The benefits we gain
> removing checks will be harder to measure though should be plain when you
> disassemble a hot-path; in a (very) rare case, the saved byte codes could be
> the difference between inlining or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
