This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: max. array size GNU C compiler...



EKK <ekk@ekkinc.com> wrote in message 37BD7803.E59265BE@ekkinc.com">news:37BD7803.E59265BE@ekkinc.com...
>
> > Another question is:  Do you really need all those values in memory at
> > the same time?  Can you store the values in a file and only haul in
> > small pieces that you are working on? {Works with matrices, and tables}.
> >
>
> this would be a good thing, however, this is a finite element analysis
> code which would need a massive overhaul to achieve what you describe
> above, which would induce considerable loss of performance.

It very well might not, if you use memory mapped files as the backing store
for the variables. One of the simpler ways to do this would be to replace
the memory allocation used by Fortran, in the case of F77 systems which have
integer/Cray/Digital style pointers provide a way to do this. Then you can
use the VM interface to access the array as if it were all in memory but
with the operating system kernel aware that only a small part of it needs be
in the resident set. On several flavors of Unix, this can provide a
substantial performance benefit, as opposed to a loss. Theoretically, this
would be an even bigger improvement on the Windows platforms, but you have
to get through Microsoft's layer of goo on top of the VM interface, as well
as certain deficiencies in the W95 implementation.

This modification could, depending on hw your code is written, be
accomplished in a very small number of lines of code changed.

In the case of F9x and allocatable arrays, there doesn't seem to be a way to
get around this problem.

Later,
Andrew Mullhaupt



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]