harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: ITC's java.math package contribution
Date Sun, 23 Apr 2006 11:50:40 GMT
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 <dfridlender@gmail.com>:
> 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 <vvgorr@gmail.com> 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 <geir@pobox.com> 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:dfridlender@gmail.com]
> > > >
> > > >> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > >
> > > >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message