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]
