Hi Elena, thank you very much for having a look at our contribution and reporting the results of your tests. We have also done some method-by-method comparisons, our results were similar to yours.
I agree with you that the difference in performance in methods of BigInteger is due to the internal representation and to the implemented algorithms. Regards, Daniel Fridlender On 4/21/06, Semukhina, Elena V <[EMAIL PROTECTED]> wrote: > Hi Daniel, > > > > I've taken a look at ITC's implementation of java.math (original > Harmony-199 donation) and tried to compare it to one donated by > Harmony-39 on the method-by-method base. > > For example, I've tested about 30 BigInteger's methods and the result is > the following: > > > > - 10 ITC's methods are slower, > > - 5 methods are approximately the same in both implementations, > > - 14 ITC's methods are faster. > > > > This is determined either by internal representation (which is different > in both implementations) or algorithmically. > > On the other hand, I must admit that ITC's BigDecimal arithmetic is > faster while, for example, toString() is slower for the values I've > randomly chosen. > > > > I agree with you that real performance advantages should be demonstrated > by real applications. > > > > On the whole, the package is well designed and the code quality is good. > > > The disadvantage I've noticed is unimplemented serialization but this > could be easily eliminated. > > > > Regards, > > Elena Semukhina > > Intel Middleware Products Division > > > > >-----Original Message----- > > >From: Daniel Fridlender [mailto:[EMAIL PROTECTED] > > >Sent: Friday, April 21, 2006 2:52 AM > > >To: harmony-dev@incubator.apache.org > > >Subject: ITC's java.math package contribution > > > > > >Dear all, > > > > > >on behalf of ITC I have updated our contribution of the package > > >java.math including some recent optimizations (HARMONY-199). I think > > >it would be interesting to compare our implementation with the one > > >donated by Intel (HARMONY-39). In order to do that, it would be nice > > >to have a collection of applications were the package is used. > > > > > >So far, we have tried both implementations with a realistic > > >application (RSA key generation) and our implementation turned out to > > >have a significantly better performance. > > > > > >Another point is that we implemented the full 1.5 API functionality, > > >which in the case of BigDecimal amounts to having about twice as many > > >methods as in the 1.4.2 API. This may have little significance now, > > >but it will definitely be important when Harmony moves to 1.5 > > > > > >Our implementation uses 1.5 syntax since the 1.5 API includes an Enum > > >(RoundingMode). > > >It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API > from > > >it. > > > > > >Some more information about our development can be found at > > >http://www.fitc.unc.edu.ar/javadev/math/ > > > > > >Daniel Fridlender > > > > > >--------------------------------------------------------------------- > > >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]
