[Developers] inv problems.
dseiple84 at gmail.com
Sat May 21 09:17:50 PDT 2011
I looked through the file Dave gave me with the inv code in it. I
didn't look very different from what is in version 10. I swapped it
out any way to see if it made any difference in the 'vol' example, but
it ran at the same speed. The profile I have of the 'vol' example
(attached: open with kcachegrind) suggests that a lot of time is being
spent in the headers for the lu-decomposition. Specifically the
On Thu, May 19, 2011 at 4:36 PM, Derek Seiple <dseiple84 at gmail.com> wrote:
> Hi All,
> Yes, I have made some improvements, but it is not yet back to the
> speed that 9.1 had. I am going to make one more change to the code and
> then see where we are. Once I've made the change and tested it I'll
> report back.
> On Thu, May 19, 2011 at 3:13 PM, John Sibert <sibert at hawaii.edu> wrote:
>> I seem to recall a recent message from Derek implying that he had fixed the
>> speed issue.
>> On 05/19/2011 08:02 AM, Arni Magnusson wrote:
>>> Hi Dave,
>>> I notice that I'm the only recipient of this important question. I
>>> appreciate your faith in me, but efficient linear algebra with AD objects is
>>> really outside my area of expertise.
>>> I haven't looked at the inverse or solve code (old, new, or proposed), but
>>> posted the GCC profile diagnostics to help the development team to improve
>>> the performance of the 'vol' example, which became 3 times slower between
>>> 9.1 and 10.0. The profile diagnostics point at some culprit functions, and
>>> Derek Seiple told me (25 Apr email) that he is currently following those
>>> This is definitely a high-priority issue. Given the nature of the problem
>>> (we have 9.1 code that works fast) and the upcoming developer workshop, I'm
>>> optimistic it will be solved in version 10.2 or 11.0.
>>> On Thu, 19 May 2011, dave fournier wrote:
>>>> I'm a bit woried about these problmes with inv and maybe solve taking so
>>>> It kind of breaks the entire software. That is what I alway expected to
>>>> happen eventually. The idea is that it is supposed to be fast. I produced a
>>>> sketch of the code proper working code but it seems to have been screwed up.
>>>> Any thoughts?
>>> Developers mailing list
>>> Developers at admb-project.org
>> John Sibert
>> Emeritus Researcher, SOEST
>> University of Hawaii at Manoa
>> Visit the ADMB project http://admb-project.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 639621 bytes
Desc: not available
More information about the Developers