Use boost d-ary heap for MLD routing

[oxidase]

Issue

For #3764 can be used boost::heap::d_ary_heap as a 4-ary heap. The PR adds SearchHeap that internally uses boost::heap::d_ary_heap with boost::heap::arity<4>. In general on a small dataset like bayern-latest the difference between 2-ary and 4-ary heaps is not statistically relevant, but the difference wrt to BinaryHeap is for 1000 queries http://localhost:5000/route/v1/driving/11.575395,48.137132;9.932966,49.792450

	Welch Two Sample t-test

data:  before$V1 and after$V1
t = 13.672, df = 1274.7, p-value < 2.2e-16
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
 0.001313073 0.001753019
sample estimates:
  mean of x   mean of y 
0.010305615 0.008772569 

Data summary of MLD routing with BinaryHeap (red on histogram) is

    Min.  1st Qu.   Median     Mean  3rd Qu.     Max. 
0.007715 0.008152 0.008602 0.010310 0.011940 0.039360 

and for the new SearchHeap (blue on histogram) is

    Min.  1st Qu.   Median     Mean  3rd Qu.     Max. 
0.007814 0.008083 0.008232 0.008773 0.008688 0.014980 

Tasklist

• add regression / cucumber cases (see docs/testing.md)
• review
• adjust for comments

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

[daniel-j-h]

because it implements a max heap?

[oxidase]

yes, greater instead of less and increase instead of decrease

[daniel-j-h]

👍

What about our existing heap usages e.g. in the CH code?
I think we have some Map and Array storage for heaps in use somewhere.

[oxidase]

It is possible to use boost heaps, but i don't want to make a performance regression for CH algorithms, as performance depends on memory access patterns. Basically for CH-routing only UnorderedMapStorage is used, but in contractor also XORFastHashStorage is used.

[oxidase]

Rebased to the current master and checked performance with #3857 The current implementation of the binary heap is nearly the same as boost::heap::d_ary_heap

@TheMarex as the 4-ary heap does not bring significant performance improvements, is it still needed? I see only benefit in using generalized library code instead of a custom version

I will continue with checking variants for DataIndex

[TheMarex]

@oxidase I suspect the current runtime is dominated by access to the DataIndex hence we don't see any improvements.

A comparison with ArrayIndex might be worthwhile. However if we already pay the price for a full array of size |V| for each heap we might actually go a step further and remove the indirection altogether.

Instead of having a separate index for translating global NodeID to a heap internal (continuous) ID and then use that for indexing the data, we could have a fixed pre-alloced array for that which is indexed by NodeID directly.

That said this would be a bit of work again and would yield an implementation with more memory usage. I'm fine with tabling again, since this is definitely to the category quick win anymore.

[oxidase]

@TheMarex ArrayIndex is somewhat not suitable already on Germany-size graphs, because almost all time spent in memset_avx2_erms by clearing heaps. I have reused generation arrays and here some results

for the MLD algorithm and germany-latest OSM file

• std::unordered_map
• tsl::hopscotch_map
• google::sparse_map
• generative_array
• CH-timing for reference

I think it is ready for review, but it brings almost no value, so it is ok to reject the PR as not needed.

[TheMarex]

I'm for merging this, because at least we don't have our own heap implementation anymore.

But we should only use one heap implementation in the code base. So we should remove query_heap.hpp and port the CH code to use this implementation.

This of course requires a benchmark of CH on old/new just to make sure nothing changed.

[oxidase]

@TheMarex after lengthy performance investigation i think it is better to close PR without merging, because it is brings no performance improvement but increases memory consumption in places like in master const Key key = static_cast<Key>(heap.size()); with Key = uint32_t and in branch reference->handle = heap.push(std::make_pair(weight, reference)); with handle = void *

What i can do:

• remove heap[0] element
• make CheckHeap optional

[oxidase]

@TheMarex please could you check the PR? Summary:

• removed heap[0] element
• removed CheckHeap
• heap changed to boost::heap::d_ary_heap, but any mutable heap structure can be used
• renamed BinaryHeap to QueryHeap

I did not change the index storage as it is performance critical and could not find a better solution than the current one with XORFastHashStorage. The performance with 4-ary heap is the same as with BinaryHeap

[TheMarex]

👍