Conversation
| ++node_id; | ||
|
|
||
| return {static_cast<std::size_t>(std::distance(edges.begin(), edges_of_node)), coordinate}; | ||
| }; |
There was a problem hiding this comment.
Hm can we clean this one up - the stateful lambda with init captures and transform is a bit ugly
include/partition/inertial_flow.hpp
Outdated
| public: | ||
| InertialFlow(const GraphView &view); | ||
|
|
||
| std::vector<bool> ComputePartition(const double balance, const double source_sink_rate); |
There was a problem hiding this comment.
Should we use dynamic bitset here
(search for vector bool in the docs there)
There was a problem hiding this comment.
What do you mean with balance and source sink rate here?
If balance is 0.25 we take 0.25 * nodes as source and 0.25 * nodes as sinks, right?
There was a problem hiding this comment.
Also seeing you implemented the skeleton as stateful class holding a graph view ref. I suppose you want to abstract the try-n-cuts-take-best inside ComputePartition (?)
There was a problem hiding this comment.
The interface here is just a placeholder for me to imagine what would happen:
- balance would be a guideline for the cuts to be chosen. Any flow that is computed gives a large number of possible cuts (e.g.
a-b-c-d-e-f-g-hcan be split on any intermediate node with an identical cut size). The balance would guide the flow algorithm which of the possible minimal flows to report / what kind of effort to spend on balancing the cuts in size - the source/sink-rate would be for the initialisation of the flow algorithm. The inertial flow picks X percent of the nodes as source/sink, right? So that would be the X.
- For the statefulness: we can easily make this not stateful and make the flow algorithm do the
best out of npart here. That was just to get something working quickly to iterate on.
| LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON | ||
| ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | ||
| (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS | ||
| SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
842bd66 to
50b03a9
Compare
include/partition/graph_view.hpp
Outdated
| void advance(difference_type offset) { position += offset; } | ||
| bool equal(const EdgeIDIterator &other) const { return position == other.position; } | ||
| const reference dereference() const { return position; } | ||
| reference dereference() const { return position; } |
There was a problem hiding this comment.
since reference is already const due to https://github.com/Project-OSRM/osrm-backend/pull/3603/files/50b03a93f9472a3e726fc82d6d452ecb1561054f..3bde4426d491540190d403b889f5a8fcf702164a#diff-d79e8547c1b4e3f383ca1879d7db6bebL35 and my compiler complained about the double const
1561fb1 to
6518d17
Compare
02502d3 to
6b64487
Compare
src/tools/extract.cpp
Outdated
| boost::program_options::value<bool>(&extractor_config.dump_compressed_node_based_graph) | ||
| ->implicit_value(true) | ||
| ->default_value(false), | ||
| "Generate a partitionable graph file (.cnbg) for use with osrm-partition")( |
There was a problem hiding this comment.
Hm on the demo server with Boost 1.55 I have to say --dump-partition-graph true even though implicit_value above should only require dump-partition-graph. No idea if this is an Boost issue...
There was a problem hiding this comment.
Can we just do -DENABLE_MASON=ON on the demoserver and pretend this is ancient history?
There was a problem hiding this comment.
It works specifying it explicitly.
1876ba5 to
fd939a6
Compare
90a4cbf to
9d62e4f
Compare
9d62e4f to
079611f
Compare
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
fix windows compilation no multi line warnings sanitze on mason with newer TBB
|
Grabbing this PR for rebasing and fixing PR comments. |
8c7e79c to
6759982
Compare
6759982 to
6f34d70
Compare
Builds basic infrastructure outline in #3586, defining interfaces and connections between the different parts. Foundation for #3205.
Tasks
osrm-extractOnce done