Re: Python and GMP.

2009-04-21 Thread casevh
On Apr 21, 5:47 am, Paul Rubin wrote: > casevh writes: > > > Could you test pow(a,b,c) where a,b,c are each 300 decimal digits? > > > $ py25 -m timeit -s  "a=long('23'*150);b=long('47'*150);m=long > > ('79'*150)" "c=pow(a,b,m)" > > 10 loops, best of 3: 52.7 msec per

Re: Python and GMP.

2009-04-21 Thread Paul Rubin
casevh writes: > > Could you test pow(a,b,c) where a,b,c are each 300 decimal digits? > > $ py25 -m timeit -s "a=long('23'*150);b=long('47'*150);m=long > ('79'*150)" "c=pow(a,b,m)" > 10 loops, best of 3: 52.7 msec per loop > $ py31 -m timeit -s > 100 loops, best of 3: 8.85 msec per loop > $

Re: Python and GMP.

2009-04-21 Thread Paul Rubin
alessiogiovanni.bar...@gmail.com writes: > > Could you test pow(a,b,c) where a,b,c are each 300 decimal digits? > > This is an important operation in cryptography, that GMP is carefully > > optimized for.  Thanks. > > Ok, thanks for your answers. I understand the problems of licensing, > but we co

Re: Python and GMP.

2009-04-21 Thread casevh
On Apr 21, 12:11 am, Paul Rubin wrote: > casevh writes: > > Python 3.1 is significantly faster than Python 2.x on 64-bit > > platforms. The following times are for multiplication with 2, 30 and > > 300 decimal digits. > > Could you test pow(a,b,c) where a,b,c are eac

Re: Python and GMP.

2009-04-21 Thread Mark Dickinson
On Apr 21, 12:04 pm, bearophileh...@lycos.com wrote: > Using inline ASM in Python sources isn't an option. Except when it is. :) There's a tiny amount of inline assembler in the sources already: see Python/pymath.c and Python/ceval.c. Not surprisingly, there's some in the ctypes module as well.

Re: Python and GMP.

2009-04-21 Thread bearophileHUGS
casevh: > Testing 2 digits. This primarily measures the overhead for call GMP > via an extension module. > ... Thank you for adding some actual data to the whole discussion :-) If you perform similar benchmarks with Bigints of Java you will see how much slower they are compared to the Python ones.

Re: Python and GMP.

2009-04-21 Thread Mark Dickinson
On Apr 21, 8:57 am, alessiogiovanni.bar...@gmail.com wrote: > Ok, thanks for your answers. I understand the problems of licensing, > but > we could to learn from GMP's source code to improve the Python's int > implementation, > mainly because, GMP is very fast. We could violate the GPL? Suggestion

Re: Python and GMP.

2009-04-21 Thread alessiogiovanni . baroni
On 21 Apr, 09:11, Paul Rubin wrote: > casevh writes: > > Python 3.1 is significantly faster than Python 2.x on 64-bit > > platforms. The following times are for multiplication with 2, 30 and > > 300 decimal digits. > > Could you test pow(a,b,c) where a,b,c are each 3

Re: Python and GMP.

2009-04-21 Thread Paul Rubin
casevh writes: > Python 3.1 is significantly faster than Python 2.x on 64-bit > platforms. The following times are for multiplication with 2, 30 and > 300 decimal digits. Could you test pow(a,b,c) where a,b,c are each 300 decimal digits? This is an important operation in cryptography, that GMP is

Re: Python and GMP.

2009-04-20 Thread casevh
On Apr 20, 11:39 am, Benjamin Peterson wrote: >   gmail.com> writes: > > > > > There are reasons why Python not used the GMP library for implementing > > its long type? > > Basically, GMP only becomes faster when the numbers are huge. Python 3.1 is significantly faster than Python 2.x on 64-bit p

Re: Python and GMP.

2009-04-20 Thread Paul Rubin
Benjamin Peterson writes: > Basically, GMP only becomes faster when the numbers are huge. In my experience GMP is about 4x faster than Python longs with 1024 bit numbers, a very common cryptographic size. -- http://mail.python.org/mailman/listinfo/python-list

Re: Python and GMP.

2009-04-20 Thread Mark Dickinson
On Apr 20, 10:36 pm, Mark Dickinson wrote: > The other major issue is licensing:  as far as I recall, the > various discussions never came to a conclusion about the legal > implications of using GMP. It took me a while to find it... See the thread starting at http://mail.python.org/pipermail/py

Re: Python and GMP.

2009-04-20 Thread Mark Dickinson
On Apr 20, 7:39 pm, Benjamin Peterson wrote: >   gmail.com> writes: > > > > > There are reasons why Python not used the GMP library for implementing > > its long type? > > Basically, GMP only becomes faster when the numbers are huge. That was true for one particular attempt in this direction (by

Re: Python and GMP.

2009-04-20 Thread Benjamin Peterson
gmail.com> writes: > > There are reasons why Python not used the GMP library for implementing > its long type? Basically, GMP only becomes faster when the numbers are huge. -- http://mail.python.org/mailman/listinfo/python-list

Re: Python and GMP.

2009-04-20 Thread Jean-Paul Calderone
On Mon, 20 Apr 2009 18:24:07 +0200, "Diez B. Roggisch" wrote: alessiogiovanni.bar...@gmail.com wrote: There are reasons why Python not used the GMP library for implementing its long type? Any reason it should? I don't know GMP (only that it exists), but adding binary dependencies is always

Re: Python and GMP.

2009-04-20 Thread Diez B. Roggisch
alessiogiovanni.bar...@gmail.com wrote: > There are reasons why Python not used the GMP library for implementing > its long type? Any reason it should? I don't know GMP (only that it exists), but adding binary dependencies is always a tricky and in need of careful weighting thing to do. Diez --

Python and GMP.

2009-04-20 Thread alessiogiovanni . baroni
There are reasons why Python not used the GMP library for implementing its long type? -- http://mail.python.org/mailman/listinfo/python-list