On Thu, 12 May 2022 12:14:49 GMT, Ludovic Henry wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do i
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
On Wed, 11 May 2022 19:13:55 GMT, Paul Sandoz wrote:
>> Ludovic Henry has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 18 commits:
>>
>> - Fix overlapping registers
>> - Actually fix h when hash
On Tue, 8 Mar 2022 17:07:34 GMT, Claes Redestad wrote:
>>> Can we change the optimizer so that the strength reduction happens only
>>> after all transformations have settled? Carelessly changing a
>>> multiplication to a shift as today may hurt a lot of potential
>>> optimisations. Thanks.
>>
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
On Tue, 5 Apr 2022 15:40:29 GMT, Ludovic Henry wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do i
r
> example), and hashing String represents a large part of our CPU usage. It's
> very unlikely that we are the only one as String.hashCode is such a core
> feature of the JVM-based languages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to
On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do i
On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do it through an enhancement to
On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do it through an enhancement to
anguages with its use in HashMap for example.
> Having even only a 2x speedup would allow us to save thousands of CPU cores
> per month and improve correspondingly the energy/carbon impact.
>
> [1]
> https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18
On Fri, 4 Mar 2022 17:01:05 GMT, Roger Riggs wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do it through an enhancement to
>>
Despite the hash value being cached for Strings, computing the hash still
represents a significant CPU usage for applications handling lots of text.
Even though it would be generally better to do it through an enhancement to the
autovectorizer, the complexity of doing it by hand is trivial and
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
Hi Andrew, Vladimir,
> It's too early for that: changes are supposed to bake in JDK head for
> a while. Also, since it's an enhancement rather than a bug fix we'd
> need to have the discussion. I would say it's marginal whether
> something like this should be back ported.
> Usually we backport
Hello,
I would like to backport the newly added MD5 Intrinsic to JDK 11. The change is
contained, limiting the chance of a regression, and provides a great speedup on
a common pattern. This change also contains the follow-up fix by Vladimir
Kozlov.
As it is the first backport I go through,
Pushed with https://hg.openjdk.java.net/jdk/jdk/rev/b8231f177eaf
Thank you to all involved
Webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.03
> I think you need to set flag to false (to overwrite setting on command line)
> in vm_version_*.cpp files on all other CPUs until they have implementation:
Fixed.
> Also I forgot to ask to update copyright year in files you
Webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.03
Testing: everything passes with hotspot:tier1 and jdk:tier1 in fastdebug on
Linux-x64.
> I would leave this investigation to Intel's Java group. They are expert in
> this area!
Ok, we'll reach out to Intel on our end as well to
Updated webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.02
> Next code in inline_digestBase_implCompressMB should be reversed
> (get_long_*() should be called for long_state):
>
>if (long_state) {
> state = get_state_from_digestBase_object(digestBase_obj);
>} else {
>
: Monday, August 3, 2020 4:59 PM
To: Ludovic Henry ;
hotspot-compiler-...@openjdk.java.net; Vivek Deshpande
Cc: core-libs-dev
Subject: Re: RFR[M]: Adding MD5 Intrinsic on x86-64
Hmm, with that code reversed I now have failure only on Windows:
V [jvm.dll+0x43abb7] report_vm_error+0x117
I've updated [1] with the proper patch.
[1] http://cr.openjdk.java.net/~luhenry/md5-intrinsics/webrev.01/8250902.patch
> And I got crash during JDK build on linux-x64:
>
> # Internal Error (src/hotspot/share/opto/library_call.cpp:5732), pid=18904,
> tid=19012
> # assert(field != __null) failed: undefined field
> #
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug
>
> But it looks like it has more changes (windows_aarch64) then just MD5
> intrinsic.
> I will retest again with removed other changes.
That looks like a mistake with me learning to use Mercurial, sorry about that.
The only patch you need is `8250902: Implement MD5 Intrinsics on x86`, all the
28 matches
Mail list logo
