[CppAD] Use of global var for tape

[schattenpflanze at arcor.de]

Dear Iakov,

>>> 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>
Usually, you have a small set of independent variables x, a small set of
output variables y, and a large set of dependent, intermediate variables
(tmp in your example). Therefore, you would have to track and reset a
lot of variables. Nevertheless, one could argue that all dependent
variables should be defined in a local scope, or that it is the
responsibility of the user to destruct (or reset) them after Dependent()
is called.

>> 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.
I think that is certainly a possibility worth considering. I would love
to hear Brad's opinion on that.

>> 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.
This approach would definitely be more flexible. It would probably
require some more thinking on the user's side in order to obtain optimal
performance when using large amounts of tapes in parallel. I think it
might be worth it, though.

> 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.
That is certainly true.

Best regards,
Peter