On Tue, 12 Nov 2024 10:17:45 GMT, Francesco Nigro wrote:
>> @minborg sent me some logs from his machine, and I'm analyzing them now.
>>
>> Basically, I'm trying to see why your Java code is a bit faster than the
>> Loop code.
>>
>>
>>
>> 44.77%c2, level 4
On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg wrote:
>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
>> size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
On Tue, 12 Nov 2024 10:03:50 GMT, Emanuel Peter wrote:
>>> Thanks @minborg for this :) Please remember to add the misprediction count
>>> if you can and avoid the bulk methods by having a `nextMemorySegment()`
>>> benchmark method which make a single fill call site to observe the
>>> different
On Mon, 11 Nov 2024 14:51:06 GMT, Per Minborg wrote:
>> Thanks @minborg for this :) Please remember to add the misprediction count
>> if you can and avoid the bulk methods by having a `nextMemorySegment()`
>> benchmark method which make a single fill call site to observe the different
>> segme
On Mon, 11 Nov 2024 17:23:56 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg 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 six additional
>> c
On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg wrote:
>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
>> size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg wrote:
>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
>> size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
On Mon, 11 Nov 2024 13:59:38 GMT, Francesco Nigro wrote:
> Thanks @minborg for this :) Please remember to add the misprediction count if
> you can and avoid the bulk methods by having a `nextMemorySegment()`
> benchmark method which make a single fill call site to observe the different
> segme
> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
> size of the segments varies.
Per Minborg 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 pul
On Mon, 11 Nov 2024 11:55:27 GMT, Per Minborg wrote:
> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
> size of the segments varies.
Thanks @minborg for this :) Please remember to add the misprediction count if
you can - or just avoid the bulk methods instead i.e.
This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
size of the segments varies.
-
Commit messages:
- Use static arrays
- Revert changes from other branch
- Add benchmark
- Add benchmarks
Changes: https://git.openjdk.org/jdk/pull/22010/files
Webrev: ht
11 matches
Mail list logo
