On Mon, 22 Jan 2024 21:26:39 GMT, Brian Burkhalter wrote:
>> @bplb It is not used in jtreg testing.
>
> So it is only for verification purposes in the context of this PR?
@bplb Yes, it is.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17291#discussion_r1462444386
On Mon, 22 Jan 2024 20:02:34 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update TestDivWord.java
>>
>> Added method to check results of divWo
On Mon, 22 Jan 2024 18:07:49 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> As you note, that would probably requi
> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
> Hacker's Delight (2nd ed), section 9.3, the same used in
> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
> to get the computation faster.
fabioromano1 has updated the
On Mon, 22 Jan 2024 18:07:49 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> As you note, that would probably requi
On Mon, 22 Jan 2024 17:23:22 GMT, Raffaello Giulietti
wrote:
> AFAIK, IntrinsicCandidate methods are only relevant in JIT compiled code. A
> test that checks correctness might not reach the compilation stage, and
> execute only in the bytecode interpreter.
>
> But IMO using the result of
On Mon, 22 Jan 2024 16:15:57 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> What about splitting the result of `div
On Mon, 22 Jan 2024 15:38:08 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> Sure. But the purpose of a test is not mu
On Mon, 22 Jan 2024 15:38:08 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> Sure. But the purpose of a test is not mu
On Mon, 22 Jan 2024 15:14:58 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> The test does not seem to check that the
On Mon, 8 Jan 2024 18:20:09 GMT, Brian Burkhalter wrote:
> Do you have any benchmark results demonstrating the increased throughput?
I just uploaded a class for random tests. But during the execution, I've found
a non banal problem concerning the old implementation's running time.
The problem
> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
> Hacker's Delight (2nd ed), section 9.3, the same used in
> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
> to get the computation faster.
fabioromano1 has updated the
> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
> Hacker's Delight (2nd ed), section 9.3, the same used in
> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
> to get the computation faster.
fabioromano1 has updated the
The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
Hacker's Delight (2nd ed), section 9.3, the same used in
`Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to
get the computation faster.
-
Commit messages:
- Merge branch
On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Create RandomBigIntegers.java
>>
>> Create a benchmark to measure the p
On Mon, 4 Dec 2023 22:26:32 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Create RandomBigIntegers.java
>>
>> Create a benchmark to measure the p
On Mon, 4 Dec 2023 22:26:32 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Create RandomBigIntegers.java
>>
>> Create a benchmark to measure the p
On Thu, 30 Nov 2023 20:37:37 GMT, Roger Riggs wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update BigInteger(int, Random)
>>
>> Update a comment
>
> There are some
> A faster and simpler way to generate random BigIntegers, avoiding eventually
> trimming of leading zeros in magnitude array.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Create RandomBigIntegers.java
Create a ben
On Tue, 28 Nov 2023 19:31:14 GMT, Brian Burkhalter wrote:
>> Do you have any actual benchmark measurements that you could share?
>
>> @bplb I have not yet made benchmark measurements, but I can produce them.
>
> @fabioromano1 I think it would be good to measure a
On Tue, 28 Nov 2023 19:31:14 GMT, Brian Burkhalter wrote:
>> Do you have any actual benchmark measurements that you could share?
>
>> @bplb I have not yet made benchmark measurements, but I can produce them.
>
> @fabioromano1 I think it would be good to measure a
On Mon, 27 Nov 2023 22:58:17 GMT, fabioromano1 wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional
>
On Tue, 28 Nov 2023 01:08:43 GMT, Brian Burkhalter wrote:
>> It's equivalent. If you watch the implementations of other methods in the
>> class where a mask out is made, this method is often used.
>
> Indeed it looks as if that is correct.
As specified in
> A faster and simpler way to generate random BigIntegers, avoiding eventually
> trimming of leading zeros in magnitude array.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Update BigInteger(int, Random)
Update a c
On Mon, 27 Nov 2023 22:34:12 GMT, Brian Burkhalter wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> src/java.base/share/classes/java/math/BigInteger.java line 754:
>
>> 752: // numInts >= 1,
branch 'openjdk:master' into patch-4
- Merge branch 'patch-4' of https://github.com/fabioromano1/jdk into patch-4
- Merge branch 'openjdk:master' into patch-4
- An optimization
- Correct BigInteger(int , Random)
- Made random generation of BigIntegers faster
Changes: https://git.openjdk.org/jdk
On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 wrote:
> The enanchment is useful for applications that make heavy use of BitSet
> objects as sets of integers, and therefore they need to make a lot of calls
> to cardinality() method, which actually require linear time in the number of
ization reduces the cost of calling cardinality() to constant time,
> as it simply returns the value of the field, and it also try to make as
> little effort as possible to update the field, when needed.
fabioromano1 has updated the pull request incrementally with one additional
commit si
ization reduces the cost of calling cardinality() to constant time,
> as it simply returns the value of the field, and it also try to make as
> little effort as possible to update the field, when needed.
fabioromano1 has updated the pull request incrementally with one additional
commit si
On Thu, 19 Jan 2023 23:14:12 GMT, John R Rose wrote:
> I'll pile on: This optimization doesn't buy much in today's world, where most
> machines execute `bitCount` in one cycle. It saves a trivial loop. Over very
> large bitsets that saves something, but most bitsets are likely to be medium
>
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear
On Thu, 19 Jan 2023 14:03:38 GMT, fabioromano1 wrote:
> Libraries cannot be all things to all users. A library provides a service
> that would be difficult for a majority of users to implement on their own.
> Sometimes a library needs specialization for certain use cases. That is why
On Thu, 19 Jan 2023 13:24:03 GMT, Jim Laskey wrote:
> Libraries cannot be all things to all users. A library provides a service
> that would be difficult for a majority of users to implement on their own.
> Sometimes a library needs specialization for certain use cases. That is why
> we use
On Wed, 18 Jan 2023 21:51:02 GMT, Martin Buchholz wrote:
> Like other reviewers, changing the performance tradeoffs in BitSet make me
> uncomfortable.
>
> 30 years of code has adapted to the current performance tradeoffs. Those
> users who really need O(1) cardinality() can fairly easily
On Wed, 18 Jan 2023 14:15:17 GMT, Uwe Schindler wrote:
> As one dealing with bitsets very often: In my opinion, adding this to bitset
> adds too much overhead on the hot methods like set/clear methods. Especially
> loops that populate a BitSet with values, I am not sure if the whole loop can
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request incrementally with five additional
commits since the last revision:
- Revert "Formatted"
This reverts comm
On Wed, 18 Jan 2023 11:37:05 GMT, Alan Bateman wrote:
> It looks all the javadoc and several areas of the code have been
> re-formatted. Please revert all of this as it's impossible to see what has
> been changed.
Done.
-
PR: https://git.openjdk.org/jdk/pull/11837
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Added author and reverse the cicle order in includes(BitSet)
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/reb
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Added author to includes(BitSet)
-
Changes:
-
On Wed, 11 Jan 2023 15:33:47 GMT, Claes Redestad wrote:
>> I agree with the fact that is less intrusive, but certainly not potentially
>> quicker, since the complete recalculation of cardinality requires linear
>> time in the value of wordsInUse
>
> A perhaps slightly less racy way would be to
On Wed, 11 Jan 2023 12:57:47 GMT, Jim Laskey wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>>
On Wed, 18 Jan 2023 06:36:56 GMT, Julian Waters wrote:
> @fabioromano1 Would you like me to create an entry for you for the Pull
> Request is linked to the appropriate mailing list? When I do that you will
> have to change the name of this Pull Request though
Yes, thank you
The enanchment is useful for applications that make heavy use of BitSet objects
as sets of integers, and therefore they need to make a lot of calls to
cardinality() method, which actually require linear time in the number of words
in use by the bit set.
This optimization reduces the cost of
44 matches
Mail list logo
