> Well, I would say that not being to unlimit the stack size to some
> reasonable value is the more dangerous feature. The reason to put
> large
> arrays on the stack has to do with caching effects. So what you can do
> is
> basically keep using the same memory that is already in the cache if
> you
> work on data on the stack. This can actually make a measurable
> difference
> in performance, and is why I have made a point of using stack workspace
> in
Indeed, but this ONLY makes sense if the stack is small enough to fit in
cache. Hence 524 Meg as a stack limit would seem to be a perfectly
reasonable. There is no argument for using over 500Meg of stack that I can
see.
Thus my comment is that someone needs to work out how much stack the
problematic test cases need and have a script that is smart enough to detect
if the stack limit is high enough. Simply searching for the word "unlimited"
is not going to be transferable in any way. More than likely someone
probably, ala Charmm, has something totally unreasonable on the stack such
as:
subroutine foo(natom,...)
!Automatic allocation of my_array on stack.
my_array(natom,natom)
...
All the best
Ross
/\
\/
|\oss Walker
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 19 2010 - 14:00:04 PDT
