From: amado.alves on
> 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...
From: Jeffrey R. Carter on
amado.alves(a)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
From: amado.alves on
> 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?
From: amado.alves on
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.
From: Randy Brukardt on
<amado.alves(a)gmail.com> wrote in message
news:afa48ae2-cee6-41d6-9390-5cd6b12bdfcf(a)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.