If we will combine on ideas level new implementaion of java.math should appear. Both implementations use the D. Knuth's algorithms and nothing new. Yes, we can take the Big Decimal from HARMONY-199 and Big Integer from HARMONY-39 (or vice versa) and measure the performance. Other approach is to improve the performance of some methods where it is worse. It's not clear what will be better as a result.
Thanks, Vladimir. On 4/23/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > I think it should be possible to combine on ideas level, not just the > code. > > You may want to look at your counterpart's code from the following > perspective: > which ideas, tips, algorithms would you take to your code? > > Once we figured that out I think it would be easier to define next steps. > > Thanks, > Mikhail > > 2006/4/23, Daniel Fridlender <[EMAIL PROTECTED]>: > > Hi Vladimir, > > > > We implemented BigDecimal using only public features of BigInteger, so > > that we can certainly combine our implementation of BigDecimal with > > HARMONY-39 (or any other) implementation of BigInteger. > > > > But I agree with you that there seems to be no easy way of combining > > both implementations of BigInteger due to their different internal > > representation. The only way would be to re-implement good ideas from > > one implementation into the other one. We want to further optimize > > our implementation, so we would be happy to do that. > > > > I also agree with you that it would be really nice to have a > > representative collection of realistic applications of the > > functionality of java.math. RSA key generation is definitely one of > > them. We should find more. That would also help us identifying > > methods that are critical for the performance in practice, thus > > methods that are worth optimizing further. > > > > Regards, > > > > Daniel Fridlender > > > > On 4/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > > > Hi Geir, > > > > > > Unfortunately both implementations have different internal > representation. > > > Therefore all algorithms have been implemented in accordance with > them. > > > I see no way to integrate them. > > > > > > I'd also like to note it's insufficiently to measure the performance > > > using only one of the real applications and one of VMs. We know > > > some of methods for HARMONY-39 contribution have better performance > > > in comparing with HARMONY-199. It means (in my opinion) it's not a > fact > > > that other applications will not show worse performance for one or > other > > > implementation. > > > > > > Clearly, that we should make a choice once. What will we do if there > are 50% > > > of voices against 50%? > > > For any of the forthcoming contributions but not only for ones > discussed in > > > this thread. > > > > > > Thanks, > > > Vladimir Gorr > > > Intel Middleware Products Division. > > > > > > On 4/21/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > This is great stuff. It will be fun to integrate all of this > together > > > > to get the best of both. > > > > > > > > Now, with that happy and positive yet blatantly naive statement out > > > > there... > > > > > > > > How monolithic are these implementations? Will it even be possible > to > > > > integrate, or do the internals reflect enough difference in approach > > > > that it will be one or the other? > > > > > > > > geir > > > > > > > > > > > > Semukhina, Elena V 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.2API > > > > > 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] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > >
