On Tue, 9 Sep 2025 16:46:10 GMT, Ben Perez wrote:
>> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
>> optimized. In particular, since modulus[2] = 0 several multiplications can
>> be removed. Other multiplications can be replaced by shifts, which also
>> saves ti
> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
> optimized. In particular, since modulus[2] = 0 several multiplications can be
> removed. Other multiplications can be replaced by shifts, which also saves
> time. Preliminary tests indicate an improvement between 5-
On Thu, 21 Aug 2025 23:30:08 GMT, Ben Perez wrote:
>> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
>> optimized. In particular, since modulus[2] = 0 several multiplications can
>> be removed. Other multiplications can be replaced by shifts, which also
>> saves t
On Thu, 21 Aug 2025 23:30:08 GMT, Ben Perez wrote:
>> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
>> optimized. In particular, since modulus[2] = 0 several multiplications can
>> be removed. Other multiplications can be replaced by shifts, which also
>> saves t
On Fri, 15 Aug 2025 01:01:01 GMT, Ben Perez wrote:
> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
> optimized. In particular, since modulus[2] = 0 several multiplications can be
> removed. Other multiplications can be replaced by shifts, which also saves
> time.
> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
> optimized. In particular, since modulus[2] = 0 several multiplications can be
> removed. Other multiplications can be replaced by shifts, which also saves
> time. Preliminary tests indicate an improvement between 5-
> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
> optimized. In particular, since modulus[2] = 0 several multiplications can be
> removed. Other multiplications can be replaced by shifts, which also saves
> time. Preliminary tests indicate an improvement between 5-
On Wed, 20 Aug 2025 15:16:47 GMT, Chen Liang wrote:
> > What do you mean by "works"? And why doesn't it work for the zeroes?
>
> As descirbed by [the documentation of
> `@Stable`](https://cr.openjdk.org/~jrose/jvm/Stable.html), a 0 value may be
> interpreted as "uncomputed" for lazy values, an
On Fri, 15 Aug 2025 01:01:01 GMT, Ben Perez wrote:
> There are several places where MontgomeryIntegerPolynomialP256.mult() can be
> optimized. In particular, since modulus[2] = 0 several multiplications can be
> removed. Other multiplications can be replaced by shifts, which also saves
> time.
On Wed, 20 Aug 2025 14:47:58 GMT, Ferenc Rakoczi wrote:
> What do you mean by "works"? And why doesn't it work for the zeroes?
As descirbed by [the documentation of
`@Stable`](https://cr.openjdk.org/~jrose/jvm/Stable.html), a 0 value may be
interpreted as "uncomputed" for lazy values, and the
On Fri, 15 Aug 2025 14:50:23 GMT, ExE Boss wrote:
> > I see you are inlining some modulus values manually. You can mark the
> > arrays as `@Stable` and check what performance gain can you have as a
> > result, because then C2 can treat these values as constants and generate
> > more optimal co
On Fri, 15 Aug 2025 13:47:04 GMT, Chen Liang wrote:
> I see you are inlining some modulus values manually. You can mark the arrays
> as `@Stable` and check what performance gain can you have as a result,
> because then C2 can treat these values as constants and generate more optimal
> computat
On Fri, 15 Aug 2025 03:47:01 GMT, Chen Liang wrote:
> This particular method is already `@IntrinsicCandidate`: what special
> treatment does it get from the JVM?
There are currently only intrinsics for x86 so improvements to the Java
implementation will still benefit quite a few users.
--
13 matches
Mail list logo