ANN: GMPY 1.10 alpha with support for Python 3

Mensanator mensanator at aol.com
Mon Jul 20 00:12:35 EDT 2009


On Jul 19, 5:05 pm, casevh <cas... at gmail.com> wrote:
> GMPY 1.10 beta is now available. This version fixes an issue where
> very large objects would be cached for reuse instead of being freed.

Excellent! That explains the funny memory usage graph.

>
> Source code and Windows installers may be found athttp://code.google.com/p/gmpy/downloads/list
>

Test results:

import collatz_functions as cf
# imports gmpy
# the cf.Type12MH function does the equivalent
# of the pure Python version of the function
# using gmpy
import time

#3.1 gmpy 1.10 beta
#
t0 = time.time()
n=10
for k in range(1,n):
  for i in range(1,n-2):
    print((str(cf.gmpy.numdigits(cf.Type12MH(k,i))).zfill(n)),end=' ')
  print()
print()
t1 = time.time()

print(t1-t0)

# 3.1 pure Python
#
##t0 = time.time()
##n=10
##for k in range(1,n):
##  for i in range(1,n-2):
##    print((str(cf.gmpy.numdigits( \
##      2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)//2+1)-1)-1  \
##      )).zfill(n)),end=' ')
##  print()
##print()
##t1 = time.time()
##
##print(t1-t0)


##  3.1 gmpy 1.10 alpha
##
##0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
0505375816
##
##3.32299995422
## funny memory usage display, different between 2.6 & 3.1, but funny
regardless,
## memory remains allocated (~700 MB) when program halts

##  3.1 pure Python
##
##0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
0505375816
##
##338.832000017
## memory usage seems normal, runs slow enough to observe memory being
allocated
## and freed and remains freed when program halts

##  2.6 pure Python
##
##0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##aborted after ONE FULL WEEK of processing (only 8 of 9 rows
completed)

##  Something funny happened here. By the time I ran this test, there
##  were 14 orphaned copies of pythonw.exe present, at least one of
which
##  was still running along with the real pair executing the program.
Yet
##  the Performance only registered ~50%. Normally, this would be 100%
if
##  two programs were running. Pure Python is a LOT slower than gmpy,
##  but not THAT slow. These orphaned processes may be a Python 3.1
issue.

##===================================================================

## 3.1 gmpy 1.10 beta
##
##  0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##  0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##  0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##  0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##  0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##  0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##  0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##  0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##  0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
0505375816
##
##  2.41799998283
## memory usage now appears normal, no more allocated memory when
program halts
## and it's so fast all we see on Performance graph is a small blip,
much better
## than the 700-1400 MB it was allocating before.

## 3.1 pure Python
##
##0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
0505375816
##
##339.611999989
## looks like gmpy about a 100 times faster. I knew there was a reason
I
## won't use Python without gmpy.

## 2.6 gmpy 1.10 beta
##
##0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
0505375816
##
##2.68400001526

## 2.6 pure Python
##
##0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
0000000013
##0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
0000000107
##0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
0000000952
##0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
0000008560
##0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
0000077028
##0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
0000693246
##0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
0006239209
##0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
0056152869
##0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
0505375816
##
##338.987999916
## ah, that's more like it. no more pythonw.exe thrashing. I was
almost ready
## to drop version 2.6 like a live grenade, but that was based on some
other
## fault apparently. it may be 3.1 I have to drop.

I still got a single instance of an orphaned pythonw.exe, but this
happened during a quick attempt at provoking it during a 3.1 pure
Python test, so I have no reason to suspect gmpy (previously, I
thought it may be related to the memory leak).

I've got an idea on how to reliably provoke this which I'll try to
work up later (and won't even load gmpy to make sure it's not
involved).

> casevh




More information about the Python-list mailing list