<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12-11-28 04:30 PM, John Sibert
wrote:<br>
<br>
The problem is that it is a moving target. ADMB-RE was originally
intended to<br>
deal with RE's stuck into an arbitrary nonlinear model without
any special structure.<br>
<br>
These models generally have highly confounded parameters so can
not be handled<br>
easily with the usual MCMC stuff. In fact I don't think there was
any other package that<br>
could begin to deal with them. Downside from that is that the
cognoscenti actively<br>
discourage any discussion of such so that the unwashed have no
concept of moving in this<br>
direction. As a result ADMB-RE was dumbed down to deal mostly with
separable models.<br>
The kind of multi-threading opportunities are quite different.
I'm not sure where to go with <br>
that. I see little value in dealing with models so trivial that
they can be done in R, but that<br>
seems to be where the uninformed market is.<br>
<br>
I have perused the code for the multi-threaded LU decomposition in
Lapack / openblas.<br>
<br>
It is very fast but suffers from the fact that this was written by
unrepentant FORTRASH<br>
programmers with no idea of using the correct data structures for
the problem.<br>
As a result taking that code and producing adjoint code from it or
df1 code for use in<br>
large spatial models would be very difficult and probably a waste
of time.<br>
<br>
I have developed some ideas for what I think could be a successful
approach to this<br>
but have yet to be convinced that anyone is interested.<br>
<br>
<br>
<br>
</div>
<blockquote cite="mid:50B6AC9F.2080201@hawaii.edu" type="cite">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.
<br>
<br>
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.
<br>
<br>
In principle, the two approaches are not mutually exclusive.
<br>
<br>
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.)
<br>
<br>
Cheers,
<br>
John
<br>
PS enjoy the attached.
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Developers@admb-project.org">Developers@admb-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.admb-project.org/mailman/listinfo/developers">http://lists.admb-project.org/mailman/listinfo/developers</a>
</pre>
</blockquote>
<br>
</body>
</html>