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