RFR: 8333867: SHA3 performance can be improved [v2]
Ferenc Rakoczi
duke at openjdk.org
Fri Jun 14 09:50:14 UTC 2024
On Thu, 13 Jun 2024 20:25:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:
>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix clone(), accept review suggestions.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 73:
>
>> 71: // The following array is allocated to size WIDTH bytes, but we only
>> 72: // ever use the first blockSize bytes it (for bytes <-> long conversions)
>> 73: private byte[] byteState = new byte[WIDTH];
>
> Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?
This is interesting: if I use WIDTH (or in blockSize) long arrays in the local level, the performance drops a few per cents. Even more when I only declare the local array in the block in which it is used. However, since we really only need 8 bytes, if I allocate that at the beginning of the function, I don't see that performance drop. So I rewrote the output loop in the function and got rid of the class level declaration.
> src/java.base/share/classes/sun/security/provider/SHA3.java line 121:
>
>> 119: }
>> 120: implCompress(buffer, 0);
>> 121: int availableBytes = buffer.length;
>
> change to `blockSize` as in `implCompress0(...)`?
Yes, thanks, I wanted to, just forgot.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572500
PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572413
More information about the security-dev
mailing list