+1 for the combined version
2006/8/3, Vladimir Strigun <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
