> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically, the impact of such changes on the performance of sharp
> memory access operations.
>
> This issue proposes to update the benchmark in the following ways to meet the
> aforementioned use-case:
>
> 1. Remove allocation from the individual benchmarks - it just creates noise.
> 2. Consolidate per-thread shared heap and direct buffers.
> 3. All scenarios now use absolute memory access operations - so no state of
> the shared buffers is considered.
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box.
> 5. There seems to have been an existing bug in the test where the size
> parameter was not always considered - this is now fixed.
Chris Hegarty has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains ten additional
commits since the last revision:
- Update copyright year range and tailing whitespace
- Merge branch 'master' into bb-bench
- Template generation of carrier specific micro-benchmarks.
* Benchmarks are now split out into carrier specific source files
* All variants and views are covered
* Test scenario naming is idiomatic
Even with the split by carrier, regex expressions can be used to easily run
subsets the benchmarks. E.g. test all memory operations related to Short with
read-only buffers:
$ java -jar benchmarks.jar
"org.openjdk.bench.java.nio..*Buffers.testDirect.*Short.*" -l
Benchmarks:
org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortRO
org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortSwapRO
org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewRO
org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewSwapRO
org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewRO
org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewSwapRO
- Merge branch 'master' into bb-bench
- Add explicitly allocated heap carrier buffer tests
- Replace Single with Loop
- whitespace
- Add additional carrier views and endianness variants.
A large number of variants are now covered. The individual benchmarks
conform to the following convention:
test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)?
This allows to easily run a subset of particular interest. For example:
Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*"
Char only :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*"
Bulk only :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*"
Put with Int or Long carrier :-
test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?"
Running all variants together is likely not all that useful, since there
will be a lot of data.
The param sizes are changed so as to better allow for wider carrier views.
There are a lot of individual benchmark methods, but their implementation is
trivial, and largely mechanical.
Question: where do folk stand on having a `main` method in a benchmark - as
a standalone-run sanity? I found this useful to assert the validity of the
benchmark code. It can be commented out if it could somehow affect the
benchmark runs.
( I omitted read-only views, since they less interesting, and we already
have a lot of variants )
- Initial changes
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1430/files
- new: https://git.openjdk.java.net/jdk/pull/1430/files/a8e81a84..9e8014cf
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=05
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=04-05
Stats: 123643 lines in 3239 files changed: 61246 ins; 39707 del; 22690 mod
Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430
PR: https://git.openjdk.java.net/jdk/pull/1430
