RFR [9]: Better failure output for test/java/util/Arrays/ParallelPrefix.java
Chris Hegarty
chris.hegarty at oracle.com
Thu Jun 4 14:57:15 UTC 2015
On 4 Jun 2015, at 15:28, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Jun 4, 2015, at 4:09 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> On 4 Jun 2015, at 13:37, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>> ...
>>> If you wanna go the extra mile it's useful for the data provider to supply a string description argument summarizing the test data.
>>
>> Added.
>>
>
> I did not mean:
>
>> + @DataProvider(name = "intSet")
>
> I meant as a String parameter of the test method, so that some useful summary shows up in the test report. It's not terribly important.
D’oh! Sorry.
>>> You might want to size the arrays in proportion to the parallelism since the threshold is calculated as:
>>>
>>> this.threshold =
>>> (p = (hi - lo) / (ForkJoinPool.getCommonPoolParallelism() << 3))
>>> <= MIN_PARTITION ? MIN_PARTITION : p;
>>>
>>> So for a large machine with say a parallelism of 2^5 an array size of 2^12 is not sufficient to go above MIN_PARTITION..
>>
>> I could be wrong, and I accept your point about sizing as per parallelism, but I think 2^12 should be sufficient for most systems, given MIN_PARTITION = 16. With a parallelism of 2^5, then p will be greater than MIN_PARTITION, no?
>>
>
> Equal to:
>
> 2^12 / (2^5 * 2^3) = 2^12 / 2^8 = 2^4
Another d’oh! I missed the '<< 3' in my calculations.
> I think it would be ok to increase this to 2^14.
Increasing the size to 2^14 increases the execution time of the test from ~2 secs to ~(12-16) secs on my really old slow machine. So this should be ok. I’ll run some more tests with the increased size before pushing.
Thanks,
-Chris.
> Paul.
More information about the core-libs-dev
mailing list