<font size=2 face="sans-serif">Using the "deterministic parallel"
feature I have now run this problem for hundreds of millions of nodes,
so I think we can safely say that our segfault problem is solved.</font>
<br>
<br><font size=2 face="sans-serif">Needless to say, we are <i>very</i>
interested in hearing more about the "trivial experimental feature";
can you supply any additional information?</font>
<br>
<br><font size=2 face="sans-serif">Allan Wechsler</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">John Forrest <john.forrest@fastercoin.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">acw@ascent.com</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">cbc@list.coin-or.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">03/11/2013 04:44 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Cbc] Cbc segfault after many hours
of CPU time</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Status report on segfault.<br>
<br>
Unable to reproduce with debug version.<br>
<br>
Have reproduced segfaults three times with optimized version. It
is <br>
always to do with multi-threading. Once I could see something I didn't
<br>
like so have modified that. However the other two times it was not
<br>
obvious. Looking at registers and disassembled code I could see <br>
segfault but going from a few instructions back it should have worked.
<br>
So classic overwriting due to threads. But I can't see what is wrong
<br>
with locking/unlocking threads to stop overwriting. Will continue <br>
looking slowly.<br>
<br>
However if you use -thread 104 instead of 4 that switches on <br>
deterministic parallel. This is not quite as efficient (it would
be a <br>
lot better if the effort per node was better determined e.g. as in <br>
Cplex's"ticks") but does not have same problem. That has
been running a <br>
long time without a problem (>63 million nodes).<br>
<br>
Using my (not in svn yet) trunk and throwing every cut at problem I can
<br>
prove solution of 499243.8 is optimal after 23 million nodes.<br>
<br>
However looking at problem I tried another trivial experimental feature
<br>
on problem. There may be bugs, but I don't think so. That took
15,368 <br>
nodes and 54 seconds.<br>
<br>
John Forrest<br>
</font></tt>
<br>