You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Vladimir Strigun <vs...@gmail.com> on 2006/06/02 09:54:24 UTC
[classlib][java.math]performance improvement for java.math package
Our team has done some analysis of current Harmony implementation of
java.math package. The implementation was considered from the
performance point of view and I'd like to share results of our work
with you.
The analysis and tuning was made from the enterprise-level
applications point of view which are known to use BigInteger and
BigDecimal for storing numeric information. In most cases the numbers
there fit well within 32 bits. So coming from the BigDecimal
perspective which is really important for these applications and
taking into account some specifics (small numbers) we made some
optimizations in both BigDecimal and BigInteger. The latter was tuned
specifically for BigDecimal:
- Special handling for small numbers (fit within 32 bit) was added to
all methods
- Frequently used constants (0..10) were cached and reused by valueOf
method (no need to create a new instance of BigInteger)
- as well as were powers of 10 (0..10)
- methods add(), divide(), divideAndRemainer() in BigInteger were
optimized for short values if both arguments can fit in 32 bits the
resulting BigInteger is created by valueOf method.
If we consider enterprise level applications, we can imagine that
toString() method is also frequently used. The method was analyzed and
as a result we combined toString() methods in BigDecimal and
BigInteger to one unified method in BigInteger. Method
BigInteger.toDecimalScaledString(int scale) now is used from both
BigInteger and BigDecimal. This way allows reducing amount of created
objects and data copying. In addition, size calculation was modified
for resulting array. In the new implementation the size is calculated
with less precision. Because allocated char array will be copied into
String and collected by GC after toString() then it is not a problem
if the allocated char array will be slightly bigger then necessary.
I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
We also have created a set of micro benchmarks (which I'll to attach
to JIRA as well) which shows that our special-case handling doesn't
break the performance for other cases and we do not degrade in common,
and, of course, all unit tests pass with new version. Below you can
find several comparisons in performance between current version and
the fixed one.
===
Ops/sec for toString() method of BigDecimal
Number Current fixed one
of digits version
2 1121 5354
4 774 7514
8 615 6748
12 743 5543
16 623 4494
24 389 4895
32 306 3496
48 232 5815
64 224 3761
128 91 87
Ops/sec for divide method of BigInteger
Number Current fixed one
of digits version
2 5247 6315
4 4623 6497
8 5560 7491
12 838 838
16 2533 2063
24 1689 1717
32 2397 2494
48 2143 2131
64 613 525
128 1399 1418
Ops/sec for subtract method of BigInteger
Number Current fixed one
of digits version
2 3920 4394
4 3300 3302
8 5178 5640
12 957 913
16 3794 2904
24 2057 1962
32 3421 3241
48 3469 2828
64 652 610
128 2318 2246
===
Unfortunately we haven't look thoroughly to ITC contribution, so it
may happen that some of the optimizations described in this letter
were already implemented there. Daniel, could you please consider our
new implementation when you start to merge implementations math
packages. If optimization methods described above already have been
implemented in ITC contribution it will be great to compare internal
representation of BigInteger and try to measure affect of different
approaches.
On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
>
> Vladimir Strigun updated HARMONY-551:
> -------------------------------------
>
> Attachment: Harmony-551.diffs
>
> Please try my patch.
> Several features were added:
> - special handling for small value
> - frequently used constans were cached
> - several methods were modified and optimized for small value.
> etc.
>
> > [classlib][java.math] performance improvement for java.math package
> > -------------------------------------------------------------------
> >
> > Key: HARMONY-551
> > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > Project: Harmony
> > Type: Improvement
>
> > Components: Classlib
> > Reporter: Vladimir Strigun
> > Attachments: Harmony-551.diffs
> >
> > Performance improvement for BigDecimal and BigInteger classes.
> > I will attach patch soon.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][java.math]performance improvement for java.math package
Posted by Vladimir Strigun <vs...@gmail.com>.
Hi Daniel,
Thank you for your response and sorry for delay with my answer. Please
find my comments inside.
On 6/15/06, Daniel Fridlender <df...@gmail.com> wrote:
> Hi Vladimir,
>
> thank you very much for this new optimization of math from, as you
> said, enterprise-level applications point of view. Of course we are
> considering this optimization (H551) as well for the combination of
> the different math implementations into a new and more efficient one.
>
> In fact we are already working on a new version combining H39+380 with
> H199 and are introducing some of H551 optimizations as well. On the
> other hand, we are for the moment postponing some other of your
> optimizations for a future version since introducing them now would
> break, in my opinion prematurely, a nice design property we have so
> far: BigDecimal depends only on public features of BigInteger.
Thanks for doing this. What kind of optimization you planned to add first?
I can agree that it's good to have such design, but nevertheless since
BigDecimal internally represented though BigInteger, possibly it
should be also good to use some non public features of BigInteger.
> So, we are following this plan:
>
> 1) integration of H39+H380 with H199 and with part of H551
> 2) optimization of this with more advanced algorithms
> 3) introducing remaining optimization from H551
>
> For the point 2) above I would still like to have independence between
> BigDecimal and BigInteger.
>
> I hope you agree with this plan.
Yes, this plan sounds good for me. Let's follow it and compare
implementations after 1st integration. We can use microbench that
attached to the issue, or, possibly we should find another benchmark
for it. What benchmarks you have used for performance measurement?
> I would also be grateful if you could be more specific when you
> mention enterprise-level applications. We are looking for realistic
> applications of math in order to be able to get an idea of how the
> implementations will work in practice. So far we had only found a few
> applications in cryptography and in number factorization (actually,
> they are applications of BigInteger only). Could you point me to the
> applications you had in mind so that we can add them to our (so far)
> small collection of applications? Are those applications for which
> float or double are not enough?
I have in mind some banking software, online payment processing, etc.
Within these type of application values usually fit to 32 bit, that's
why we have special case for small numbers. Also, these optimizations
do not degrade in common.
Thanks,
Vladimir.
> Thanks again,
>
> Daniel
>
>
> On 6/2/06, Vladimir Strigun <vs...@gmail.com> wrote:
> > Our team has done some analysis of current Harmony implementation of
> > java.math package. The implementation was considered from the
> > performance point of view and I'd like to share results of our work
> > with you.
> >
> > The analysis and tuning was made from the enterprise-level
> > applications point of view which are known to use BigInteger and
> > BigDecimal for storing numeric information. In most cases the numbers
> > there fit well within 32 bits. So coming from the BigDecimal
> > perspective which is really important for these applications and
> > taking into account some specifics (small numbers) we made some
> > optimizations in both BigDecimal and BigInteger. The latter was tuned
> > specifically for BigDecimal:
> >
> > - Special handling for small numbers (fit within 32 bit) was added to
> > all methods
> > - Frequently used constants (0..10) were cached and reused by valueOf
> > method (no need to create a new instance of BigInteger)
> > - as well as were powers of 10 (0..10)
> > - methods add(), divide(), divideAndRemainer() in BigInteger were
> > optimized for short values if both arguments can fit in 32 bits the
> > resulting BigInteger is created by valueOf method.
> >
> >
> > If we consider enterprise level applications, we can imagine that
> > toString() method is also frequently used. The method was analyzed and
> > as a result we combined toString() methods in BigDecimal and
> > BigInteger to one unified method in BigInteger. Method
> > BigInteger.toDecimalScaledString(int scale) now is used from both
> > BigInteger and BigDecimal. This way allows reducing amount of created
> > objects and data copying. In addition, size calculation was modified
> > for resulting array. In the new implementation the size is calculated
> > with less precision. Because allocated char array will be copied into
> > String and collected by GC after toString() then it is not a problem
> > if the allocated char array will be slightly bigger then necessary.
> >
> > I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
> >
> > We also have created a set of micro benchmarks (which I'll to attach
> > to JIRA as well) which shows that our special-case handling doesn't
> > break the performance for other cases and we do not degrade in common,
> > and, of course, all unit tests pass with new version. Below you can
> > find several comparisons in performance between current version and
> > the fixed one.
> >
> > ===
> >
> > Ops/sec for toString() method of BigDecimal
> >
> > Number Current fixed one
> > of digits version
> > 2 1121 5354
> > 4 774 7514
> > 8 615 6748
> > 12 743 5543
> > 16 623 4494
> > 24 389 4895
> > 32 306 3496
> > 48 232 5815
> > 64 224 3761
> > 128 91 87
> >
> > Ops/sec for divide method of BigInteger
> >
> > Number Current fixed one
> > of digits version
> >
> > 2 5247 6315
> > 4 4623 6497
> > 8 5560 7491
> > 12 838 838
> > 16 2533 2063
> > 24 1689 1717
> > 32 2397 2494
> > 48 2143 2131
> > 64 613 525
> > 128 1399 1418
> >
> > Ops/sec for subtract method of BigInteger
> >
> > Number Current fixed one
> > of digits version
> >
> > 2 3920 4394
> > 4 3300 3302
> > 8 5178 5640
> > 12 957 913
> > 16 3794 2904
> > 24 2057 1962
> > 32 3421 3241
> > 48 3469 2828
> > 64 652 610
> > 128 2318 2246
> >
> > ===
> >
> > Unfortunately we haven't look thoroughly to ITC contribution, so it
> > may happen that some of the optimizations described in this letter
> > were already implemented there. Daniel, could you please consider our
> > new implementation when you start to merge implementations math
> > packages. If optimization methods described above already have been
> > implemented in ITC contribution it will be great to compare internal
> > representation of BigInteger and try to measure affect of different
> > approaches.
> >
> >
> >
> >
> > On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> > > [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
> > >
> > > Vladimir Strigun updated HARMONY-551:
> > > -------------------------------------
> > >
> > > Attachment: Harmony-551.diffs
> > >
> > > Please try my patch.
> > > Several features were added:
> > > - special handling for small value
> > > - frequently used constans were cached
> > > - several methods were modified and optimized for small value.
> > > etc.
> > >
> > > > [classlib][java.math] performance improvement for java.math package
> > > > -------------------------------------------------------------------
> > > >
> > > > Key: HARMONY-551
> > > > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > > > Project: Harmony
> > > > Type: Improvement
> > >
> > > > Components: Classlib
> > > > Reporter: Vladimir Strigun
> > > > Attachments: Harmony-551.diffs
> > > >
> > > > Performance improvement for BigDecimal and BigInteger classes.
> > > > I will attach patch soon.
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > If you think it was sent incorrectly contact one of the administrators:
> > > http://issues.apache.org/jira/secure/Administrators.jspa
> > > -
> > > For more information on JIRA, see:
> > > http://www.atlassian.com/software/jira
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][java.math]performance improvement for java.math package
Posted by Daniel Fridlender <df...@gmail.com>.
Hi Vladimir,
thank you very much for this new optimization of math from, as you
said, enterprise-level applications point of view. Of course we are
considering this optimization (H551) as well for the combination of
the different math implementations into a new and more efficient one.
In fact we are already working on a new version combining H39+380 with
H199 and are introducing some of H551 optimizations as well. On the
other hand, we are for the moment postponing some other of your
optimizations for a future version since introducing them now would
break, in my opinion prematurely, a nice design property we have so
far: BigDecimal depends only on public features of BigInteger.
So, we are following this plan:
1) integration of H39+H380 with H199 and with part of H551
2) optimization of this with more advanced algorithms
3) introducing remaining optimization from H551
For the point 2) above I would still like to have independence between
BigDecimal and BigInteger.
I hope you agree with this plan.
I would also be grateful if you could be more specific when you
mention enterprise-level applications. We are looking for realistic
applications of math in order to be able to get an idea of how the
implementations will work in practice. So far we had only found a few
applications in cryptography and in number factorization (actually,
they are applications of BigInteger only). Could you point me to the
applications you had in mind so that we can add them to our (so far)
small collection of applications? Are those applications for which
float or double are not enough?
Thanks again,
Daniel
On 6/2/06, Vladimir Strigun <vs...@gmail.com> wrote:
> Our team has done some analysis of current Harmony implementation of
> java.math package. The implementation was considered from the
> performance point of view and I'd like to share results of our work
> with you.
>
> The analysis and tuning was made from the enterprise-level
> applications point of view which are known to use BigInteger and
> BigDecimal for storing numeric information. In most cases the numbers
> there fit well within 32 bits. So coming from the BigDecimal
> perspective which is really important for these applications and
> taking into account some specifics (small numbers) we made some
> optimizations in both BigDecimal and BigInteger. The latter was tuned
> specifically for BigDecimal:
>
> - Special handling for small numbers (fit within 32 bit) was added to
> all methods
> - Frequently used constants (0..10) were cached and reused by valueOf
> method (no need to create a new instance of BigInteger)
> - as well as were powers of 10 (0..10)
> - methods add(), divide(), divideAndRemainer() in BigInteger were
> optimized for short values if both arguments can fit in 32 bits the
> resulting BigInteger is created by valueOf method.
>
>
> If we consider enterprise level applications, we can imagine that
> toString() method is also frequently used. The method was analyzed and
> as a result we combined toString() methods in BigDecimal and
> BigInteger to one unified method in BigInteger. Method
> BigInteger.toDecimalScaledString(int scale) now is used from both
> BigInteger and BigDecimal. This way allows reducing amount of created
> objects and data copying. In addition, size calculation was modified
> for resulting array. In the new implementation the size is calculated
> with less precision. Because allocated char array will be copied into
> String and collected by GC after toString() then it is not a problem
> if the allocated char array will be slightly bigger then necessary.
>
> I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
>
> We also have created a set of micro benchmarks (which I'll to attach
> to JIRA as well) which shows that our special-case handling doesn't
> break the performance for other cases and we do not degrade in common,
> and, of course, all unit tests pass with new version. Below you can
> find several comparisons in performance between current version and
> the fixed one.
>
> ===
>
> Ops/sec for toString() method of BigDecimal
>
> Number Current fixed one
> of digits version
> 2 1121 5354
> 4 774 7514
> 8 615 6748
> 12 743 5543
> 16 623 4494
> 24 389 4895
> 32 306 3496
> 48 232 5815
> 64 224 3761
> 128 91 87
>
> Ops/sec for divide method of BigInteger
>
> Number Current fixed one
> of digits version
>
> 2 5247 6315
> 4 4623 6497
> 8 5560 7491
> 12 838 838
> 16 2533 2063
> 24 1689 1717
> 32 2397 2494
> 48 2143 2131
> 64 613 525
> 128 1399 1418
>
> Ops/sec for subtract method of BigInteger
>
> Number Current fixed one
> of digits version
>
> 2 3920 4394
> 4 3300 3302
> 8 5178 5640
> 12 957 913
> 16 3794 2904
> 24 2057 1962
> 32 3421 3241
> 48 3469 2828
> 64 652 610
> 128 2318 2246
>
> ===
>
> Unfortunately we haven't look thoroughly to ITC contribution, so it
> may happen that some of the optimizations described in this letter
> were already implemented there. Daniel, could you please consider our
> new implementation when you start to merge implementations math
> packages. If optimization methods described above already have been
> implemented in ITC contribution it will be great to compare internal
> representation of BigInteger and try to measure affect of different
> approaches.
>
>
>
>
> On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> > [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
> >
> > Vladimir Strigun updated HARMONY-551:
> > -------------------------------------
> >
> > Attachment: Harmony-551.diffs
> >
> > Please try my patch.
> > Several features were added:
> > - special handling for small value
> > - frequently used constans were cached
> > - several methods were modified and optimized for small value.
> > etc.
> >
> > > [classlib][java.math] performance improvement for java.math package
> > > -------------------------------------------------------------------
> > >
> > > Key: HARMONY-551
> > > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > > Project: Harmony
> > > Type: Improvement
> >
> > > Components: Classlib
> > > Reporter: Vladimir Strigun
> > > Attachments: Harmony-551.diffs
> > >
> > > Performance improvement for BigDecimal and BigInteger classes.
> > > I will attach patch soon.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> > http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> > http://www.atlassian.com/software/jira
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][java.math]performance improvement for java.math package
Posted by Vladimir Strigun <vs...@gmail.com>.
On 6/20/06, Mikhail Loenko <ml...@gmail.com> wrote:
> I think they are not unit tests and should go to a different
> (performance?) test
> suite. Right now we don't have one but it seems to be time to create it
Of course, it's not unit tests, but my suggestion was based on our
testing convention.
What do you think about <modulename>/src/tests/performance ?
Thanks,
Vladimir.
> Thanks,
> Mikhail
>
> 2006/6/20, Vladimir Strigun <vs...@gmail.com>:
> > Hi Mikhail,
> >
> > AFAIK, we haven't such kind of tests in svn yet. It's hard to define
> > best place for it, but since this suite is intended for java.math
> > testing only and it's implementation-independent tests, I believe
> > modules/math/src/test/java/tests/api is appropriate place. If you
> > agree with this I will create patch for suite, add copyright and
> > change package definition of classes.
> >
> > What do you think about it?
> >
> > Thanks,
> > Vladimir.
> >
> > On 6/13/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > Hi Vladimir
> > >
> > > What do you think the most appropriate location and suite for the tests
> > > in the HARMONY-551 are?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/6/2, Vladimir Strigun <vs...@gmail.com>:
> > > > Our team has done some analysis of current Harmony implementation of
> > > > java.math package. The implementation was considered from the
> > > > performance point of view and I'd like to share results of our work
> > > > with you.
> > > >
> > > > The analysis and tuning was made from the enterprise-level
> > > > applications point of view which are known to use BigInteger and
> > > > BigDecimal for storing numeric information. In most cases the numbers
> > > > there fit well within 32 bits. So coming from the BigDecimal
> > > > perspective which is really important for these applications and
> > > > taking into account some specifics (small numbers) we made some
> > > > optimizations in both BigDecimal and BigInteger. The latter was tuned
> > > > specifically for BigDecimal:
> > > >
> > > > - Special handling for small numbers (fit within 32 bit) was added to
> > > > all methods
> > > > - Frequently used constants (0..10) were cached and reused by valueOf
> > > > method (no need to create a new instance of BigInteger)
> > > > - as well as were powers of 10 (0..10)
> > > > - methods add(), divide(), divideAndRemainer() in BigInteger were
> > > > optimized for short values if both arguments can fit in 32 bits the
> > > > resulting BigInteger is created by valueOf method.
> > > >
> > > >
> > > > If we consider enterprise level applications, we can imagine that
> > > > toString() method is also frequently used. The method was analyzed and
> > > > as a result we combined toString() methods in BigDecimal and
> > > > BigInteger to one unified method in BigInteger. Method
> > > > BigInteger.toDecimalScaledString(int scale) now is used from both
> > > > BigInteger and BigDecimal. This way allows reducing amount of created
> > > > objects and data copying. In addition, size calculation was modified
> > > > for resulting array. In the new implementation the size is calculated
> > > > with less precision. Because allocated char array will be copied into
> > > > String and collected by GC after toString() then it is not a problem
> > > > if the allocated char array will be slightly bigger then necessary.
> > > >
> > > > I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
> > > >
> > > > We also have created a set of micro benchmarks (which I'll to attach
> > > > to JIRA as well) which shows that our special-case handling doesn't
> > > > break the performance for other cases and we do not degrade in common,
> > > > and, of course, all unit tests pass with new version. Below you can
> > > > find several comparisons in performance between current version and
> > > > the fixed one.
> > > >
> > > > ===
> > > >
> > > > Ops/sec for toString() method of BigDecimal
> > > >
> > > > Number Current fixed one
> > > > of digits version
> > > > 2 1121 5354
> > > > 4 774 7514
> > > > 8 615 6748
> > > > 12 743 5543
> > > > 16 623 4494
> > > > 24 389 4895
> > > > 32 306 3496
> > > > 48 232 5815
> > > > 64 224 3761
> > > > 128 91 87
> > > >
> > > > Ops/sec for divide method of BigInteger
> > > >
> > > > Number Current fixed one
> > > > of digits version
> > > >
> > > > 2 5247 6315
> > > > 4 4623 6497
> > > > 8 5560 7491
> > > > 12 838 838
> > > > 16 2533 2063
> > > > 24 1689 1717
> > > > 32 2397 2494
> > > > 48 2143 2131
> > > > 64 613 525
> > > > 128 1399 1418
> > > >
> > > > Ops/sec for subtract method of BigInteger
> > > >
> > > > Number Current fixed one
> > > > of digits version
> > > >
> > > > 2 3920 4394
> > > > 4 3300 3302
> > > > 8 5178 5640
> > > > 12 957 913
> > > > 16 3794 2904
> > > > 24 2057 1962
> > > > 32 3421 3241
> > > > 48 3469 2828
> > > > 64 652 610
> > > > 128 2318 2246
> > > >
> > > > ===
> > > >
> > > > Unfortunately we haven't look thoroughly to ITC contribution, so it
> > > > may happen that some of the optimizations described in this letter
> > > > were already implemented there. Daniel, could you please consider our
> > > > new implementation when you start to merge implementations math
> > > > packages. If optimization methods described above already have been
> > > > implemented in ITC contribution it will be great to compare internal
> > > > representation of BigInteger and try to measure affect of different
> > > > approaches.
> > > >
> > > >
> > > >
> > > >
> > > > On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> > > > > [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
> > > > >
> > > > > Vladimir Strigun updated HARMONY-551:
> > > > > -------------------------------------
> > > > >
> > > > > Attachment: Harmony-551.diffs
> > > > >
> > > > > Please try my patch.
> > > > > Several features were added:
> > > > > - special handling for small value
> > > > > - frequently used constans were cached
> > > > > - several methods were modified and optimized for small value.
> > > > > etc.
> > > > >
> > > > > > [classlib][java.math] performance improvement for java.math package
> > > > > > -------------------------------------------------------------------
> > > > > >
> > > > > > Key: HARMONY-551
> > > > > > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > > > > > Project: Harmony
> > > > > > Type: Improvement
> > > > >
> > > > > > Components: Classlib
> > > > > > Reporter: Vladimir Strigun
> > > > > > Attachments: Harmony-551.diffs
> > > > > >
> > > > > > Performance improvement for BigDecimal and BigInteger classes.
> > > > > > I will attach patch soon.
> > > > >
> > > > > --
> > > > > This message is automatically generated by JIRA.
> > > > > -
> > > > > If you think it was sent incorrectly contact one of the administrators:
> > > > > http://issues.apache.org/jira/secure/Administrators.jspa
> > > > > -
> > > > > For more information on JIRA, see:
> > > > > http://www.atlassian.com/software/jira
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][java.math]performance improvement for java.math package
Posted by Mikhail Loenko <ml...@gmail.com>.
I think they are not unit tests and should go to a different
(performance?) test
suite. Right now we don't have one but it seems to be time to create it
Thanks,
Mikhail
2006/6/20, Vladimir Strigun <vs...@gmail.com>:
> Hi Mikhail,
>
> AFAIK, we haven't such kind of tests in svn yet. It's hard to define
> best place for it, but since this suite is intended for java.math
> testing only and it's implementation-independent tests, I believe
> modules/math/src/test/java/tests/api is appropriate place. If you
> agree with this I will create patch for suite, add copyright and
> change package definition of classes.
>
> What do you think about it?
>
> Thanks,
> Vladimir.
>
> On 6/13/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Hi Vladimir
> >
> > What do you think the most appropriate location and suite for the tests
> > in the HARMONY-551 are?
> >
> > Thanks,
> > Mikhail
> >
> > 2006/6/2, Vladimir Strigun <vs...@gmail.com>:
> > > Our team has done some analysis of current Harmony implementation of
> > > java.math package. The implementation was considered from the
> > > performance point of view and I'd like to share results of our work
> > > with you.
> > >
> > > The analysis and tuning was made from the enterprise-level
> > > applications point of view which are known to use BigInteger and
> > > BigDecimal for storing numeric information. In most cases the numbers
> > > there fit well within 32 bits. So coming from the BigDecimal
> > > perspective which is really important for these applications and
> > > taking into account some specifics (small numbers) we made some
> > > optimizations in both BigDecimal and BigInteger. The latter was tuned
> > > specifically for BigDecimal:
> > >
> > > - Special handling for small numbers (fit within 32 bit) was added to
> > > all methods
> > > - Frequently used constants (0..10) were cached and reused by valueOf
> > > method (no need to create a new instance of BigInteger)
> > > - as well as were powers of 10 (0..10)
> > > - methods add(), divide(), divideAndRemainer() in BigInteger were
> > > optimized for short values if both arguments can fit in 32 bits the
> > > resulting BigInteger is created by valueOf method.
> > >
> > >
> > > If we consider enterprise level applications, we can imagine that
> > > toString() method is also frequently used. The method was analyzed and
> > > as a result we combined toString() methods in BigDecimal and
> > > BigInteger to one unified method in BigInteger. Method
> > > BigInteger.toDecimalScaledString(int scale) now is used from both
> > > BigInteger and BigDecimal. This way allows reducing amount of created
> > > objects and data copying. In addition, size calculation was modified
> > > for resulting array. In the new implementation the size is calculated
> > > with less precision. Because allocated char array will be copied into
> > > String and collected by GC after toString() then it is not a problem
> > > if the allocated char array will be slightly bigger then necessary.
> > >
> > > I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
> > >
> > > We also have created a set of micro benchmarks (which I'll to attach
> > > to JIRA as well) which shows that our special-case handling doesn't
> > > break the performance for other cases and we do not degrade in common,
> > > and, of course, all unit tests pass with new version. Below you can
> > > find several comparisons in performance between current version and
> > > the fixed one.
> > >
> > > ===
> > >
> > > Ops/sec for toString() method of BigDecimal
> > >
> > > Number Current fixed one
> > > of digits version
> > > 2 1121 5354
> > > 4 774 7514
> > > 8 615 6748
> > > 12 743 5543
> > > 16 623 4494
> > > 24 389 4895
> > > 32 306 3496
> > > 48 232 5815
> > > 64 224 3761
> > > 128 91 87
> > >
> > > Ops/sec for divide method of BigInteger
> > >
> > > Number Current fixed one
> > > of digits version
> > >
> > > 2 5247 6315
> > > 4 4623 6497
> > > 8 5560 7491
> > > 12 838 838
> > > 16 2533 2063
> > > 24 1689 1717
> > > 32 2397 2494
> > > 48 2143 2131
> > > 64 613 525
> > > 128 1399 1418
> > >
> > > Ops/sec for subtract method of BigInteger
> > >
> > > Number Current fixed one
> > > of digits version
> > >
> > > 2 3920 4394
> > > 4 3300 3302
> > > 8 5178 5640
> > > 12 957 913
> > > 16 3794 2904
> > > 24 2057 1962
> > > 32 3421 3241
> > > 48 3469 2828
> > > 64 652 610
> > > 128 2318 2246
> > >
> > > ===
> > >
> > > Unfortunately we haven't look thoroughly to ITC contribution, so it
> > > may happen that some of the optimizations described in this letter
> > > were already implemented there. Daniel, could you please consider our
> > > new implementation when you start to merge implementations math
> > > packages. If optimization methods described above already have been
> > > implemented in ITC contribution it will be great to compare internal
> > > representation of BigInteger and try to measure affect of different
> > > approaches.
> > >
> > >
> > >
> > >
> > > On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> > > > [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
> > > >
> > > > Vladimir Strigun updated HARMONY-551:
> > > > -------------------------------------
> > > >
> > > > Attachment: Harmony-551.diffs
> > > >
> > > > Please try my patch.
> > > > Several features were added:
> > > > - special handling for small value
> > > > - frequently used constans were cached
> > > > - several methods were modified and optimized for small value.
> > > > etc.
> > > >
> > > > > [classlib][java.math] performance improvement for java.math package
> > > > > -------------------------------------------------------------------
> > > > >
> > > > > Key: HARMONY-551
> > > > > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > > > > Project: Harmony
> > > > > Type: Improvement
> > > >
> > > > > Components: Classlib
> > > > > Reporter: Vladimir Strigun
> > > > > Attachments: Harmony-551.diffs
> > > > >
> > > > > Performance improvement for BigDecimal and BigInteger classes.
> > > > > I will attach patch soon.
> > > >
> > > > --
> > > > This message is automatically generated by JIRA.
> > > > -
> > > > If you think it was sent incorrectly contact one of the administrators:
> > > > http://issues.apache.org/jira/secure/Administrators.jspa
> > > > -
> > > > For more information on JIRA, see:
> > > > http://www.atlassian.com/software/jira
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][java.math]performance improvement for java.math package
Posted by Vladimir Strigun <vs...@gmail.com>.
Hi Mikhail,
AFAIK, we haven't such kind of tests in svn yet. It's hard to define
best place for it, but since this suite is intended for java.math
testing only and it's implementation-independent tests, I believe
modules/math/src/test/java/tests/api is appropriate place. If you
agree with this I will create patch for suite, add copyright and
change package definition of classes.
What do you think about it?
Thanks,
Vladimir.
On 6/13/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Hi Vladimir
>
> What do you think the most appropriate location and suite for the tests
> in the HARMONY-551 are?
>
> Thanks,
> Mikhail
>
> 2006/6/2, Vladimir Strigun <vs...@gmail.com>:
> > Our team has done some analysis of current Harmony implementation of
> > java.math package. The implementation was considered from the
> > performance point of view and I'd like to share results of our work
> > with you.
> >
> > The analysis and tuning was made from the enterprise-level
> > applications point of view which are known to use BigInteger and
> > BigDecimal for storing numeric information. In most cases the numbers
> > there fit well within 32 bits. So coming from the BigDecimal
> > perspective which is really important for these applications and
> > taking into account some specifics (small numbers) we made some
> > optimizations in both BigDecimal and BigInteger. The latter was tuned
> > specifically for BigDecimal:
> >
> > - Special handling for small numbers (fit within 32 bit) was added to
> > all methods
> > - Frequently used constants (0..10) were cached and reused by valueOf
> > method (no need to create a new instance of BigInteger)
> > - as well as were powers of 10 (0..10)
> > - methods add(), divide(), divideAndRemainer() in BigInteger were
> > optimized for short values if both arguments can fit in 32 bits the
> > resulting BigInteger is created by valueOf method.
> >
> >
> > If we consider enterprise level applications, we can imagine that
> > toString() method is also frequently used. The method was analyzed and
> > as a result we combined toString() methods in BigDecimal and
> > BigInteger to one unified method in BigInteger. Method
> > BigInteger.toDecimalScaledString(int scale) now is used from both
> > BigInteger and BigDecimal. This way allows reducing amount of created
> > objects and data copying. In addition, size calculation was modified
> > for resulting array. In the new implementation the size is calculated
> > with less precision. Because allocated char array will be copied into
> > String and collected by GC after toString() then it is not a problem
> > if the allocated char array will be slightly bigger then necessary.
> >
> > I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
> >
> > We also have created a set of micro benchmarks (which I'll to attach
> > to JIRA as well) which shows that our special-case handling doesn't
> > break the performance for other cases and we do not degrade in common,
> > and, of course, all unit tests pass with new version. Below you can
> > find several comparisons in performance between current version and
> > the fixed one.
> >
> > ===
> >
> > Ops/sec for toString() method of BigDecimal
> >
> > Number Current fixed one
> > of digits version
> > 2 1121 5354
> > 4 774 7514
> > 8 615 6748
> > 12 743 5543
> > 16 623 4494
> > 24 389 4895
> > 32 306 3496
> > 48 232 5815
> > 64 224 3761
> > 128 91 87
> >
> > Ops/sec for divide method of BigInteger
> >
> > Number Current fixed one
> > of digits version
> >
> > 2 5247 6315
> > 4 4623 6497
> > 8 5560 7491
> > 12 838 838
> > 16 2533 2063
> > 24 1689 1717
> > 32 2397 2494
> > 48 2143 2131
> > 64 613 525
> > 128 1399 1418
> >
> > Ops/sec for subtract method of BigInteger
> >
> > Number Current fixed one
> > of digits version
> >
> > 2 3920 4394
> > 4 3300 3302
> > 8 5178 5640
> > 12 957 913
> > 16 3794 2904
> > 24 2057 1962
> > 32 3421 3241
> > 48 3469 2828
> > 64 652 610
> > 128 2318 2246
> >
> > ===
> >
> > Unfortunately we haven't look thoroughly to ITC contribution, so it
> > may happen that some of the optimizations described in this letter
> > were already implemented there. Daniel, could you please consider our
> > new implementation when you start to merge implementations math
> > packages. If optimization methods described above already have been
> > implemented in ITC contribution it will be great to compare internal
> > representation of BigInteger and try to measure affect of different
> > approaches.
> >
> >
> >
> >
> > On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> > > [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
> > >
> > > Vladimir Strigun updated HARMONY-551:
> > > -------------------------------------
> > >
> > > Attachment: Harmony-551.diffs
> > >
> > > Please try my patch.
> > > Several features were added:
> > > - special handling for small value
> > > - frequently used constans were cached
> > > - several methods were modified and optimized for small value.
> > > etc.
> > >
> > > > [classlib][java.math] performance improvement for java.math package
> > > > -------------------------------------------------------------------
> > > >
> > > > Key: HARMONY-551
> > > > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > > > Project: Harmony
> > > > Type: Improvement
> > >
> > > > Components: Classlib
> > > > Reporter: Vladimir Strigun
> > > > Attachments: Harmony-551.diffs
> > > >
> > > > Performance improvement for BigDecimal and BigInteger classes.
> > > > I will attach patch soon.
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > If you think it was sent incorrectly contact one of the administrators:
> > > http://issues.apache.org/jira/secure/Administrators.jspa
> > > -
> > > For more information on JIRA, see:
> > > http://www.atlassian.com/software/jira
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][java.math]performance improvement for java.math package
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Vladimir
What do you think the most appropriate location and suite for the tests
in the HARMONY-551 are?
Thanks,
Mikhail
2006/6/2, Vladimir Strigun <vs...@gmail.com>:
> Our team has done some analysis of current Harmony implementation of
> java.math package. The implementation was considered from the
> performance point of view and I'd like to share results of our work
> with you.
>
> The analysis and tuning was made from the enterprise-level
> applications point of view which are known to use BigInteger and
> BigDecimal for storing numeric information. In most cases the numbers
> there fit well within 32 bits. So coming from the BigDecimal
> perspective which is really important for these applications and
> taking into account some specifics (small numbers) we made some
> optimizations in both BigDecimal and BigInteger. The latter was tuned
> specifically for BigDecimal:
>
> - Special handling for small numbers (fit within 32 bit) was added to
> all methods
> - Frequently used constants (0..10) were cached and reused by valueOf
> method (no need to create a new instance of BigInteger)
> - as well as were powers of 10 (0..10)
> - methods add(), divide(), divideAndRemainer() in BigInteger were
> optimized for short values if both arguments can fit in 32 bits the
> resulting BigInteger is created by valueOf method.
>
>
> If we consider enterprise level applications, we can imagine that
> toString() method is also frequently used. The method was analyzed and
> as a result we combined toString() methods in BigDecimal and
> BigInteger to one unified method in BigInteger. Method
> BigInteger.toDecimalScaledString(int scale) now is used from both
> BigInteger and BigDecimal. This way allows reducing amount of created
> objects and data copying. In addition, size calculation was modified
> for resulting array. In the new implementation the size is calculated
> with less precision. Because allocated char array will be copied into
> String and collected by GC after toString() then it is not a problem
> if the allocated char array will be slightly bigger then necessary.
>
> I've attached the changes we made for BigInteger and BigDecimal to Harmony-551
>
> We also have created a set of micro benchmarks (which I'll to attach
> to JIRA as well) which shows that our special-case handling doesn't
> break the performance for other cases and we do not degrade in common,
> and, of course, all unit tests pass with new version. Below you can
> find several comparisons in performance between current version and
> the fixed one.
>
> ===
>
> Ops/sec for toString() method of BigDecimal
>
> Number Current fixed one
> of digits version
> 2 1121 5354
> 4 774 7514
> 8 615 6748
> 12 743 5543
> 16 623 4494
> 24 389 4895
> 32 306 3496
> 48 232 5815
> 64 224 3761
> 128 91 87
>
> Ops/sec for divide method of BigInteger
>
> Number Current fixed one
> of digits version
>
> 2 5247 6315
> 4 4623 6497
> 8 5560 7491
> 12 838 838
> 16 2533 2063
> 24 1689 1717
> 32 2397 2494
> 48 2143 2131
> 64 613 525
> 128 1399 1418
>
> Ops/sec for subtract method of BigInteger
>
> Number Current fixed one
> of digits version
>
> 2 3920 4394
> 4 3300 3302
> 8 5178 5640
> 12 957 913
> 16 3794 2904
> 24 2057 1962
> 32 3421 3241
> 48 3469 2828
> 64 652 610
> 128 2318 2246
>
> ===
>
> Unfortunately we haven't look thoroughly to ITC contribution, so it
> may happen that some of the optimizations described in this letter
> were already implemented there. Daniel, could you please consider our
> new implementation when you start to merge implementations math
> packages. If optimization methods described above already have been
> implemented in ITC contribution it will be great to compare internal
> representation of BigInteger and try to measure affect of different
> approaches.
>
>
>
>
> On 6/2/06, Vladimir Strigun (JIRA) <ji...@apache.org> wrote:
> > [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
> >
> > Vladimir Strigun updated HARMONY-551:
> > -------------------------------------
> >
> > Attachment: Harmony-551.diffs
> >
> > Please try my patch.
> > Several features were added:
> > - special handling for small value
> > - frequently used constans were cached
> > - several methods were modified and optimized for small value.
> > etc.
> >
> > > [classlib][java.math] performance improvement for java.math package
> > > -------------------------------------------------------------------
> > >
> > > Key: HARMONY-551
> > > URL: http://issues.apache.org/jira/browse/HARMONY-551
> > > Project: Harmony
> > > Type: Improvement
> >
> > > Components: Classlib
> > > Reporter: Vladimir Strigun
> > > Attachments: Harmony-551.diffs
> > >
> > > Performance improvement for BigDecimal and BigInteger classes.
> > > I will attach patch soon.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> > http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> > http://www.atlassian.com/software/jira
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org