Re: [classlib][java.math] combination of math packages
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]
Re: [classlib][java.math] combination of math packages
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]
Re: [classlib][java.math] combination of math packages
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][java.math] combination of math packages
+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
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 [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]
Re: [classlib][java.math] combination of math packages
cool! 2006/7/21, Daniel Fridlender [EMAIL PROTECTED]: 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]
Re: [classlib][java.math] combination of math packages
Excellent. Maybe we can put this dual math thing to bed? Daniel Fridlender 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]
