On modern hardware the min-max heap beats a binary heap

And if you only need a monotone priority queue (i.e. priority queue where the popped elements are monotonically increasing&#x2F;decreasing) you should consider using a radix heap. This monotone requirement can be satisfied more than you would expect when eg. using time as key or in pathfinding. I have a simple radix heap implementation here: <a href="https:&#x2F;&#x2F;github.com&#x2F;mpdn&#x2F;radix-heap" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mpdn&#x2F;radix-heap</a>

Like folks mentioned there, I wonder if a higher-fanout heap (people asked about 4-ary) might also do well in practice. Looking at Wikipedia (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;D-ary_heap" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;D-ary_heap</a>), it looks like maybe so -- the growth in number of comparisons isn&#x27;t that bad, and it mentions 4-ary heaps working well specifically.<p>(Like how linear search wins for small N, or insertion sort helps with small subarrays in introsort: more steps, but each step is also a lot cheaper on modern hardware due to fewer branch mispredictions, better cache locality, or something else that better fits the hardware&#x27;s strengths.)

I have used a min-max heap once. I don&#x27;t remember why I needed it at the time--it was a previous job--but I do remember that I had to roll my own, because it&#x27;s just not that popular of a data structure, and it was the obvious and only good solution to the problem at the time.<p>So, it&#x27;s nice to see a detailed analysis of the structure like this! Perhaps if it becomes more popular, I will find more places to use it.

&gt; &quot;<i>...C++20 finally added a way of accessing this instruction, using std::countl_zero. I don’t have C++20 though so I had to do it the old platform specific ways ...</i>&quot;<p>You don&#x27;t need C++20. Even C++98 had std::bitset&lt;&gt;::count(), which has a nice conversion from unsigned long, and which, when compiled for SSE3 or better (e.g. Core2), uses a POPCNT instruction. It is pretty simple to produce various other results, including countl_zero, from a popcount, with just a couple of additional bitwise ops.<p>Modern compilers are happy to keep a bitset&lt;32&gt; in the same register as an unsigned long, so the conversion takes exactly zero cycles. POPCNT takes three cycles, and the extra bitwise ops another couple.

In certain domains, the trend has been to give up constant factors in order to increase programmer productivity (e.g., python pays a 10x slowdown but is batteries included).<p>So in that case I would use this data structure even if it weren&#x27;t faster. I can&#x27;t count the number of times I have had to mess with inserting negative priorities into a min heap to create a max heap! We should just have one data structure that does both.<p>(though taking this idea to the logical extreme means we should just use Order Statistic Tree for everything since it not only gives you log(n) min&#x2F;max, but also log(n) find kth and get rank of x)

If you need a min-max heap (or double ended heap) in Go here is one I&#x27;ve used: <a href="https:&#x2F;&#x2F;github.com&#x2F;aalpar&#x2F;deheap" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aalpar&#x2F;deheap</a><p>Very useful when you need it!

It would be neat to fire this up on an older processor which doesn’t have modern instruction-level parallelism and verify the difference in performance

I&#x27;ve been using the author&#x27;s flat_hash_map (<a href="https:&#x2F;&#x2F;github.com&#x2F;skarupke&#x2F;flat_hash_map" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skarupke&#x2F;flat_hash_map</a>) for several years now and have been really impressed. I&#x27;ve yet to find a single bug, it&#x27;s nearly as fast as folly&#x27;s hash maps (for my use case anyway) but far easier to integrate than folly.

Impressive. Looking forward to the d-heap article.

Wow. This is a very good analysis on a fundamental algorithm. Haven’t seen a high quality analysis like this for a good while.