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/08/01 13:24:38 UTC
Re: [classlib][java.math] combination of math packages
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 <df...@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
Re: [classlib][java.math] combination of math packages
Posted by Mikhail Loenko <ml...@gmail.com>.
+1 for the combined version
2006/8/3, Vladimir Strigun <vs...@gmail.com>:
> Daniel,
>
> thank you for the analysis of our patch. Now I think we all should
> vote for our combined version and put it to SVN as default one.
>
> Thanks,
> Vladimir.
>
> On 8/2/06, Daniel Fridlender <df...@gmail.com> wrote:
> > 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 <vs...@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 <df...@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
> >
> >
>
> ---------------------------------------------------------------------
> 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] combination of math packages
Posted by Stefano Mazzocchi <st...@apache.org>.
Vladimir Strigun wrote:
> Daniel,
>
> thank you for the analysis of our patch. Now I think we all should
> vote for our combined version and put it to SVN as default one.
+1
and a big applause for all the parties involved in this merge: it is an
amazing example of why open development and cooperation make the unity
more than the sum of its parts.
Well done!
--
Stefano.
---------------------------------------------------------------------
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] combination of math packages
Posted by Vladimir Strigun <vs...@gmail.com>.
Daniel,
thank you for the analysis of our patch. Now I think we all should
vote for our combined version and put it to SVN as default one.
Thanks,
Vladimir.
On 8/2/06, Daniel Fridlender <df...@gmail.com> wrote:
> 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 <vs...@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 <df...@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
>
>
---------------------------------------------------------------------
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] combination of math packages
Posted by Daniel Fridlender <df...@gmail.com>.
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 <vs...@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 <df...@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