[Cbc] Clues sought on how to diagnose Cbc performance changes
John J Forrest
jjforre at us.ibm.com
Wed Dec 17 04:30:04 EST 2008
Allan,
I would suggest looking at the example driver4.cpp. With that you should
get all the performance advantages of the stand-alone solver.
John Forrest
From: acw at ascent.com
To: cbc at list.coin-or.org
Date: 12/16/2008 07:15 PM
Subject: [Cbc] Clues sought on how to diagnose Cbc performance changes
A little while ago I sent the following message to Coin-discuss. The last
time I paid serious attention, there was no mailing list devoted to Cbc,
but now I discover that there is, and this was probably a better place to
ask my question. I apologize to those who are seeing my query twice.
----- Forwarded by Allan C Wechsler/Cambridge/Ascent on 12/16/2008 07:11 PM
-----
From: acw at ascent.com
To: coin-discuss at list.coin-or.org
Date: 12/16/2008 06:14 PM
Subject: [Coin-discuss] Clues sought on how to diagnose Cbc performance
changes
About two years ago, we built an application around the then-current
release of Cbc. For the sake of discussion, call this "Version A."
Very recently, we downloaded a much more recent release, and re-architected
the application. This "Version B" has exactly the same API as Version A,
but the details of the systems integration are different in a variety of
ways.
Version A was essentially a hack-job on CbcMain's command-line interface:
for example, it launched the Cbc solver by faking a "branch" command.
Version B, in contrast, was written along the lines of some of the simpler
examples in Cbc/examples, and since it leaves out most of the machinery of
the command-line interface, it's about a factor of ten shorter.
To my (perhaps naive) surprise, Version B is far less efficient than
Version A. On one small example problem, Version A processed 24 nodes to
solve the problem, while Version B processed 52 nodes, more than twice as
many.
It is obvious that we have made at least one ill-advised change in cut,
node, or branch selection, or in presolve/postsolve processing. We have
avoided customizations we did not understand, and in most cases used the
default choices that were implicit in the two versions of Cbc.
We have tried more-or-less blind flailing in our attempts to regain the
lost performance efficiency, exploring Version A and experimenting with
transplanting various customizations from there to Version B, but nothing
has had an effect of more than about 10%, compared to the more than 2-to-1
discrepancy between the two versions.
Obviously Cbc has not regressed; it is our own ignorance of how to
configure it that is at fault. But we don't even know how to begin the
analysis that would reveal fruitful avenues to take. We would appreciate
any advice. I haven't provided much detail about our configuration,
because I don't know what aspects of it are important, but I'd be pleased
to answer any questions that would help someone give us some guidance.
Thank you for your consideration, and for the enormous amount of work that
has clearly been put into making Cbc a useful tool.
_______________________________________________
Coin-discuss mailing list
Coin-discuss at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/coin-discuss
_______________________________________________
Cbc mailing list
Cbc at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/cbc/attachments/20081217/3ef3c0cd/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/cbc/attachments/20081217/3ef3c0cd/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/cbc/attachments/20081217/3ef3c0cd/attachment-0001.gif
More information about the Cbc
mailing list