[Developers] profiling ADMB model with gprof

[Allan Hicks]

Thanks to Ian for spurring me to compile ADMB10beta in Microsoft Visual 
C++, and thanks to all of the ADMB folks for their hard work.  I am very 
appreciative of the ease at which it is to compile the ADMB source code.

I compiled ADMB 10 using MS Visual Studio C++ 2008 (VC9) and MS Visual 
Studio C++ 2010 (VC10), and compared run times to ADMB 9 compiled with 
VC9.  I used the same expanded catch-at-age model that Ian Taylor used 
when investigating Linux.  All executables are 32-bit, compiled and ran 
on a Xeon 3680 with 3GB RAM running Windows XP 32-bit.  The results of 
25 runs are shown in the attached figure, and here are some key results:

1) I did not find Ian Taylor's Linux result that ADMB 10 was slower 
during minimization. ADMB9 and ADMB10 were about the same speed when 
compiled with the same compiler.

2) ADMB 10 was about 9% slower when estimating the Hessian (which 
includes the slightly faster minimization).

3) Compiling with VC10 resulted in slighter faster minimization times 
and significantly faster times when estimating the Hessian.

4) More than half of the run time is spent estimating the Hessian for 
this model.

Overall, the combination of ADMB10 and VC10 improves the speed of 
minimization, but is about the same speed as ADMB9 when also estimating 
the Hessian.  Finally, I did not observe the large difference in run 
times like Ian reported with Linux (he only looked at minimization time, 
so his observation has nothing to do with the Hessian).  This suggests 
to me that there may be something when compiling.

Thanks again to everyone and I'm glad to see these improvements (as well 
as the many improvements I am unaware of) in ADMB.

Allan




On 11/17/2010 5:37 PM, Ian Taylor wrote:
>  The which_library() function worked perfectly for me--thanks for the 
> information. It returned "s" and "o" when it was supposed to in 
> version 10. In version 9 perhaps it was not yet resurrected, as it 
> always returned "o", regardless of how I compiled.
>
> Pasted below is output showing that libado.a was 65% of the size of 
> libads.a in v9 but the ratio was 98% in v10beta, implying that 
> something may have gone wrong with the make file for 64 bit linux. 
> Allan Hicks just showed me some indication that on his Windows 
> computer, things were working well with v10beta, providing further 
> support for the idea that my slow run times were a problem with how 
> ADMB was getting compiled on linux.
>
> [~]$ ls -lh ~/h_itaylor/admb/v9/lib
> total 15M
> -rwxr--r-- 1 itaylor itaylor 1.5M Aug 18 13:52 libadmod.a
> -rwxr--r-- 1 itaylor itaylor 3.7M Aug 18 13:52 libado.a
> -rwxr--r-- 1 itaylor itaylor 5.7M Aug 18 13:52 libads.a
> -rwxr--r-- 1 itaylor itaylor 116K Aug 18 13:52 libadt.a
> -rwxr--r-- 1 itaylor itaylor 2.0M Aug 18 13:52 libdf1b2o.a
> -rwxr--r-- 1 itaylor itaylor 2.0M Aug 18 13:52 libdf1b2s.a
> -rwxr--r-- 1 itaylor itaylor  32K Aug 18 13:52 libdf1b2stub.a
> [~]$ ls -lh ~/h_itaylor/admb/v10/lib
> total 19M
> -rwxr--r-- 1 itaylor itaylor 1.9M Nov 10 12:29 libadmod.a
> -rwxr--r-- 1 itaylor itaylor 5.2M Nov 10 12:24 libado.a
> -rwxr--r-- 1 itaylor itaylor 5.3M Nov 10 12:28 libads.a
> -rwxr--r-- 1 itaylor itaylor 166K Nov 10 12:29 libadt.a
> -rwxr--r-- 1 itaylor itaylor 3.0M Nov 10 12:20 libdf1b2o.a
> -rwxr--r-- 1 itaylor itaylor 2.9M Nov 10 12:21 libdf1b2s.a
> -rwxr--r-- 1 itaylor itaylor  33K Nov 10 12:29 libdf1b2stub.a
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ADMB9and10MS.pdf
Type: application/pdf
Size: 28084 bytes
Desc: not available
URL: <http://lists.admb-project.org/pipermail/developers/attachments/20101117/7f67faf4/attachment-0001.pdf>