Re: gnat and heap size

[Dr Adrian Wrigley <amtw@linuxchip.demon.co.uk>]

Claude Marinier wrote:
> We want to use large arrays (well, large for us: 10000 x 10000 complex
> numbers). We are using gnat 3.13p on Solaris 7. We run out of heap (heap
> exhausted) and have not yet found a way to increase it.

I have had a similar problem, and raised it on this NG a few months ago...

I was trying to store the past five years of the US stock markets in a big array.
I wanted to reload the data from disk "instantly", so I could do statistics easily.

The solution I came up with was to use an "mmap" call to map the data.  That way,
I could get an access value to data as big as the OS could give.  This was big
enough for my data (about 0.5GB).  Mapping the data back in was extremely quick.
Unfortunately, it makes the code a bit less portable, but that wasn't too bad.

But there were problems with mapping big records, and taking 'size attributes.
Since Ada works in bits, the sizes can overflow (signed) 32-bit representation.
This makes handling data in excess of 256MB tricky, since locations of
record elements are wrong, as are size attributes (eg a problem in generics).
I solved this by calculating the sizes of each element, multiplying by the
number of elements, adding in each record component's size.  Nasty.
But it was 10-100 times the speed of more obvious solutions.

I suspect you have a 64-bit architecture, and *may* not hit the 'size problems
I had with GNAT.  If you stick to simple arrays, you might be OK. I was using
GNAT 3.12p on a '686 processor.

I don't know what these other guys seem so surprised at.  Doesn't everybody
else have 1280MB of RAM nowadays, too?  ;-)  It's only a few hundred bucks!
--
Adrian Wrigley

(by the way... what do you use such large matrices for?)