On 06/25/2013 09:09 PM, Alan Eliasen wrote:
On 06/25/2013 12:13 PM, Peter Levart wrote:
else { // resizing
// increase by factor of 1.5 (like ArrayList)
int newLength = oldLength + (oldLength >> 1);
We probably don't ever want to extend any ro
On 06/25/2013 12:13 PM, Peter Levart wrote:
> else { // resizing
> // increase by factor of 1.5 (like ArrayList)
> int newLength = oldLength + (oldLength >> 1);
We probably don't ever want to extend any row of this cache any more
than we need to. The
On 06/25/2013 10:13 PM, Peter Levart wrote:
>
> On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
>> T get(int index1, index2) {
>> T[][] lc = cache;
>> if (index1 >= lc.length) { // needs resizing
>> lc = ((index1 << 1) + 1);
>> cache = lc;
>> }
>> T[] lt = lc[
On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
T get(int index1, index2) {
T[][] lc = cache;
if (index1 >= lc.length) { // needs resizing
lc = ((index1 << 1) + 1);
cache = lc;
}
T[] lt = lc[*index2*];
if (index2 >= lt.length) { // needs resizin
So I am going to try to please everybody (I hope).
I agree with Alan Eliasen that the existing patch for 4641897 should be
integrated as-is.
I also think however that we might as well integrate Aleksey and Dima's patch
immediately thereafter, before the large integer division review. To that en
On 21/06/2013 16:04, Brian Burkhalter wrote:
On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
One part that might need attention is getRadixConversionCache as I
could imagine cases where the synchronization could lead to
contention. Have you (or Alan) considered alternatives that would
limit
Sorry, I missed line "pc[radix] = cacheLine;" in the method
"getRadixConversionCache();"
in the previous post.
Here is the corrected patch.
*** Alan Eliasen's BigInteger.java
--- BigInteger.java patched according to Aleksey's advice
***
*** 1038,1048
/**
* The cache of
Thank you, Aleksey!
Alan said: "I'm willing to review any rewrites that people might suggest".
Here is a concretization of Aleksey's patch for Alan's review.
*** Alan's BigInteger.java
--- BigInteger.java patched according to Aleksey's advice
***
*** 1038,1048
/**
*
On 06/22/2013 02:50 PM, Aleksey Shipilev wrote:
> On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
>> Alexey,
>>
>> Each possible radix has its cacheLine in the cache.
>>
>> Cache contents looks like
>> BigInteger[][] powerCache = new BigInteger[37] {
>> /*0*/ null,
>> /*1*/ null,
>> /*2*/ new BigInt
On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
> Alexey,
>
> Each possible radix has its cacheLine in the cache.
>
> Cache contents looks like
> BigInteger[][] powerCache = new BigInteger[37] {
> /*0*/ null,
> /*1*/ null,
> /*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
> /*3*/ new BigInte
Below are the results of performance evaluation:
1) Performance improvement of specialized method bi.toHexString() against
general bi.toString(16).
2) Code ot hypothetical BigInteger.toHexString();
3) Code of benchmark.
-Dima
=== b.bitLength(); b.toString(16); b.toHexString();
bitLength=2047;
On 06/21/2013 06:42 PM, Brian Burkhalter wrote:
> I think
> the main open problem for this patch and the Karatsuba one just
> integrated this week is to determine algorithm crossover thresholds
> which are not going to provoke performance degradations for certain
> intermediate bit lengths on the p
On 06/21/2013 10:23 PM, Dmitry Nadezhin wrote:
> Brian,
>
> This patch significally enhances performance of string conversion for
> large numbers.
>
> I suggest to create also a fast path for power-of-two radices: 2, 4, 8, 16,
> 32 .
> It is a simple linear algorithm that is suitable both for la
Brian,
This patch significally enhances performance of string conversion for
large numbers.
I suggest to create also a fast path for power-of-two radices: 2, 4, 8, 16,
32 .
It is a simple linear algorithm that is suitable both for large and small
numbers.
Can it be attached to this bug activity
Alexey,
Each possible radix has its cacheLine in the cache.
Cache contents looks like
BigInteger[][] powerCache = new BigInteger[37] {
/*0*/ null,
/*1*/ null,
/*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
/*3*/ new BigInteger[] { 3, 9, 81, ... },
/*4*/ new BigInteger[] { 4, 16, 256, ... }
On Jun 21, 2013, at 9:56 AM, Alan Eliasen wrote:
> Yes, as noted in the code comments and in my comments on this list,
> it would be possible to do something fancier, perhaps using Future.
> This code was intended to be as simple and understandable as possible,
> to rapidly give an asymptoticall
On 06/21/2013 09:04 AM, Brian Burkhalter wrote:
>
> On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
>
>> One part that might need attention is getRadixConversionCache as I
>> could imagine cases where the synchronization could lead to
>> contention. Have you (or Alan) considered alternatives tha
On 06/21/2013 07:04 PM, Brian Burkhalter wrote:
>
> On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
>
>> One part that might need attention is getRadixConversionCache as I
>> could imagine cases where the synchronization could lead to
>> contention. Have you (or Alan) considered alternatives tha
On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
> One part that might need attention is getRadixConversionCache as I could
> imagine cases where the synchronization could lead to contention. Have you
> (or Alan) considered alternatives that would limit the synchronization to
> only when the p
On 19/06/2013 20:58, Brian Burkhalter wrote:
Continuing on from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018181.html
here is a new Request for Review, this time for
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897
The webrev is here
http://cr.openj
Hi Brain,
I believe that you can reuse "zeros" array which is declared in the class to
improve:
// Pad with internal zeros if necessary.
// Don't pad if we're at the beginning of the string.
if ((s.length() < digits) && (sb.length() > 0))
for (int i=s.length(); i 0)
f
21 matches
Mail list logo
