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

[Sebastian Haase]

Here is a small c program that we used more than a year ago to confirm
that tiger is really doing a 64-bit malloc (on G5).

<code: test64.c >
#include <stdlib.h>
#include <stdio.h>
int main()  {  size_t n;  void *p;  double gb;
 for(gb=10;gb>.3;gb-=.5) {
       n= 1024L * 1024L * 1024L * gb;
       p = malloc( n );
       printf("%12lu %4.1lfGb %p\n",n,n/1024./1024./1024.,p);
       free(p); }  return 0;  }
</code>

Hope this helps anyone.
Sebastian


On 2/1/07, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> Louis Wicker wrote:
>
> > Travis:
> >
> > yes it does.  Its the Woodcrest server chip
> > <http://www.intel.com/business/xeon/?cid=cim:ggl%7Cxeon_us_woodcrest%7Ck6913%7Cs> 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.
> >
> Nice.  I didn't know this.
>
> > 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....
>
> It's entirely compiler and system dependent.  NumPy just uses the system
> malloc.  If you can compile it so that the system malloc supports 64-bit
> then O.K. (but you will probably run into trouble unless Python is also
> compiled as a 64-bit application).   From Robert's answer, I guess it is
> impossible under Tiger to compile with 64-bit support.
>
> -Travis
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>