<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Using a special OpenMP memory manager turned out to greatly improve
CppAD speed tests. This has enabled CppAD to obtain near linear
speed ups for 40 cores (we have not yet tested more cores); see the
heading 05-22 on
<br>
<a class="moz-txt-link-freetext"
href="http://www.coin-or.org/CppAD/Doc/whats_new_11.xml#05-22">http://www.coin-or.org/CppAD/Doc/whats_new_11.xml#05-22</a>
<br>
<br>
This new memory manager holds onto memory until the following
function is called
<br>
<a class="moz-txt-link-freetext"
href="http://www.coin-or.org/CppAD/Doc/free_available.xml">http://www.coin-or.org/CppAD/Doc/free_available.xml</a>
<br>
<br>
On 7/15/2011 9:36 AM, <a class="moz-txt-link-abbreviated" href="mailto:schattenpflanze@arcor.de">schattenpflanze@arcor.de</a> wrote:
<blockquote cite="mid:4E206C93.1030607@arcor.de" type="cite"><br>
<pre wrap="">I had a look into this. The "memory leak" is due to the fact that
free_available(0) is never called. Thus, the omp_alloc memory manager
never really frees the memory, but rather stores it for possible future
use. Moreover, even if free_available(0) is called before the end of
main(), the created ADFun object is still in scope. Thus, its memory
cannot yet be freed.
</pre>
</blockquote>
This makes sense; see<br>
<a class="moz-txt-link-freetext" href="http://www.coin-or.org/CppAD/Doc/inuse.xml">http://www.coin-or.org/CppAD/Doc/inuse.xml</a><br>
<blockquote cite="mid:4E206C93.1030607@arcor.de" type="cite">
<pre wrap="">If I define the ADFun object within a block scope and call
free_available(0) after that block closes (see attachment), no memory
leak is detected by valgrind.
</pre>
</blockquote>
Thanks for checking this.<br>
<blockquote cite="mid:4E206C93.1030607@arcor.de" type="cite">
<pre wrap="">
We should definitely find a way to free all memory automatically at the
end of a program. I suggest calling free_available() for every thread
(up to the number set in max_num_threads) in the destructor of some
auxiliary class A, and including an object of that type as a static
class member of AD<Base> (or any other class).
In addition, we could also think about deleting returned memory by
default, and only activating the current behaviour (storing returned
memory as "available") on user request. Something like
omp_alloc::keep_memory_available(bool setting).
</pre>
</blockquote>
Perhaps the memory allocator should not hold onto memory that was
allocated during sequential (not parallel) mode ?<br>
<br>
That way, free_available during sequential mode could return all the
memory to the system (provided that the variables allocated during
parallel mode have dropped out of scope by the time we reach
sequential mode).<br>
<br>
<blockquote cite="mid:4E206C93.1030607@arcor.de" type="cite">
<pre wrap="">
Best regards,
Peter
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
CppAD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CppAD@list.coin-or.org">CppAD@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cppad">http://list.coin-or.org/mailman/listinfo/cppad</a>
</pre>
</blockquote>
<br>
</body>
</html>