[CppAD] Use of global var for tape

Iakov Nakhimovski Iakov.Nakhimovski at gmail.com
Fri Aug 12 03:58:03 EDT 2011


Dear Peter,

> Unfortunately, it turned out that using shared pointers (or even better
> weak pointers) in each AD<double> instance slows down everything
Ok I didn't think of that. In my case I 'tape' once and then use the
ADFunc many times. Therefore the extra overhead in the beggining is
not an issue. It can be different for other applications.

>> 2) Make the tape creation explicit to the user
>> - tape_this pointer in the AD<Base> is a normal pointer to ADTape<Base>
> Using ordinary pointers instead would work with regard to performance.
> However, this might cause trouble if a tape is deleted but the recorded
> AD<double> variables are not.
Well, the only code that would do so is something like:
AD<double> tmp,x,y;
{
ADTape tape = Independent(x)
tmp=x;
y=tmp;
ADFunc f(y,x); <- cleans tape pointer in x & y but not in tmp
}
y = tmp + 1;     <- tape object does not exist
ADTape tape = Independent(x)
tmp=x+tmp; <- Which tape to use?

Is it really worth handling gracefully? Can this be defined as an
error? Are there other examples?
The above could be fixed by providing some kind of "tape reset" method
on AD<Base>

> There is then no obvious way to check that
> the tape pointed to still exists (and thus to decide, whether an
> AD<double> pointing to that tape is still a variable of a specific tape
> or a parameter).
If we can agree that this is an invalid operation then the case could
be detected with an assert in debug mode (e.g., by checking a global
set of valid tapes) and reported as an error.

> Moreover, the memory allocator in omp_alloc.hpp currently keeps track of
> used memory per thread. One would have to do the memory management
> within the tape (or attach a memory manager object to the tape) in order
> to avoid checking the thread number explicitly.
Attaching an allocator to a container (the tape in this case) as a
template argument is quite common. Don't see a problem here. I
actually think this is a better option than providing a single
implementation that the user cannot change. At least in my application
the tape is constructed once and then used many times (like 10^5) with
different arguments. In such a case system memory allocator is good
enough since it is only used once in the beginning and does not hurt
the performance so much.
Thinking along this lines: would it be possible to abstract, e.g.,
TapeAllocator in a separate class that would become the second
template argument, next to Base? Different allocators could then be
provided for different thread libs in a consistent way.

I feel that locking CppAD to OpenMP is a limitation since this means
troubles when working with other thread libs like pthreads or CUDA
threads.

Best regards,

Iakov



More information about the CppAD mailing list