Parallel redesign - #3192
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## latest #3192 +/- ##
==========================================
+ Coverage 73.06% 73.12% +0.06%
==========================================
Files 445 445
Lines 107661 107801 +140
Branches 17257 17262 +5
==========================================
+ Hits 78659 78826 +167
+ Misses 28726 28699 -27
Partials 276 276 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
fwesselm
left a comment
There was a problem hiding this comment.
@Opt-Mucca, this looks great! Just a couple of uninformed comments from me.
| worker.search_ptr_->getLocalNodes())) { | ||
| break; | ||
| if (!skip_separation) { | ||
| evaluateNode(i); |
There was a problem hiding this comment.
The return value of evaluateNode is ignored here? It could return true, right? Does this overcount the total_nodes_explored?
There was a problem hiding this comment.
I don't think this overcounts total_nodes_explored. The node should be processed by pruneNode and then increment the counter. Edit: The node is already sent of to processedNodes, but pruneNode should recognise this.
The bool return seems to be something left-over from early drafts (isn't even used on master currently)
This PR is a first redesign of the parallel MIP code. I'm just going to dot point the major changes:
preparedNodesof each worker. A worker now only processes nodes assigned to it.backtrackPlungeto a simple DFS style algorithm without the ability to skip a level of the tree while backtracking based on pseudocosts.nodequeueattached to each worker to a simplestd::vector.For my tests on 8 threads this gives a 6.5% time improvement and 6% LP iteration improvement. It gives a 1% performance degradation on single-threaded performance. Edit: This change should also use 40% less memory.
Reason for single-threaded degradation: There is one outlier instance
tbfp-networkwhere the sub-mip no longer finds the optimal solution instantly. This means the problems solves 5x slower. It stems from thebacktrackPlungechanges, but I'd mostly chalk it up to randomness. Without this instance the change is performance neutral on single-threaded and more than 6.5% improving on 8 threads.