On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The com
On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The com
On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The com
Hi all,
This pull request contains a backport of commit
[f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
Thanks!
-
Commit messages:
- Backport f101e153cee68750fcf1f12da10e298
On Tue, 25 Jun 2024 17:31:09 GMT, Ferenc Rakoczi wrote:
>> Hi @vpaprotsk,
>> @ferakocz is going to take a look at the change. When he says it's ok, I'll
>> approve the PR.
>
> @ascarpino please approve this change.
Thanks @ferakocz @ascarpino
-
PR Comment: https://git.openjdk.or
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 19:21:37 GMT, Anthony Scarpino
wrote:
>>> What causes regression in P256 "(~-8-14%)"? From what I see, you
>>> re-arranged code to not execute some code ("reducePositive()") when it is
>>> not needed. How this affects P256?
>>
>> Actually, the other way around; reducePosit
On Mon, 24 Jun 2024 14:48:43 GMT, Ferenc Rakoczi wrote:
>> @ferakocz just tagging you as reminder of (the many) items in your queue :)
>> Thanks!
>
>> @ferakocz just tagging you as reminder of (the many) items in your queue :)
>> Thanks!
>
> Sorry, I was out of office last week. I will take a
On Thu, 20 Jun 2024 18:32:14 GMT, Volodymyr Paprotski wrote:
> @ferakocz just tagging you as reminder of (the many) items in your queue :)
> Thanks!
Sorry, I was out of office last week. I will take a deeper look at the changes
tomorrow, but I have a question based on my first look at it: Do y
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 Tue, 18 Jun 2024 15:10:37 GMT, Vladimir Kozlov wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> comment from Sandhya
>
> @TobiHartmann ran our testing and it passed.
Thanks @vnkozlov @TobiHartmann !
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 23:29:18 GMT, Vladimir Kozlov wrote:
> Talking about future improvements. Is it possible to optimize reduction code
> by converting it to intrinsic too? Or code generated by C2 is good enough?
I had some experiments to try where I was using virtual methods to add
optimizati
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 21:21:01 GMT, Vladimir Kozlov wrote:
> Let me know that I got it right:
>
> * The reduction operation was optional and P256 benefitted by not executing
> it.
> * Previous `mult()` **Java** code always retuned 0 because it executes
> reduction so callers do not need to do 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 19:22:01 GMT, Vladimir Kozlov wrote:
> Looking on `MontgomeryIntegerPolynomialP256.java` the code in `multImpl() +
> reducePositive()` is similar to original `mult()` except new additional code
> at the end of `multImpl()`.
Yep, I split the original java mult() into multIm
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 18:51:33 GMT, Volodymyr Paprotski wrote:
>> What causes regression in P256 "(~-8-14%)"?
>> From what I see, you re-arranged code to not execute some code
>> ("reducePositive()") when it is not needed. How this affects P256?
>
>> What causes regression in P256 "(~-8-14%)"? Fro
On Mon, 17 Jun 2024 18:12:16 GMT, Vladimir Kozlov wrote:
> What causes regression in P256 "(~-8-14%)"? From what I see, you re-arranged
> code to not execute some code ("reducePositive()") when it is not needed. How
> this affects P256?
Actually, the other way around; reducePositive is now an
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 Fri, 14 Jun 2024 23:39:54 GMT, Sandhya Viswanathan
wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve non-intrinsic p256 performance
>
> src/hotspot/share/opto/runtime.cpp line 1417:
>
>> 1415: /
> 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 (e.g. this avoids extra reductions when
> mult() result is fed into
On Fri, 14 Jun 2024 22:01:44 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 (
> 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 (e.g. this avoids extra reductions when
> mult() result is fed into
On Fri, 14 Jun 2024 20:23:04 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 (i.e.
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 (i.e. this avoids extra reductions when mult()
result is fed into addition). T
31 matches
Mail list logo
