[Developers] admb threading

[dave fournier]

On 12-11-28 04:30 PM, John Sibert wrote:

The problem is that it is a moving target.  ADMB-RE was originally 
intended to
deal with RE's stuck into an arbitrary  nonlinear model without any 
special structure.

These models generally have highly confounded parameters so can not be 
handled
easily with the usual MCMC stuff. In fact I don't think there was any 
other package that
could begin to deal with them. Downside from that is that the 
cognoscenti  actively
discourage any discussion of such so that the unwashed have no concept 
of moving in this
direction. As a result ADMB-RE was dumbed down to deal mostly with 
separable models.
The kind of multi-threading opportunities are quite different. I'm not 
sure where to go with
that.  I see little value in dealing with models so trivial that they 
can be done in R, but that
seems to be where the uninformed market is.

I have perused the code for the multi-threaded LU decomposition in 
Lapack / openblas.

It is very fast but suffers from the fact that this was written by 
unrepentant FORTRASH
programmers with no idea of using the correct data structures for the 
problem.
As a result taking that code and producing adjoint code from it or df1 
code for use in
large spatial models would be very difficult and probably a waste of time.

I have developed some ideas for what I think could be a successful 
approach to this
but have yet to be convinced that anyone is interested.



> Johnoel and I need some feedback about how to approach threading. Dave 
> has provided a nice proof of concept using pthreads to implement 
> parallel processing on larger chunks of code. This approach is likely 
> to have the biggest performance improvement, but seems application 
> specific and would require more expertize on the part of users.
>
> Alternatively it is possible to implement threading internally in the 
> ADMB libraries, concentrating on smaller chunks of code, for instance 
> the solve(...) function. This approach would probably have smaller 
> performance payoff in most applications, but would be more transparent 
> to users.
>
> In principle, the two approaches are not mutually exclusive.
>
> So my question to the ADMB Developer group is what did we mean when we 
> assigned a high priority to parallelization?  Do we want parallel code 
> that is "transparent" to the user (if so what parts of the would have 
> the highest priority)? Or do we want to develop tools that allow users 
> to create their on threaded code for specific applications? (Don't 
> tell me both.)
>
> Cheers,
> John
> PS enjoy the attached.
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at admb-project.org
> http://lists.admb-project.org/mailman/listinfo/developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.admb-project.org/pipermail/developers/attachments/20121128/b0c737ec/attachment.html>