On Wed, 9 Feb 2022 22:42:50 GMT, Paul Sandoz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 1603:
>>
>>> 1601: * parallel multiplication algorithm will use more CPU resources
>>> 1602: * to compute the result faster, with no increase in memory
>>> 1603: * con
On Wed, 9 Feb 2022 22:48:57 GMT, Paul Sandoz wrote:
> > A question about wording of the @implNote. In multiply() they say: "An
> > implementation may offer better algorithmic ...", but we changed this to
> > "This implementation may offer better algorithmic ..." I've kept it as
> > "This imple
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Thu, 3 Feb 2022 05:33:52 GMT, kabutz wrote:
> A question about wording of the @implNote. In multiply() they say: "An
> implementation may offer better algorithmic ...", but we changed this to
> "This implementation may offer better algorithmic ..." I've kept it as "This
> implementation may
On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since To
On Thu, 3 Feb 2022 06:35:47 GMT, Joe Darcy wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Updated comment to include information about performance
>
> src/java.base/share/classes/java/math/BigInteger.java line 1603:
>
On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since To
On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since To
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Fri, 28 Jan 2022 19:03:39 GMT, kabutz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Benchmark for testing the effectiveness of BigInteger.parallelMultiply()
>
> I have added a benchmark for checking performance diff
On Fri, 28 Jan 2022 19:03:39 GMT, kabutz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Benchmark for testing the effectiveness of BigInteger.parallelMultiply()
>
> I have added a benchmark for checking performance diff
On Fri, 28 Jan 2022 18:59:56 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to paral
On Sat, 15 Jan 2022 18:03:33 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Changed depth type to byte to save 8 bytes on each RecursiveSquare instance
>
> test/jdk/java/math/BigInteger/BigIntegerParall
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to paral
On Thu, 16 Dec 2021 06:07:29 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to paral
On Thu, 16 Dec 2021 21:54:43 GMT, Paul Sandoz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to
On Thu, 16 Dec 2021 21:48:14 GMT, kabutz wrote:
> > embarrassingly parallelizable
>
> Having looked at [embarrassingly
> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
> certain that this particular problem would qualify. The algorithm is easy to
> parallelize, but
On Thu, 16 Dec 2021 21:37:26 GMT, kabutz wrote:
> > embarrassingly parallelizable
>
> Having looked at [embarrassingly
> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
> certain that this particular problem would qualify. The algorithm is easy to
> parallelize, but
On Thu, 16 Dec 2021 21:30:21 GMT, kabutz wrote:
> embarrassingly parallelizable
Having looked at [embarrassingly
parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
certain that this particular problem would qualify. The algorithm is easy to
parallelize, but in the end w
On Thu, 16 Dec 2021 21:22:02 GMT, Paul Sandoz wrote:
> > "embarrassingly parallel when employing recursive" -> "embarrassingly
> > non-parallel when employing recursive" (?)
>
> I corrected to "embarrassingly parallelizable" (i believe that is a common
> phrase we as software engineers use in
On Thu, 16 Dec 2021 20:09:59 GMT, kabutz wrote:
> "embarrassingly parallel when employing recursive" -> "embarrassingly
> non-parallel when employing recursive" (?)
I corrected to "embarrassingly parallelizable" (i believe that is a common
phrase we as software engineers use in these cases).
On Thu, 16 Dec 2021 19:46:19 GMT, Paul Sandoz wrote:
> > Terribly sorry to ask this, but where would I see the CSR? I don't have
> > access to the JIRA in the backend.
>
> You should be able to view it but not edit:
>
> https://bugs.openjdk.java.net/browse/JDK-8278886
>
> (To get creation/upd
On Thu, 16 Dec 2021 06:07:29 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Thu, 16 Dec 2021 19:39:59 GMT, kabutz wrote:
> Terribly sorry to ask this, but where would I see the CSR? I don't have
> access to the JIRA in the backend.
You should be able to view it but not edit:
https://bugs.openjdk.java.net/browse/JDK-8278886
(To get creation/update access rights y
On Thu, 16 Dec 2021 05:55:14 GMT, kabutz wrote:
>> This is looking good. I will create the CSR and propose it. Since the
>> holiday season is imminent it's likely no approval of the CSR will happen on
>> until the new year.
>
>> This is looking good. I will create the CSR and propose it. Since
On Thu, 16 Dec 2021 05:55:14 GMT, kabutz wrote:
>> This is looking good. I will create the CSR and propose it. Since the
>> holiday season is imminent it's likely no approval of the CSR will happen on
>> until the new year.
>
>> This is looking good. I will create the CSR and propose it. Since
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Thu, 16 Dec 2021 01:01:33 GMT, Paul Sandoz wrote:
>> Inside the constructor would not work, since we do not construct RecursiveOp
>> for all the tasks. However, I have incremented the parameter depth. I don't
>> like changing parameters inside methods, but since I'm doing it where it is
>>
On Thu, 16 Dec 2021 01:33:46 GMT, Paul Sandoz wrote:
> This is looking good. I will create the CSR and propose it. Since the holiday
> season is imminent it's likely no approval of the CSR will happen on until
> the new year.
Thank you so much Paul.
-
PR: https://git.openjdk.java
On Wed, 15 Dec 2021 20:18:39 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Wed, 15 Dec 2021 14:31:26 GMT, kabutz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2000:
>>
>>> 1998: da1 = a2.add(a0);
>>> 1999: db1 = b2.add(b0);
>>> 2000: var vm1_task = RecursiveOp.multiply(da1.subtract(a1),
>>> db1.subtract(b1), parallel,
On Wed, 15 Dec 2021 14:40:34 GMT, kabutz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 1909:
>>
>>> 1907: @Override
>>> 1908: public BigInteger compute() {
>>> 1909: return a.multiply(b, true, super.parallel,
>>> super.depth);
>>
>
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 30 Nov 2021 23:18:21 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:19:37 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:45:02 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:16:20 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:10:39 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:03:48 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Removed JVM flags from benchmark
>
> To add my 2c IMO a parallel version of this type absolutely **must** be
> opt-in. There
On 26/11/2021 4:15 am, kabutz wrote:
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Removed JVM flags from benchmark
To add my 2c IMO a parallel version of this type absolutely *
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Removed JVM flags from benchmark
>
> To add my 2c IMO a parallel version of this type absolutely **must** be
> opt-in. There
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Fri, 19 Nov 2021 10:42:23 GMT, kabutz wrote:
> > I think the functionality in this PR is worth pursuing, but with the JDK 18
> > rampdown 1 date fast approaching, as a non-urgent issue, I think we
> > shouldn't try to rush it into JDK 18.
>
> > I looked more closely and now understand a bit
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz wrote:
>
>
> > I also do not like potentially non-obvious default behavior, nor a command
> > line flag, nor a (static) setting on `BigInteger`. Thus I think the
> > original `parallelMultiply()` (or perhaps `multiplyParallel()`) would be
> > pre
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Nov 18, 2021, at 2:41 AM, kabutz
mailto:d...@openjdk.java.net>> wrote:
Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be
necessary. BigInteger has thresholds for using different multiply algorithms
and these are also not configurable.
Those thresholds are the res
-libs-dev
Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
[v3]
- Original Message -
> From: "Bernd Eckenfels"
> To: "core-libs-dev"
> Sent: Jeudi 18 Novembre 2021 12:07:19
> Subject: Re: RFR: JDK-8277175 : Add a parallel mult
- Original Message -
> From: "Bernd Eckenfels"
> To: "core-libs-dev"
> Sent: Jeudi 18 Novembre 2021 12:07:19
> Subject: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
> [v3]
> What about a new API multiply method which takes
://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von kabutz
Gesendet: Thursday, November 18, 2021 11:41:40 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
[v3]
On Thu, 18 Nov 2021 07:26:45 GMT, David
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
> To add my 2c IMO a parallel version of this type absolutely **must** be
> opt-in. There are simply far too many side-effects of using the FJP and
> multiple threads to perform the calculation in parallel as if it is just a
> minor impleme
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz wrote:
> > I also do not like potentially non-obvious default behavior, nor a command
> > line flag, nor a (static) setting on `BigInteger`. Thus I think the
> > original `parallelMultiply()` (or perhaps `multiplyParallel()`) would be
> > preferabl
On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund wrote:
> > I would be wary to make any API use multiple threads behind the scenes
> > without the user explicitly asking for it. While latency of the given
> > operation might improve in isolation, parallelization always incur some
> > (often si
On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund wrote:
> I would be wary to make any API use multiple threads behind the scenes
> without the user explicitly asking for it. While latency of the given
> operation might improve in isolation, parallelization always incur some
> (often significan
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Nov 17, 2021, at 11:14 AM, Paul Sandoz
mailto:psan...@openjdk.java.net>> wrote:
Would adding a parameter in the nature of `maxProcessors` make any sense?
Kind of but i would recommend not doing it. That's hard to express in a manner
that developers will choose appropriate values across all
On Wed, 17 Nov 2021 18:20:07 GMT, Brian Burkhalter wrote:
> I also do not like potentially non-obvious default behavior, nor a command
> line flag, nor a (static) setting on `BigInteger`. Thus I think the original
> `parallelMultiply()` (or perhaps `multiplyParallel()`) would be preferable.
Fo
On Wed, 17 Nov 2021 17:27:20 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 16 Nov 2021 21:22:36 GMT, Claes Redestad wrote:
> I would be wary to make any API use multiple threads behind the scenes
> without the user explicitly asking for it. While latency of the given
> operation might improve in isolation, parallelization always incur some
> (often significan
On Wed, 17 Nov 2021 17:14:32 GMT, Brian Burkhalter wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Reordered import statements to be consistent with canonical order
>
> src/java.base/share/classes/java/math/BigInteger.ja
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Wed, 17 Nov 2021 17:20:11 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 16 Nov 2021 13:22:46 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
On Tue, 16 Nov 2021 20:45:05 GMT, Simon Roberts
wrote:
> Is there not also an architectural consideration here? I'm inclined to think
> that just because execution in parallel finishes in less wall time does not
> mean that's the right thing to do. Those CPUs will be unavailable for other
> w
Is there not also an architectural consideration here? I'm inclined to
think that just because execution in parallel finishes in less wall time
does not mean that's the right thing to do. Those CPUs will be unavailable
for other work, and in any multi-user/client type system, that effectively
makes
On Tue, 16 Nov 2021 19:59:49 GMT, Joe Darcy wrote:
> As you cite, there are a few other cases in the JDK API were a second
> "parallelFoo" method is exposed. However, I don't think those precedents
> would necessarily mandate a parallelMultiply method in BigInteger. Without a
> separate method
On Tue, 16 Nov 2021 18:52:20 GMT, kabutz wrote:
>
>
> > It isn't clear to me that parallelMultiply should be a public method as
> > opposed to an implementation detail.
>
> Hi Joe, thanks for responding. I would have preferred for it to be an
> implementation detail, but I thought it best to
On Tue, 16 Nov 2021 18:42:42 GMT, Joe Darcy wrote:
> It isn't clear to me that parallelMultiply should be a public method as
> opposed to an implementation detail.
Hi Joe, thanks for responding. I would have preferred for it to be an
implementation detail, but I thought it best to keep things
On Tue, 16 Nov 2021 13:22:46 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
BigInteger currently uses three different algorithms for multiply. The simple
quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
count and then Toom Cook 3 once we go into the several thousands of bits. Since
Toom Cook 3 is a recursive algorithm, it is trivial to parallel
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
BigInteger currently uses three different algorithms for multiply. The simple
quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
count and then Toom Cook 3 once we go into the several thousands of bits. Since
Toom Cook 3 is a recursive algorithm, it is trivial to parallel
91 matches
Mail list logo
