On Apr 4, 9:41 am, Terry Reedy <tjre...@udel.edu> wrote: > On 4/4/2011 1:51 AM, Paul Rubin wrote: > > > I didn't realize Python used Karatsuba. The main issue is probably that > > Python uses a straightforward portable C implementation that's not > > terribly efficient, > > but relatively easy for a couple of people to maintain. For (C)Python 3, > which no longer has a C int type, I believe changes were focused on > making calculations with small integers almost as fast as in 2.x. > > (I believe that retaining two implementations internally was considered > but rejected. Could be wrong.) > > >If you look for the gmpy module, it gives you a way to use gmp from > >Python. In crypto code (lots of 1024 bit modular exponentials) I think > >I found gmpy to be around 4x faster than Python longs. > > For specialized use, specialized gmpy is the way to go. > > I am curious how gmpy compares to 3.x ints (longs) with small number > calculations like 3+5 or 3*5. > > -- > Terry Jan Reedy
(Disclaimer: I'm the current maintainer of gmpy.) A quick comparison between native integers and gmpy.mpz() on Python 3.2, 64-bit Linux and gmpy 1.14. For multiplication of single digit numbers, native integers are faster by ~25%. The breakeven threshold for multiplication occurs around 12 digits and by 20 digits, gmpy is almost 2x faster. I've made some improvements between gmpy 1.04 and 1.14 to decrease the overhead for gmpy operations. The breakeven point for older versions will be higher so if you are running performance critical code with older versions of gmpy, I'd recommend upgrading to 1.14. casevh -- http://mail.python.org/mailman/listinfo/python-list