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

Reply via email to