[Developers] admb threading

[dave fournier]

On 12-11-29 09:50 AM, Mark Maunder wrote:

The biggest improvement to the profile likelihood would be to replace 
the current
penalty function method with the augmented Lagrangian.

> What about the calculation of the hessian, which can be quite long on parameter rich models.
> Profile likelihoods would also be another easy one
>
>
> -----Original Message-----
> From: developers-bounces at admb-project.org [mailto:developers-bounces at admb-project.org] On Behalf Of dave fournier
> Sent: Thursday, November 29, 2012 9:26 AM
> To: developers at admb-project.org
> Subject: Re: [Developers] admb threading
>
> On 12-11-29 09:11 AM, Hans J. Skaug wrote:
>
> The obvious transparent one is the -ndb (num der blocks) which was already set up for mult-threading, and I recall Derek was doing something with that, but I never heard about it again, and it is not for separable models.  For separable models one could split up the separable function calls by different threads in a transparent manner.  Both of these involve using the __thread declaration to deal with some global data structures.  The real point of my proof of concept example was to demonstrate that this can be done quite easily.
>
>
>
>> Both are useful, but currently "transparent to the user" is the most important.
>>
>> hans
>>
>>> -----Original Message-----
>>> From: developers-bounces at admb-project.org [mailto:developers-
>>> bounces at admb-project.org] On Behalf Of Mark Maunder
>>> Sent: Thursday, November 29, 2012 8:23 AM
>>> To: John Sibert; ADMB Developers
>>> Subject: Re: [Developers] admb threading
>>>
>>> parallel code that is "transparent" to the user
>>>
>>> -----Original Message-----
>>> From: developers-bounces at admb-project.org [mailto:developers-
>>> bounces at admb-project.org] On Behalf Of John Sibert
>>> Sent: Wednesday, November 28, 2012 4:30 PM
>>> To: ADMB Developers
>>> Subject: [Developers] admb threading
>>>
>>> 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.
>>>
>>> --
>>> John Sibert
>>> Emeritus Researcher, SOEST
>>> University of Hawaii at Manoa
>>>
>>> Visit the ADMB project http://admb-project.org/
>>>
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at admb-project.org
>>> http://lists.admb-project.org/mailman/listinfo/developers
>> _______________________________________________
>> Developers mailing list
>> Developers at admb-project.org
>> http://lists.admb-project.org/mailman/listinfo/developers
> _______________________________________________
> Developers mailing list
> Developers at admb-project.org
> http://lists.admb-project.org/mailman/listinfo/developers