On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Fri, 21 Jul 2023 15:14:23 GMT, Maurizio Cimadamore
wrote:
>> So have you thought of making this low-level classes public so we outside
>> users no longer need to deal with VarHandles?
> I believe this is beyond the scope of this PR.
Sure, I brought this up here but yes, it is not really th
On Fri, 21 Jul 2023 09:43:43 GMT, Uwe Schindler wrote:
>
> So have you thought of making this low-level classes public so we outside
> users no longer need to deal with VarHandles?
>
I believe this is beyond the scope of this PR.
As for what do we do in the JDK, I can see few options:
1. We
On Thu, 20 Jul 2023 21:43:49 GMT, Maurizio Cimadamore
wrote:
>>> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the
>>> performance of ByteBuffer was also poor:
>>
>> I finally see it.
>>
>>
>> Benchmark (polluteProfile) Mode Cnt Score
On Thu, 20 Jul 2023 17:27:58 GMT, Maurizio Cimadamore
wrote:
> Is there any benchmark for DataInput/Output stream that can be used? I mean,
> it would be interesting to understand how these numbers translate when
> running the stuff that is built on top.
I've tried to run the benchmark in tes
On Thu, 20 Jul 2023 16:58:44 GMT, Glavo wrote:
> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the
> performance of ByteBuffer was also poor:
I finally see it.
Benchmark (polluteProfile) Mode Cnt Score Error
Units
LoopOverNonConstantHe
On Thu, 20 Jul 2023 16:47:14 GMT, Maurizio Cimadamore
wrote:
>> On a newer processor/OS (Alder Lake/Ubuntu 22.04) I see a bit more
>> difference:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readBytethrpt5 680397.046 ± 27504.0
On Thu, 20 Jul 2023 16:39:59 GMT, Maurizio Cimadamore
wrote:
>>> Here's with the same parameters as the one you are using:
>>
>> I don't understand why there is such a difference. I have replicated similar
>> results on several other devices:
>>
>> Apple M1:
>>
>> Benchmark
On Thu, 20 Jul 2023 16:39:31 GMT, Glavo wrote:
>> Here's with the same parameters as the one you are using:
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readBytethrpt5 268722.378 ± 5979.787 ops/ms
>> ByteArray.readByteFromBuffer
On Thu, 20 Jul 2023 16:24:09 GMT, Maurizio Cimadamore
wrote:
> Here's with the same parameters as the one you are using:
I don't understand why there is such a difference. I have replicated similar
results on several other devices:
Apple M1:
Benchmark Mode CntSc
On Thu, 20 Jul 2023 16:12:12 GMT, Glavo wrote:
>> I just ran your benchmark above - which is similar as I said to the ones we
>> already have in the JDK. Results:
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readByteavgt 30 3.619 ± 0.051 ns/op
On Thu, 20 Jul 2023 16:01:27 GMT, Maurizio Cimadamore
wrote:
> I don't see 2x slowdown. Which JDK are you using? Which platform?
I tried running the benchmarks with OpenJDK 20.0.1 and my own jdk built from
master and the results were similar. The test platform is based on Ubuntu
23.04, and th
On Thu, 20 Jul 2023 15:55:18 GMT, Glavo wrote:
>>> In this result, ByteBuffer is much slower than VarHandle. Am I doing
>>> something wrong? What conditions are needed to make the performance of
>>> ByteBuffer close to that of Unsafe?
>>
>> These are some benchmarks we have in the JDK:
>>
>>
On Thu, 20 Jul 2023 15:49:10 GMT, Maurizio Cimadamore
wrote:
>>> > it's likely to introduce non-trivial additional overhead
>>>
>>> What do you mean? E.g. where would the overhead come from?
>>
>> You suggested changes stored the ByteBuffer into a field. I measured
>> throughput with JMH, and
On Thu, 20 Jul 2023 15:43:01 GMT, Glavo wrote:
>>> it's likely to introduce non-trivial additional overhead
>>
>> What do you mean? E.g. where would the overhead come from?
>
>> > it's likely to introduce non-trivial additional overhead
>>
>> What do you mean? E.g. where would the overhead come
On Thu, 20 Jul 2023 15:34:33 GMT, Maurizio Cimadamore
wrote:
> > it's likely to introduce non-trivial additional overhead
>
> What do you mean? E.g. where would the overhead come from?
You suggested changes stored the ByteBuffer into a field. I measured throughput
with JMH, and it shows that
On Thu, 20 Jul 2023 15:16:36 GMT, Glavo wrote:
> it's likely to introduce non-trivial additional overhead
What do you mean? E.g. where would the overhead come from?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269643645
On Thu, 20 Jul 2023 14:53:36 GMT, Glavo wrote:
>> @mcimadamore I compared the performance of `ByteBuffer` and `VarHandle`
>> using a JMH benchmark:
>>
>>
>> public class ByteArray {
>>
>> private byte[] array;
>> private ByteBuffer byteBuffer;
>>
>> private static final VarHandle
On Thu, 20 Jul 2023 14:49:48 GMT, Glavo wrote:
>> Also, note that ByteBuffer exposes its backing array (at least if the buffer
>> is not read only) via ByteBuffer::array. This does no copy. So in all the
>> various stream implementations, I believe we can really just use a
>> ByteBuffer instea
On Thu, 20 Jul 2023 14:15:15 GMT, Maurizio Cimadamore
wrote:
>>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>>
>> It's just a bytecode intrinsics, it is only replaced when used in a
>> fluent-chain of StringBuilder/Buffer.
>
> Also, note that ByteBuffer exposes its backing
On Thu, 20 Jul 2023 13:57:04 GMT, Glavo wrote:
>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>
>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>
> It's just a bytecode intrinsics, it is only replaced when used in a
> fluent-chain of StringBuilder/Buffer.
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 20 Jul 2023 13:46:10 GMT, Maurizio Cimadamore
wrote:
> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
It's just a bytecode intrinsics, it is only replaced when used in a
fluent-chain of StringBuilder/Buffer.
-
PR Review Comment: https://git.openjdk.org/jd
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 20 Jul 2023 13:38:14 GMT, Maurizio Cimadamore
wrote:
>>> The Unsafe-based writing will be used by `Integer.toString` and
>>> `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper
>>> be overkill?
>>
>> Integer/Long are very core classes so I assume they can use U
On Thu, 20 Jul 2023 13:34:25 GMT, Alan Bateman wrote:
> in those cases, will creating a ByteBuffer wrapper be overkill?
Perhaps - but do we have any benchmark to back up that claim (or backing up the
fact that Integer.toString would benefit from using ByteArray in the first
place) ? It is like
On Thu, 20 Jul 2023 10:29:25 GMT, Chen Liang wrote:
> The Unsafe-based writing will be used by `Integer.toString` and
> `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper
> be overkill?
Integer/Long are very core classes so I assume they can use Unsafe if needed,
they
On Thu, 20 Jul 2023 09:39:09 GMT, Maurizio Cimadamore
wrote:
>> Actually, a byte buffer is big endian, so some extra code would be required.
>> But maybe that's another helper function:
>>
>>
>> @ForceInline
>> ByteBuffer asBuffer(byte[] array) { return
>> ByteBuffer.wrap(array).order(ByteOr
On Thu, 20 Jul 2023 09:33:15 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/util/ByteArray.java line 54:
>>
>>> 52:
>>> 53: @ForceInline
>>> 54: static long arrayOffset(byte[] array, int typeBytes, int offset) {
>>
>> IMHO, this is the really interesting t
On Thu, 20 Jul 2023 09:25:31 GMT, Maurizio Cimadamore
wrote:
>> Glavo 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 15 additional commits sinc
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
38 matches
Mail list logo
