[Beowulf] mem consumption strategy for HPC apps?
toon.knapen at fft.be
Sun Apr 17 07:42:28 PDT 2005
Greg Lindahl wrote:
> On Thu, Apr 14, 2005 at 08:59:34AM +0200, Toon Knapen wrote:
>>Next we all know about
>>the famous performance-memory tradeoff which says that performance can
>>be improved by consuming more memory and vice versa.
> No, I _don't_ know that one. Often you have to write extra code to
> trade off memory for performance,
Indeed, in many cases you need extra code (which further increases the
memory footprint of the app) to improve performance. But my point is
that you can improve performance by increasing the memory footprint.
For instance a single-linked-list takes less memory than a double-linked
list but iterating in reverse will be slow. An std::set provides much
faster access to the elements as a double-linked-list but again
increases the memory footprint.
> or it takes so much memory that
> there's practical no way to improve performance by using more memory.
I also mentioned (in the next paragraph in my OP) that the tradeoff
assumes _infinite_ memory.
Actually my main question (and the intention of my post) was about how
to handle memory management for an out-of-core solver (thus in the
situation where one has to reduce the memory footprint of the solver (by
doing the virtual memory handling ourselves) to increase the performance).
To obtain optimal performance with an in-core solver, one needs to know
up to how much memory we can allocate 'in-core' without the OS starting
to swap the pages we're using in the solver.
The question now is: how do you 'calculate' up to how much memory you
can have 'in-core' without risking that the OS will start swapping the
pages you're using in the solver although you don't care if it swaps out
other parts of your application that are not used by the solver.
"total_amount_of_ram - ram_used_by_system"
"total_amount_of_ram - ram_used_by_system -
Which comes down to: can I rely on the OS to swap out all pages that are
not used by the out-of-core solver (without risking that the OS will
swap out pages that _are_ used in my out-of-core solver).
> In addition, it's fairly rare for HPC applications to use more memory
> than a machine physically has. Perhaps you work in one of those rare
> areas. One example I know of is NASTRAN, which solves a huge matrix
> that often doesn't fit in memory. But there's no tradeoff involved,
> either the matrix fits or it does not. Perhaps you were talking about
> the quality of the solution?
No, I was talking about out-of-core solvers, just like NASTRAN has.
Check out our training program on acoustics
and register on-line at http://www.fft.be/?id=35
More information about the Beowulf