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 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 :
> > 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) 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