You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Daniel Fridlender <df...@gmail.com> on 2006/04/20 21:51:31 UTC
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
Re: ITC's java.math package contribution
Posted by Daniel Fridlender <df...@gmail.com>.
Hi Stefano,
I would be really surprised if a change in the VM has a significative
impact on the relative performance of the two implementations. The
difference in performance is due to the internal representation and to
the implemented algorithms. But sure, it would be interesting to
compare them on other VMs, thanks!
Regards,
Daniel Fridlender
On 4/21/06, Stefano Mazzocchi <st...@apache.org> wrote:
> Daniel Fridlender wrote:
> > Hi Vladimir,
> >
> > Yes, I can make our results public of course. We have tested both
> > implementations for RSA key generation, which is a mix of random prime
> > generation and modular arithmetic (such as multiplicative inverse
> > calculation).
> > The testing platform was:
> >
> > CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz
> > Cache size: 512 KB
> > Total Mem: 1035492 KB
> > OS: Linux kernel 2.6.11-6mdk #1
> > JDK: SUN Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
> > JCE Provider: Bouncy Castle release 1.30
> >
> > We obtained the following results for keys of length 512, 1024 and
> > 2048 bits. The figures are the average of 20, 15 and 5 iterations
> > respectively.
> >
> > HARMONY-39
> > 512 bits: 231.22 ms
> > 1024 bits: 3361.98 ms
> > 2048 bits: 37620.38 ms
> >
> > HARMONY-199
> > 512 bits: 149.05 ms
> > 1024 bits: 1245.45 ms
> > 2048 bits: 16826.24 ms
> >
> > We also tested encrytping and decrypting, but in that case there were
> > no significative differences between the implementations.
>
> have you tried on other JVMs? (I wouldn't want the optimizations to be
> tied to the way Sun's hotspot does things)
>
> --
> Stefano.
>
>
> ---------------------------------------------------------------------
> 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
Re: ITC's java.math package contribution
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fridlender wrote:
> Hi Vladimir,
>
> Yes, I can make our results public of course. We have tested both
> implementations for RSA key generation, which is a mix of random prime
> generation and modular arithmetic (such as multiplicative inverse
> calculation).
> The testing platform was:
>
> CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz
> Cache size: 512 KB
> Total Mem: 1035492 KB
> OS: Linux kernel 2.6.11-6mdk #1
> JDK: SUN Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
> JCE Provider: Bouncy Castle release 1.30
>
> We obtained the following results for keys of length 512, 1024 and
> 2048 bits. The figures are the average of 20, 15 and 5 iterations
> respectively.
>
> HARMONY-39
> 512 bits: 231.22 ms
> 1024 bits: 3361.98 ms
> 2048 bits: 37620.38 ms
>
> HARMONY-199
> 512 bits: 149.05 ms
> 1024 bits: 1245.45 ms
> 2048 bits: 16826.24 ms
>
> We also tested encrytping and decrypting, but in that case there were
> no significative differences between the implementations.
have you tried on other JVMs? (I wouldn't want the optimizations to be
tied to the way Sun's hotspot does things)
--
Stefano.
---------------------------------------------------------------------
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
Re: ITC's java.math package contribution
Posted by Daniel Fridlender <df...@gmail.com>.
Hi Vladimir,
Yes, I can make our results public of course. We have tested both
implementations for RSA key generation, which is a mix of random prime
generation and modular arithmetic (such as multiplicative inverse
calculation).
The testing platform was:
CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz
Cache size: 512 KB
Total Mem: 1035492 KB
OS: Linux kernel 2.6.11-6mdk #1
JDK: SUN Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
JCE Provider: Bouncy Castle release 1.30
We obtained the following results for keys of length 512, 1024 and
2048 bits. The figures are the average of 20, 15 and 5 iterations
respectively.
HARMONY-39
512 bits: 231.22 ms
1024 bits: 3361.98 ms
2048 bits: 37620.38 ms
HARMONY-199
512 bits: 149.05 ms
1024 bits: 1245.45 ms
2048 bits: 16826.24 ms
We also tested encrytping and decrypting, but in that case there were
no significative differences between the implementations.
Regards,
Daniel Fridlender
On 4/20/06, Vladimir Gorr <vv...@gmail.com> wrote:
> Hi Daniel,
>
> indeed it makes sense to compare the performance both implementations of
> java.math package
> using the real applications. If you have any results could you plase to make
> them public?
> I want to look at them. Besides I'd pefer to slightly correct you about the
> SVN repository already contains full implemenation of the java.math package
> for Java 1.5 (please look at the HARMONY-380 issue for details).
>
> Thanks,
> Vladimir Gorr
> Intel Middleware Products Division.
>
>
> On 4/21/06, Daniel Fridlender <df...@gmail.com> wrote:
> >
> > 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
Re: ITC's java.math package contribution
Posted by Vladimir Gorr <vv...@gmail.com>.
Hi Daniel,
indeed it makes sense to compare the performance both implementations of
java.math package
using the real applications. If you have any results could you plase to make
them public?
I want to look at them. Besides I'd pefer to slightly correct you about the
SVN repository already contains full implemenation of the java.math package
for Java 1.5 (please look at the HARMONY-380 issue for details).
Thanks,
Vladimir Gorr
Intel Middleware Products Division.
On 4/21/06, Daniel Fridlender <df...@gmail.com> wrote:
>
> 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
>
>
Re: ITC's java.math package contribution
Posted by Daniel Fridlender <df...@gmail.com>.
Hi Geir,
The 1.5 spec includes an Enum which is used in BigDecimal.
But we surely can compile to 1.4 bytecode the part of the
implementation that corresponds to the 1.4 API.
Regards,
Daniel Fridlender
On 4/21/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Daniel Fridlender wrote:
> > 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.
>
> Nice! Performance is good!
>
> >
> > 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.
>
> Great - can we compile down to 1.4 bytecode?
>
> geir
>
> ---------------------------------------------------------------------
> 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
Re: ITC's java.math package contribution
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Daniel Fridlender wrote:
> 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.
Nice! Performance is good!
>
> 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.
Great - can we compile down to 1.4 bytecode?
geir
---------------------------------------------------------------------
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