[ADOL-C] ADOLC Speed Diff 1.8 vs 2.5.2

Tue Nov 25 18:40:14 EST 2014

Hello,

>
> Anyone have ideas on how to improve the ADOLC 2.5 execution time?
>

Blindly converting all "double" type variables to "adouble" will never
result in a performant code. Only the correctness of the derivatives is
guarenteed this way.

To get high performance you need to reuse the ADOL-C trace as much as
possible, and retrace as little as possible. This means all "adouble"
variables have a lifetime just within the trace_on()...trace_off() calls
and these as called at most once per model. All optimisation iterations
after that should work with simple "double" variables and call the
ADOL-C drivers function(), gradient(), sparse_hess() etc.

Best regards
Kshitij.

On 2014-11-26 00:27, Scott Rasmussen @ Zaita wrote:
> Repost because my email client prefers HTML.
> 
> Hi Guys,
> I have managed to get CPPAD+IPOPT+BLAS+MUMPS working to compare against
> ADOLC.
> Final results were:
> ADOLC 1.8      = 3 seconds - score 1998.55
> ADOLC 2.5.2  = 2.9 minutes - score 1998.55
> CPPAD             = 29 seconds - score 1977.55
> 
> Each of these models runs identical code except for the autodiff
> component. Within the application the compiled versions have all
> 'double' types replaced with the autodiff implementation of that library
> (e.g adouble for ADOLC).
> 
> Anyone have ideas on how to improve the ADOLC 2.5 execution time?
> 
> Regards,
> Scott
> 
> On 21/11/2014 8:16 a.m., Scott Rasmussen @ Zaita wrote:
>> Hi Kshitij
>>
>> Using .adolcrc and compiled buffer changes allowed me to verify the
>> changes were effective and matched when using both methods.
>>
>> Unfortunately for this platform there are no allocation or
>> deallocation calls between trace_on() and trace_off(). Doing
>> allocation between these two methods will way too expensive, The
>> entire model is created (based on custom user description file) and
>> once everything has been allocated and verified the execution is
>> passed off to the minimiser to iterate the model until minimisation
>> (where trace_on is). So all adouble values exist before trace_on() and
>> still exist after trace_off().
>>
>> At present I am attempting to implement CppAD + IPOPT to compare
>> results to ADOLC. I'll reply with results when/if I am successful.
>>
>> Regards,
>> Scott
>>
>> On 20/11/2014 10:44 p.m., Kshitij Kulshreshtha wrote:
>>> Hello Scott,
>>>
>>> the use of .adolcrc and increasing buffer-sizes in usrparms.h is
>>> completely equivalent. They both change the same variables in libadolc
>>> with .adolcrc always superseeding the values in usrparms.h
>>>
>>> The behaviour with later iterations being slower than earlier ones makes
>>> me wonder though. It is also worrisome that the trace created in the
>>> first iteration gives wrong results later on, leading to wrong
>>> minimisation, this should definitely not happen.
>>>
>>> Please make sure that there are no adouble variables existing in program
>>> core before the execution of trace_on() and none are left in the program
>>> core after the execution of trace_off(). All remaining adouble variables
>>> must be destroyed immediately before trace_off(). Do not use adoubles in
>>> any persistent data structures.
>>>
>>> Best regards
>>> Kshitij
>>>
>>> On 2014-11-20 01:06, Scott Rasmussen @ Zaita wrote:
>>>> Hi Andrea and Kshitij,
>>>>
>>>> I have tested the solutions you both offered, but they didn't improve
>>>> the situation.
>>>> Doing a trace_on() when a gradient is required, or first iteration
>>>> only,
>>>> causes the minimisation results to get worse, but execution time is 18
>>>> seconds.
>>>> Increasing the buffer size stopped the file I/O but this didn't help
>>>> execution time.
>>>>
>>>> Attached to this email are the binaries I have been using and
>>>> configuration files to run them if you're interested.
>>>> Below are the results of each configuration and test:
>>>>
>>>> Binary: isam_adolc18.exe (ADOLC version 1.8)
>>>> Process memory usage: 20MB
>>>> Files created: none
>>>> Extra notes: does run trace_on() / trace_off() on every iteration
>>>> Execution time: 3 seconds
>>>>
>>>> Binary: isam_adolc_2.5.2.exe
>>>> Process memory usage: 8-10MB
>>>> Files created:
>>>> ADOLC-Locations_0.tap (0 - 10MB)
>>>> ADOLC-Operations_0.tap (0 - 1MB)
>>>> ADOLC-Taylors_0.tap (0kbs)
>>>> Extra notes: first 2-3 iterations run almost instantly, then they slow
>>>> down to 3-4 seconds each
>>>> Execution time: 2.9 minutes
>>>>
>>>> Binary: isam_increased_buffer.exe
>>>> New buffer sizes: 134217728
>>>> Process memory usage: 21-22MB
>>>> Files created: none
>>>> Extra notes: first 2-3 iterations run almost instantly, then they slow
>>>> down to 3-4 seconds each
>>>> Execution time: 2.8 minutes
>>>>
>>>> Binary: isam_adolc_2_5_2.exe (with adolrc)
>>>> Process memory usage: 21-22MB
>>>> Files created: none
>>>> New buffer values:
>>>> "OBUFSIZE" = "512000000"
>>>> "LBUFSIZE" = "512000000"
>>>> "VBUFSIZE" = "512000000"
>>>> "TBUFSIZE" = "512000000"
>>>> Extra notes: first 2-3 iterations run almost instantly, then they slow
>>>> down to 3-4 seconds each
>>>> Execution time: 2.8 minutes
>>>>
>>>> Binary: isam_adolc_2_5_2_trace_on_when_gradient_required.exe
>>>> Process memory usage: 21-22MB
>>>> Files created: None
>>>> Extra notes: this is also using a compiled increased buffer size,
>>>> Extra notes: first 2-3 iterations run almost instantly, then they slow
>>>> down to 3-4 seconds each
>>>> Extra notes: Minimisation did not match the results of the other
>>>> binaries. They were 1998.5 and this is 2647.97 so considerably worse
>>>> Execution time: 18 seconds
>>>>
>>>> Binary: isam_adolc_2_5_2_trace_only_first_iteration.exe
>>>> Process memory usage: 21-22MB
>>>> Files created: None
>>>> Extra notes: this is also using a compiled increased buffer size
>>>> Extra notes: first 2-3 iterations run almost instantly, then they slow
>>>> down to 3-4 seconds each
>>>> Extra notes: Minimisation did not match the results of the other
>>>> binaries. They were 1998.5 and this is 2647.97 so considerably worse
>>>> Execution time: 18 seconds
>>>>
>>>> Thanks heaps for your help. I hope I can get this resolved so I can
>>>> make
>>>> ADOLC the default auto-diff library for the new modelling platform.
>>>>
>>>> Regards,
>>>> Scott
>>>>
>>>> On 19/11/2014 8:09 p.m., Andrea Walther wrote:
>>>>> Hi Scott,
>>>>>
>>>>>> I notice it writes to files A LOT and not a huge amount of data (any
>>>>>> flags to keep this in memory?)
>>>>> that is most probably the reason why the current version is so slow.
>>>>> It is really important to avoid the writting on disc to get a
>>>>> reasonable speed.
>>>>>
>>>>> In the directory
>>>>>
>>>>> .../ADOL-C/include/adolc/internal
>>>>>
>>>>> there is a file
>>>>>
>>>>> usrparms.h
>>>>>
>>>>> There you can increase the buffer size for
>>>>>
>>>>> OBUFSIZE
>>>>> LBUFSIZE
>>>>> VBUFSIZE
>>>>> TBUFSIZE
>>>>>
>>>>> to such a large value that the files are not written on disc.
>>>>> Alternatively you could use a
>>>>>
>>>>> .adolcrc
>>>>>
>>>>> file. I attach an example file. This would avoid the recompilation
>>>>> if you have to change the buffer sizes.
>>>>>
>>>>> And finally it is important that you use
>>>>>
>>>>> trace_off()
>>>>>
>>>>> and do NOT use
>>>>>
>>>>> trace_off(1) or something like that
>>>>>
>>>>> because this would force ADOL-C to write the files on disc.
>>>>>
>>>>> Hope this helps. Otherwise just email again.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Andrea
>>>>>
>>>>
>>>> _______________________________________________
>>>> ADOL-C mailing list
>>>> ADOL-C at list.coin-or.org
>>>> http://list.coin-or.org/mailman/listinfo/adol-c
>>>>
>>
> 
> _______________________________________________
> ADOL-C mailing list
> ADOL-C at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/adol-c

-- 
Dr. Kshitij Kulshreshtha

Institut für Mathematik,
Universität Paderborn,
Warburger Straße 100,
33098 Paderborn.

Büro: A3.235

Privatanschrift:
Arnikaweg 62
33100 Paderborn.