harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Semukhina, Elena V" <elena.v.semukh...@intel.com>
Subject RE: ITC's java.math package contribution
Date Mon, 24 Apr 2006 05:55:20 GMT
I'd like to confirm that BigDecimal's methods can be easily combined to
get a new version that implements the best approaches from both
implementations. The ITC's optimized "ten powering" is very fruitful and
contributes significantly to the arithmetic methods performance. On the
other hand, Intel's toString() and toEngineeringString() look a little
bit better. 

As for BigInteger, some methods which don't rely on the internal
representation can be replaced as well. I mean, for example, gcd() or
modInverse(). Such methods should be compared and the best can be
chosen.

BTW, such multistep operations are usually time consuming and the
approach that allows speeding them up is described in the "Effective
Java" by J. Bloch. I think a similar idea has been implemented by ITC in
their "in place" operations in BigInteger. 

Thanks,
Elena 

>-----Original Message-----
>From: Vladimir Gorr [mailto:vvgorr@gmail.com]
>Sent: Sunday, April 23, 2006 7:28 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: ITC's java.math package contribution
>
>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 <mloenko@gmail.com> 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 <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.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:
>> 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
>>
>>

---------------------------------------------------------------------
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