[Numpy-discussion] numpy slices limited to 32 bit values?
Glenn Tarbox, PhD
glenn@tarbox....
Thu May 14 03:31:45 CDT 2009
On Wed, May 13, 2009 at 11:22 PM, Glenn Tarbox, PhD <glenn@tarbox.org>wrote:
>
>
> On Wed, May 13, 2009 at 11:04 PM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>
>>
>>
>> On Wed, May 13, 2009 at 10:50 PM, Glenn Tarbox, PhD <glenn@tarbox.org>wrote:
>>
>>> I'm using the latest version of Sage (3.4.2) which is python 2.5 and
>>> numpy something or other (I will do more digging presently)
>>>
>>> I'm able to map large files and access all the elements unless I'm using
>>> slices
>>>
>>> so, for example:
>>>
>>> fp = np.memmap("/mnt/hdd/data/mmap/numpy1e10.mmap", dtype='float64',
>>> mode='r+', shape=(10000000000,))
>>>
>>> which is 1e10 doubles if you don't wanna count the zeros
>>>
>>> gives full access to a 75 GB memory image
>>>
>>> But when I do:
>>>
>>> fp[:] = 1.0
>>> np.sum(fp)
>>>
>>> I get 1410065408.0 as the result
>>>
>>
>> As doubles, that is more than 2**33 bytes, so I expect there is something
>> else going on. How much physical memory/swap memory do you have? This could
>> also be a python problem since python does the memmap.
>>
>
> I've been working on some other things lately and that number seemed
> related to 2^32... now that I look more closely, I don't know where that
> number comes from.
>
> To your question, I have 32GB of RAM and virtually nothing else running...
> Top tells me I'm getting between 96% and 98% for this process which seems
> about right.
>
> Here's the thing. When I create the mmap file, I get the right number of
> bytes. I can, from what I can tell, update individual values within the
> array (I'm gonna bang on it a bit more with some other scripts)
>
> Its only when using slicing that things get strange (he says having not
> really done a more thorough test)
>
> Of course, I was assuming this is a 32 bit thing... but you're right...
> where did that result come from???
>
> The other clue here is that when I create my own slice (as described above)
> it returns instantly... numpy doesn't throw an error but it doesn't do
> anything with the slice either.
>
> Since I'm IO bound anyways, maybe i'll just write a loop and see if I can't
> set all the values. The machine could use a little exercise anyways.
>
I ran the following test:
import numpy as np
size=10000000000
fp = np.memmap("/mnt/hdd/data/mmap/numpy1e10.mmap", dtype='float64',
mode='r+', shape=(size,))
for i in xrange(size):
fp[i]=1.0
time np.sum(fp)
10000000000.0
Time: CPU 188.36 s, Wall: 884.33 s
So, everything seems to be working and it kinda makes sense. The sum
should be IO bound which it is. I didn't time the loop but it took a while
(maybe 30 minutes) and it was compute bound.
To make sure, I exited the program and ran everything but the initialization
loop.
import numpy as np
size=10000000000
fp = np.memmap("/mnt/hdd/data/mmap/numpy1e10.mmap", dtype='float64',
mode='r+', shape=(size,)
time np.sum(fp)
10000000000.0
Time: CPU 180.02 s, Wall: 854.72 s
I was a little surprised that it didn't take longer given almost half of the
mmap'ed data should have been resident in the sum performed immediately
after initialization, but since it needed to start at the beginning and only
had the second half in memory, it makes sense
So, it "appears" as though the mmap works but there's something strange with
slices going on.
-glenn
>
>
>>
>> Chuck
>>
>>
>>
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
>
> --
> Glenn H. Tarbox, PhD || 206-274-6919
> http://www.tarbox.org
>
--
Glenn H. Tarbox, PhD || 206-274-6919
http://www.tarbox.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20090514/c58e77fd/attachment.html
More information about the Numpy-discussion
mailing list