harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Fridlender" <dfridlen...@gmail.com>
Subject Re: [classlib][java.math] combination of math packages
Date Wed, 02 Aug 2006 17:54:37 GMT
Vladimir,

thank you very much for reviewing H-935 and improving it.  It shows
significantly better performance for BigDecimal that fit in 64 bits
with no harm for the remaining cases.

I agree with the changes you have made and are willing to continue
improving our common math from now on.

Thanks a lot!

Daniel


On 8/1/06, Vladimir Strigun <vstrigun@gmail.com> wrote:
> Daniel,
>
> Thank you for the new optimized version. We've analyzed your version
> and found it's very good. We can accept you version as default for
> Harmony but we'd like to add some improvements. :)
>
> I've updated H-935 and attach diffs for your code. We added
> optimization for small BigDecimal's objects. Our patch doesn't break
> your design covers the following issues:
> - reduce amount of object created during initialization of BigDecimal.
> In our version we don't use BigInteger during BigDecimal creation for
> small values.
> - cached values for powers of tens and for powers of five were added.
> - additional branches in all calculation methods for supporting small
> value calculations as well.
> - toDecimalScaledString method was added to Conversion class. The
> method is intended only for processing 32-bits numbers.
>
> I've attached small micro bench that shows boost for BigDecimal that
> fits to 64 bits. I should mention that we can't see any degradation in
> all other performance tests with our patch.
>
> Daniel, could you please review our patch? If you agree with suggested
> changes, I believe we all will vote +1 for our common math :)
>
> Thanks,
> Vladimir.
>
>
> --
> Vladimir Strigun,
> Intel Middleware Product Division
>
>
>
> On 7/21/06, Daniel Fridlender <dfridlender@gmail.com> wrote:
> > Dear all,
> >
> > On behalf of ITC, I have submitted as H-935 a new implementation of
> > java.math combining previously donated implementations.  It includes
> > what we think are the best features of H-380 (donated by Intel) and
> > the best features of H-199 (donated by ITC).  We have also fixed some
> > bugs from both implementations and done some further optimizations on
> > methods from both of them.
> >
> > We have also included a few optimizations from H-551, we expect to
> > include the remaining optimizations soon.  We have also improved the
> > performance test suite from H-551 and included further tests, among
> > them realistic applications from cryptography.  Check the README file
> > included in the package mathPerformanceTestsUpdate.zip (H-935) for
> > some more details about the new features of the test suite.
> >
> > A sample of the output obtained with the performance test suite can be
> > found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html
> >
> > A comparative analysis on a method-by-method basis between H-380 and
> > H-199 can be found at
> > http://www.fitc.unc.edu.ar/javadev/math/docs.html
> >
> > We will include further documentation soon.  In the meantime, a brief
> > description of the main issues follows:
> >
> > Internal representation of BigInteger: taken from H-380
> > (Sign-magnitude representation).
> > Design: taken from H-199 (well-defined static libraries grouped by
> > functionality).
> > Serialization: taken from H-380 (it was not implemented in H-199).
> >
> > Most methods and constructors were taken from one of the previous
> > donations and then tuned for consistency with the internal
> > representation, for bug removal and for further optimizations.  Very
> > often large parts were reprogrammed (e.g.: shiftRight, bitLength,
> > bitCount, not, setTrueCoded, modInverse, and many more).
> >
> > Nevertheless we can roughly say that the new version started by taking:
> >
> > 1) Methods of BigDecimal: most of them from H-199 because of efficiency.
> > 2) Representation-dependent methods of BigInteger: most of them from H-380.
> > 3) Representation-independent methods of BigInteger: most of them from
> > H-199 for efficiency.
> > 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf,
> > BigDecimal.valueOf, etc.  We also took their performance test suite,
> > improve it and added further benchmarks.
> >
> > We plan to introduce remaining optimizations from H-551 and to
> > optimize other methods (modPow, modInverse, nextProbablePrime, etc.)
> > in order to bridge the gap in efficiency with the RI.
> >
> > Best regards,
> >
> > Daniel Fridlender
> > ITC
> >
> > http://issues.apache.org/jira/browse/HARMONY-935
> >
> > ---------------------------------------------------------------------
> > 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


Mime
View raw message