Re: [AMBER-Developers] release plans

From: Robert Duke <rduke.email.unc.edu>
Date: Mon, 19 Apr 2010 17:34:18 -0400

Oh wow, I am talking more about something on order of natom * 3..., maybe a
couple of somethings of that order. Not heading in the direction of needing
64 bit pointers ;-).
Regards - Bob
----- Original Message -----
From: "Ross Walker" <ross.rosswalker.co.uk>
To: "'AMBER Developers Mailing List'" <amber-developers.ambermd.org>
Sent: Monday, April 19, 2010 4:53 PM
Subject: RE: [AMBER-Developers] release plans


>> 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
>
>



_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 19 2010 - 15:00:03 PDT
Custom Search