RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16

[Mike Duigou]

On May 21 2013, at 20:20 , Joseph Darcy wrote:

> Hello Mike,
> 
> The TestNG data provider framework is unfamiliar to me, so my first reaction is that it is overkill for this problem as opposed to a one-off approach, but that may be driven my lack of experience with it.

Yes, quite possibly overkill for this test. 

> However, in the test code
> 
> 153     private static final long[] SOME_PRIMES = {
> 154         3L, 5L, 7L, 11L, 13L, 17L, 19L, 23L, 29L, 31L, 37L, 41L, 43L, 47L, 53L,
> 155         59L, 61L, 71L, 73L, 79L, Long.MIN_VALUE };

The Long.MIN_VALUE was used as a terminator rather than as a prime. I have changed the loop processing so that a terminator value is not needed.

> the name of the array is incorrect since Long.MIN_VALUE = -2^63 which is composite. Perhaps you were thinking of Integer.MAX_VALUE which is a Mersenne prime? (2^61 -1 is a Mersenne prime; 2^63 - 1 is not.)

Integer.MAX_VALUE now added along with some other primes near powers of two boundaries.

Updated webrev:

http://cr.openjdk.java.net/~mduigou/JDK-8007398/3/webrev/

Thanks!

Mike

> -Joe
> 
> On 5/21/2013 3:45 PM, Mike Duigou wrote:
>> Ping!
>> 
>> I need a final review on this issue.
>> 
>> Thanks,
>> 
>> Mike
>> 
>> On May 16 2013, at 14:02 , Mike Duigou wrote:
>> 
>>> On May 15 2013, at 19:09 , Joseph Darcy wrote:
>>> 
>>>> Hi Mike,
>>>> 
>>>> Looks fine. Are you satisfied with the test coverage provided by the existing regression tests?
>>> I hadn't actually looked but it turns out the answer was "No, certainly not".
>>> 
>>> I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that.
>>> 
>>> If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those.
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/
>>> 
>>> Mike
>>> 
>>>> -Joe
>>>> 
>>>> On 5/15/2013 6:17 PM, Mike Duigou wrote:
>>>>> Hello all;
>>>>> 
>>>>> This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits.
>>>>> 
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/
>>>>> 
>>>>> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in <http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016526.html>, and found that using the digits table was still faster.
>>>>> 
>>>>> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit.
>>>>> 
>>>>> Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform.
>>>>> 
>>>>> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting).
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Mike
>