-
Notifications
You must be signed in to change notification settings - Fork 25.8k
Add RecyclerBytesStreamOutput writeVInt benchmark #140490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
| // throughput is more representable metric, it amortizes pages recycling code path and reduces benchmark error | ||
| @BenchmarkMode(Mode.Throughput) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my education, what is the difference here? Is it more than just turning the fraction over so it reports the average of operations-per-unit-time vs time-per-unit operation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it's "just" turning fraction over. https://javadoc.io/doc/org.openjdk.jmh/jmh-core/1.29/org/openjdk/jmh/annotations/Mode.html#Throughput.
public static final Throughput
Throughput: operations per unit of time.
Runs by continuously calling Benchmark methods, counting the total throughput over all worker threads. This mode is time-based, and it will run until the iteration time expires.
public static final AverageTime
Average time: average time per per operation.
Runs by continuously calling Benchmark methods, counting the average time to call over all worker threads. This is the inverse of Throughput, but with different aggregation policy. This mode is time-based, and it will run until the iteration time expires.
|
|
||
| // must not be final - avoid constant fold | ||
| // see https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_10_ConstantFold.java | ||
| private int vint1 = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to be fixed or could it be any value from 1 to 127? Should be the same code anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be any from 1 to 127. As long it's not final JMH should be able properly blackhole this property.
| private int vint2 = vint1 << 8; | ||
| private int vint3 = vint2 << 8; | ||
| private int vint4 = vint3 << 8; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vint shifts by 7 bits, not 8, and there's a 5-byte case to consider too (either very large or negative)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I keep forgetting
A different view on
RecyclerBytesStreamOutputwrite benchmark. Existing RecyclerBytesStreamOutputBenchmark measures complex randomized input covering multiple paths. I think there is value in measuring individual hot-paths with simple inputs, especially in case ofVIntthere is an optimization for 1-byte int.Differences from
RecyclerBytesStreamOutputBenchmark:RecyclerBytesStreamOutputhas page recycling amortized cost that impacts individual writes. Throughput-mode smoothes these spikes.RecyclerBytesStreamOutput. I use constant values with blackholes.Currently covers only VInt's but easy to extend for other methods.
Example run