[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matrix sizes
From: |
Paul Kienzle |
Subject: |
Re: matrix sizes |
Date: |
Wed, 15 Sep 2004 20:53:54 -0400 |
Darrick,
I see from the malloc manpage that it accepts size_t type, which
presumably means the underlying system can allocate hunks
greater than 2Gb.
So then it is simply a matter of converting all array size and index
variables everywhere in liboctave and liboctinterp to use
octave_size_t, defined as octave_uint64 for your purposes.
Simple enough, but time consuming.
Next you will need to go through libcruft and make sure all the
supporting libraries can handle size_t for array sizes and
indices. Others have done this in the past for atlas and fftw
which are the most important ones.
This should give you a working system with 53-bit indexing
which should last you a little bit longer.
Pushing it to full 64-bit indexing will require fiddling with the
range type and completing arithmetic ops on uint64. I don't
know what the compatibility implications are of such a
change.
- Paul
On Sep 15, 2004, at 8:31 PM, Darrick Edward Chang wrote:
Sorry for this follow-up, but in response to some emails I have already
gotten, perhaps I should clarify the conditions I am working under. I
am
running octave 2.1.57 on a server with 20GB of RAM. Thus I can use
the zeros command to create multiple matrices of size 16000 x 16000,
for
example, with no problem.
Trying to create a single matrix of size 16384 x 16384, however, or a
complex matrix of size 16384 x 8192, is where octave spits out the
error
messages that I noted in my previous message.
-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.org
How to fund new projects: http://www.octave.org/funding.html
Subscription information: http://www.octave.org/archive.html
-------------------------------------------------------------
- matrix sizes, Darrick Edward Chang, 2004/09/15
- Re: matrix sizes,
Paul Kienzle <=