Larger matrices

I manage to process 1000 x 1000 matrices with the respective Ada 2005
standard library with GNAT GPL 2008. Processing includes
multiplication by a vector.

Now I want larger matrices, say 5000 x 5000. The objects seem to be
allocated ok (dynamically), but mutiplication gives a "segmentation
fault."

Any tips on how to overcome this?

Thanks a lot.

amado.alves@gmail.com schrieb:

> Now I want larger matrices, say 5000 x 5000. The objects seem to be
> allocated ok (dynamically), but mutiplication gives a "segmentation
> fault."
>
> Any tips on how to overcome this?

Have you tried having gnatmake recompile the library
units (-a,-f,-s) with, say, -g, -O, -gnata, -gnato,
and -fstack-check? Might yield a better diagnostic.


--
Georg Bauhaus
Y A Time Drain http://www.9toX.de

> Have you tried having gnatmake recompile the library
> units (-a,-f,-s) with, say, -g, -O, -gnata, -gnato,
> and -fstack-check? *Might yield a better diagnostic. (Bauhaus)

I'll try that and let you all know. Thanks a lot for this great first
orientation in the miriad set of compiler options.

It's a Storage_Error with the message "stack overflow detected".

My program does not use the stack, so probably the multiplication is
implemented as a function with parameters passed on the stack and this
overflows, like it does if I trie to create the large arrays as static
objects.

Next I will try to increase the stack size, but I bet I'm gonna hit
the 2G ceiling :-(

(Recently I saw memory pointers being defined as 32-bit integers.)

On Wed, 6 Aug 2008 10:29:09 -0700 (PDT), amado.alves@gmail.com wrote:

> It's a Storage_Error with the message "stack overflow detected".
>
> My program does not use the stack, so probably the multiplication is
> implemented as a function with parameters passed on the stack and this
> overflows, like it does if I trie to create the large arrays as static
> objects.

IMO, for such huge matrices and vectors, it is better to use in-place
operations, rather than a loose functional programming style.

And do you have dense 5000 x 5000 matrices? You are a hardworking man!
(:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

> IMO, for such huge matrices and vectors, it is better to use in-place
> operations, rather than a loose functional programming style.

You mean a procedure with out parameter instead of function? Is there
such utility?

> And do you have dense 5000 x 5000 matrices? You are a hardworking man!

It's an hypertext. It starts out sparse, but then gets less sparse
with the usage because it is an adaptive hypertext system and I am
using spreading activation to create new links. Probably it will never
be very dense, but new links may appear anywhere in the matrix. And
it's only a prototype for a thesis, and the focus is on the
theoretical model not the implementation, so I was prepared to spend a
few megas of my giga ram to use the standard library if only the
compiler let me do it...

I found switches -fstack-usage and -fcallgraph-ifo (gcc) in the GNAT
manual but Gnatmake does not seem to accept this.

I also found that GNAT is calling a BLAS or LAPACK function called
"gemv" to implement matrix-vector "*" and so my diagnostics of
overflow caused by (value?) passing on the stack is probably right.

So now I want to increase the stack size. To 200M. The right Gnatmake
switch, please...

amado.alves@gmail.com wrote:
> It's a Storage_Error with the message "stack overflow detected".
>
> My program does not use the stack, so probably the multiplication is
> implemented as a function with parameters passed on the stack and this
> overflows, like it does if I trie to create the large arrays as static
> objects.

Probably the operation declares a result object on the stack, which causes the
stack overflow. GNAT is pretty good about not passing large objects by copy.

You may need to create your own operations that use the heap rather than the stack.

--
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

> Probably the operation declares a result object on the stack, which causes the
> stack overflow. GNAT is pretty good about not passing large objects by copy.

Yes, I inspected a little, the "*" function is entered well, it's the
BLAS/LAPACK call that explodes.

> You may need to create your own operations that use the heap rather than the stack.

Because nobody did this yet?
Increase the stack size?

Upon failing miserably to convince GNAT to use a stack of 200M, I am
currently working around the problem by writing my own matrix-by-
vector multiplication function. It takes 2 seconds for a 5000 x 5000
matrix, but it does not explode.

I continue interested in ways to augment the stack size (or another
way) to enable use of the standard library. Not so much for speed, but
more for validation (GNAT passes ACATS right? Are ACATS for this
library setup yet?)

Thanks a lot.

<amado.alves@gmail.com> wrote in message
news:afa48ae2-cee6-41d6-9390-5cd6b12bdfcf@y21g2000hsf.googlegroups.com...
> Upon failing miserably to convince GNAT to use a stack of 200M, I am
> currently working around the problem by writing my own matrix-by-
> vector multiplication function. It takes 2 seconds for a 5000 x 5000
> matrix, but it does not explode.
>
> I continue interested in ways to augment the stack size (or another
> way) to enable use of the standard library. Not so much for speed, but
> more for validation (GNAT passes ACATS right? Are ACATS for this
> library setup yet?)

No, no ACATS for this (or any of the new packages, for that matter) yet.
Since packages are relatively easy to implement correctly, I've been
concentrating the new tests on the new features (like interfaces and null
exclusions and limited returning functions) that it is much more likely to
get wrong. I've also paid no attention at all to the non-manditory annexes.
So that's two strikes on these packages.

If someone wants to submit ACATS-style tests for any of the new packages,
they'd be much appreciated. (There surely needs to be at least some minimal
tests just to ensure that they exist.)

Randy.