[Developers] admb threading

[Mark Maunder]

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