<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1">Hi Kshitij<br>
<br>
Using .adolcrc and compiled buffer changes allowed me to verify
the changes were effective and matched when using both methods.<br>
<br>
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(). <br>
<br>
At present I am attempting to implement CppAD + IPOPT to compare
results to ADOLC. I'll reply with results when/if I am successful.<br>
<br>
Regards,<br>
Scott<br>
<br>
</font>
<div class="moz-cite-prefix">On 20/11/2014 10:44 p.m., Kshitij
Kulshreshtha wrote:<br>
</div>
<blockquote cite="mid:546DB7F2.50703@math.upb.de" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Scott,
</pre>
<blockquote type="cite">
<pre wrap="">I notice it writes to files A LOT and not a huge amount of data (any
flags to keep this in memory?)
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
ADOL-C mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ADOL-C@list.coin-or.org">ADOL-C@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/adol-c">http://list.coin-or.org/mailman/listinfo/adol-c</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>