On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 21:52:22 GMT, Volodymyr Paprotski wrote:
> numAdds is now again pretty much a 'private' concept to the IntegerPolynomial
> class, so figure it was fine before, it should be fine now?
I did not mean it for this changes but as general improvement of code in other
RFE. But it
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 18:51:33 GMT, Volodymyr Paprotski wrote:
> Actually, the other way around; reducePositive is now an unconditionally
> executed for both pure java and the intrinsic paths.
Looking on `MontgomeryIntegerPolynomialP256.java` the code in `multImpl() +
reducePositive()` is simil
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Wed, 12 Jun 2024 20:04:40 GMT, Ferenc Rakoczi wrote:
> tier1,2,3 mach5 tests all passed.
Thank you for testing.
-
PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2163863932
On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi wrote:
>> This PR removes some unnecessary conversions between byte arrays and long
>> arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Tue, 11 Jun 2024 09:55:11 GMT, Ferenc Rakoczi wrote:
>> This PR removes some unnecessary conversions between byte arrays and long
>> arrays during SHA3 digest computations.
>
> Some microbenchmark data (the percentages are improvements in ops/sec):
> Benchmark
On Tue, 11 Jun 2024 17:30:37 GMT, Ferenc Rakoczi wrote:
>> Thank you for explanation.
>>
>> An other question. Is any other use of `longBuf` array after
>> `implCompress0()` call which load values from it? Because Intrinsic code
>> will not update it.
>
> There is no other use.. That array is
On Tue, 11 Jun 2024 08:03:48 GMT, Ferenc Rakoczi wrote:
>> Well, the intrinsic function treats the input and state as long arrays
>> anyways, and so it only works on little endian architectures, where the
>> conversion is a no-op. There is no additional array copy, this b2lLittle()
>> call use
On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi wrote:
> This PR removes some unnecessary conversions between byte arrays and long
> arrays during SHA3 digest computations.
src/java.base/share/classes/sun/security/provider/SHA3.java line 100:
> 98: b2lLittle(b, ofs, longBuf, 0, blockS
On Mon, 10 Jun 2024 17:29:31 GMT, Ferenc Rakoczi wrote:
>> src/java.base/share/classes/sun/security/provider/SHA3.java line 98:
>>
>>> 96: @IntrinsicCandidate
>>> 97: private void implCompress0(byte[] b, int ofs) {
>>> 98: b2lLittle(b, ofs, longBuf, 0, blockSize);
>>
>> What abo
On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi wrote:
> This PR removes some unnecessary conversions between byte arrays and long
> arrays during SHA3 digest computations.
src/java.base/share/classes/sun/security/provider/SHA3.java line 98:
> 96: @IntrinsicCandidate
> 97: private voi
On Thu, 6 Jul 2023 13:06:30 GMT, Cesar Soares Lucas wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmarks
On Fri, 21 Apr 2023 15:08:21 GMT, Cesar Soares Lucas
wrote:
> Since only the tests added in this PR are failing due to that problem do you
> think I should create a separate PR to fix the Regex or just include the fix
> in this PR?
Create separate PR and fix it first. This PR still need revie
On Mon, 17 Apr 2023 16:17:30 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Mon, 17 Apr 2023 16:17:30 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Mon, 17 Apr 2023 16:17:30 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Fri, 14 Apr 2023 20:54:45 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Fri, 14 Apr 2023 20:54:45 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Wed, 5 Apr 2023 16:31:20 GMT, Cesar Soares Lucas wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmarks
On Fri, 24 Mar 2023 23:57:07 GMT, Cesar Soares Lucas
wrote:
>> src/hotspot/share/opto/callnode.hpp line 511:
>>
>>> 509: // by a SafePoint; 2) A scalar replaced object is participating in an
>>> allocation
>>> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The
>>> schematics of
On Fri, 24 Mar 2023 23:24:47 GMT, Cesar Soares Lucas
wrote:
>> src/hotspot/share/opto/macro.hpp line 196:
>>
>>> 194: Node* size_in_bytes);
>>> 195:
>>> 196: static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn,
>>> ArrayCopyNode* ac, intptr_t offset,
On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas
wrote:
>> Can I please get reviews for this PR?
>>
>> The most common and frequent use of NonEscaping Phis merging object
>> allocations is for debugging information. The two graphs below show numbers
>> for Renaissance and DaCapo benchmar
On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk wrote:
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare
On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote:
> Updated man pages from markdown sources.
I am not sure some words changes are correct?
May be we should cleanup and update all these man pages as separate issue. And
apply only `-Xcomp` changes.
@iklam
you recently pushed changes https:/
30 matches
Mail list logo
