[Beowulf] mem consumption strategy for HPC apps?

[Toon Knapen]

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.

Is it

"total_amount_of_ram - ram_used_by_system"

or better

"total_amount_of_ram - ram_used_by_system - 
total_amount_of_mem_used_by_other_parts_of_my_app" ?

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