On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos wrote:
>> By avoiding a bit shift operation for the latin1 fast-path test, we can
>> speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code
>> points.
>>
>> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can
On Sat, 18 Mar 2023 17:06:52 GMT, jmehrens wrote:
>> We could, but benchmarks show no performance improvements over the current
>> PR. I think the current code is perhaps slightly more readable.
>
> Does non-short-circuit logical AND operator perform similar to baseline? In
> this very
On Wed, 15 Mar 2023 14:56:28 GMT, Eirik Bjorsnos wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update StringLatin1.canEncode to sync with same test in CharacterData.of
>
> Just for fun, I tried with a
On Wed, 15 Mar 2023 14:57:43 GMT, Quan Anh Mai wrote:
>>> The StringLatin1.canEncode regression disappears.
>>
>> I mixed things up so StringLatin1.canEncode was benchmarked without the
>> updated code.
>>
>> Here are updated benchmark results:
>>
>>
>> Baseline:
>>
>>
>> Benchmark
On Wed, 15 Mar 2023 14:56:28 GMT, Eirik Bjorsnos wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update StringLatin1.canEncode to sync with same test in CharacterData.of
>
> Just for fun, I tried with a
On Wed, 15 Mar 2023 14:23:35 GMT, Eirik Bjorsnos wrote:
>> Many thanks to have tried, yep, I was curious indeed re the
>> "StringLatin1.canEncode regression" case.
>> I would still modify the benchmark to use inputs (I know that will make it
>> memory bound sadly, due to reading inputs - but
On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos wrote:
>> By avoiding a bit shift operation for the latin1 fast-path test, we can
>> speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code
>> points.
>>
>> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can
On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos wrote:
>> By avoiding a bit shift operation for the latin1 fast-path test, we can
>> speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code
>> points.
>>
>> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can
On Wed, 15 Mar 2023 12:00:59 GMT, Claes Redestad wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update StringLatin1.canEncode to sync with same test in CharacterData.of
>
> Nice one!
@cl4es Do you agree that
On Wed, 15 Mar 2023 13:50:44 GMT, Francesco Nigro wrote:
>> I created a randomized version of `Characters.isDigit` which tests with code
>> points picked at random such that any category (Latin1, negative, different
>> planes, unassiged) are equally probable.
>>
>> Baseline:
>>
>>
>>
> By avoiding a bit shift operation for the latin1 fast-path test, we can speed
> up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>
> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace
> this with `ch >= 0 && ch <= 0xFF` for a noticable
On Wed, 15 Mar 2023 13:42:22 GMT, Eirik Bjorsnos wrote:
>> Can you check what happen adding much more inputs to the dataset including
>> non-latin chars as well and use `-prof perfnorm` to check what `perf` report
>> re branches/branch-misses?
>>
>> You can use `SplittableRandom` to
On Wed, 15 Mar 2023 12:37:24 GMT, Francesco Nigro wrote:
>>> It seems reasonable to keep these two in sync, yes. (`CharacterData.of`
>>> could even call into `StringLatin1.canEncode`, unless that's cause for some
>>> performance anomaly)
>>
>> If I update `StringLatin1.canEncode` and call
On Wed, 15 Mar 2023 12:28:05 GMT, Eirik Bjorsnos wrote:
>>> `if (ch && 0xFF00 == 0) {`
>>
>> This seems to perform similar to baseline:
>>
>>
>> Benchmark (codePoint) Mode Cnt Score Error Units
>> Characters.isDigit 48 avgt 15 0.890 ± 0.025 ns/op
>>
On Wed, 15 Mar 2023 12:15:39 GMT, Eirik Bjorsnos wrote:
>> It seems reasonable to keep these two in sync, yes. (`CharacterData.of`
>> could even call into `StringLatin1.canEncode`, unless that's cause for some
>> performance anomaly)
>
>> `if (ch && 0xFF00 == 0) {`
>
> This seems to
On Wed, 15 Mar 2023 12:13:00 GMT, Claes Redestad wrote:
>> Btw, I think we can do the same for `StringLatin1.canEncode()`
>
> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could
> even call into `StringLatin1.canEncode`, unless that's cause for some
> performance
On Wed, 15 Mar 2023 12:07:12 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/lang/CharacterData.java line 72:
>>
>>> 70:
>>> 71: static final CharacterData of(int ch) {
>>> 72: if (ch >= 0 && ch <= 0xFF) { // fast-path
>>
>> Maybereducing to a single branch
On Wed, 15 Mar 2023 11:58:14 GMT, Claes Redestad wrote:
>> By avoiding a bit shift operation for the latin1 fast-path test, we can
>> speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code
>> points.
>>
>> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can
On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos wrote:
> By avoiding a bit shift operation for the latin1 fast-path test, we can speed
> up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>
> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace
On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos wrote:
> By avoiding a bit shift operation for the latin1 fast-path test, we can speed
> up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>
> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace
By avoiding a bit shift operation for the latin1 fast-path test, we can speed
up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace
this with `ch >= 0 && ch <= 0xFF` for a noticable performance
21 matches
Mail list logo
