[Numpy-discussion] large memory address space on Mac OS X (intel)

Louis Wicker Louis.Wicker@noaa....
Thu Feb 1 13:48:16 CST 2007


yes it does.  Its the Woodcrest server chip which supports 32 and 64  
bit operations.  For example the new Intel Fortran compiler can grab  
more than 2 GB of memory (its a beta10 version).  I think gcc 4.x can  
as well.

However, Tiger (OS X 10.4.x) is not completely 64 bit compliant -  
Leopard is supposed to be pretty darn close.

Is there a numpy flag I could try for compilation....


On Feb 1, 2007, at 1:41 PM, Travis Oliphant wrote:

> Louis Wicker wrote:
>> Dear list:
>> I cannot seem to figure how to create arrays > 2 GB on a Mac Pro
>> (using Intel chip and Tiger, 4.8).  I have hand compiled both Python
>> 2.5 and numpy 1.0.1, and cannot make arrays bigger than 2 GB.  I also
>> run out of space if I try and 3-6 several arrays of 1000 mb or so  
>> (the
>> mem-alloc failure does not seem consistent, depends on whether I am
>> creating them with a "numpy.ones()" call, or creating them on the fly
>> by doing math with the other arrays "e.g., c  = 4.3*a + 3.1*b").
>> Is this a numpy issue, or a Python 2.5 issue for the Mac?  I have
>> tried this on the SGI Altix, and this works fine.
> It must be a malloc issue.  NumPy uses the system malloc to construct
> arrays.  It just reports errors back to you if it can't.
> I don't think the Mac Pro uses a 64-bit chip, does it?
> -Travis
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

| Dr. Louis J. Wicker
| National Weather Center
| 120 David L. Boren Boulevard, Norman, OK 73072-7323
| E-mail:   Louis.Wicker@noaa.gov
| HTTP:  www.nssl.noaa.gov/~lwicker
| Phone:    (405) 325-6340
| Fax:        (405) 325-6780
| "Programming is not just creating strings of instructions
| for a computer to execute.  It's also 'literary' in that you
| are trying to communicate a program structure to
| other humans reading the code." - Paul Rubin
|"Real efficiency comes from elegant solutions, not optimized programs.
| Optimization is always just a few correctness-preserving  
| away." - Jonathan Sobel
| "The contents  of this message are mine personally and
| do not reflect any position of  the Government or NOAA."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20070201/0ec8c935/attachment.html 

More information about the Numpy-discussion mailing list