https://gms.tf/2020-11-22T16:00:00+01:002020-11-22T16:00:00+01:002020-11-22T16:00:00+01:00Georg Sauthofftag:gms.tf,2020-11-22:/perfect-hashing.html

<p>The beauty of <a href="https://en.wikipedia.org/wiki/Perfect_hash_function">perfect hashing</a> is that you never have to deal with any collisions during item lookup. I recently created <a href="https://github.com/gsauthof/phashtable">libphashtable</a>, a perfect hashing hash table library for C/C++ which focuses on minimizing item lookup latency jitter. This article presents benchmarking results that show how its lookup times …</p>

<p>The beauty of <a href="https://en.wikipedia.org/wiki/Perfect_hash_function">perfect hashing</a> is that you never have to deal with any collisions during item lookup. I recently created <a href="https://github.com/gsauthof/phashtable">libphashtable</a>, a perfect hashing hash table library for C/C++ which focuses on minimizing item lookup latency jitter. This article presents benchmarking results that show how its lookup times compare to those of a traditional hash table.</p> <h2 id="overview">Overview<a class="headerlink" href="#overview" title="Permanent link">&para;</a></h2> <p>The <a href="https://github.com/gsauthof/phashtable">libphashtable README</a> contains some details on the libphashtable design and on hashing background. This diagram provides a short summary on how libphashtable works:</p> <p><img alt="libphashtable lookup scheme" src="https://gms.tf/image/libphash-lookup.svg"></p> <h2 id="results">Results<a class="headerlink" href="#results" title="Permanent link">&para;</a></h2> <p><img alt="Perfect Hashing Boxenplot" src="https://gms.tf/image/perfect-hashing-bplot.svg"></p> <p>This graph is a <a href="https://seaborn.pydata.org/generated/seaborn.boxenplot.html">boxenplot</a> (a <a href="https://en.wikipedia.org/wiki/Box_plot">boxplot</a> variant, a.k.a. letter-value plot) that describes all measured item lookup access times. It's a comparison of a standard hash-table, i.e. <code>std::unordered_map</code> (umap), against libphashtable (ptable), using different item hash functions on a high-end CPU (Intel Xeon Gold 6246) vs. a low-end CPU (Intel Atom C3768). Again, the libphashtable README's <a href="https://github.com/gsauthof/phashtable#measurements">Measurements Section</a> contains further details on the benchmark setup.</p> <p>The median is marked by a dark grey line that is part (or on top) of the biggest box. The biggest box contains 50 % of the values. The next smaller boxes contain the next 25 %, 12.5 % etc. of the measured values. Outliers are drawn in a diamond shape, where, of course, multiple outliers may be drawn on top of each other.</p> <p>Thus, the lower the median the better, less boxes are better than more, flat boxes are better than higher ones, less outliers are better than more, etc.</p> <p>As expected, using a traditional hash table leads to much latency jitter. It's not just outliers, e.g. on Xeon 50 % of the lookups are distributed over a 5 to 10 ns wide range or so. While e.g. on the Atom CPU, 50 % of the lookups are distributed over a 20 ns range or so. The very simple and old SDBM item hash function over the board yields very good results. Also, using a more expensive item hash function doesn't really have a good trade off here, such as less collisions due to a better distribution of its range, i.e. the boxes and outliers basically are just shifted without being compressed.</p> <p>The graph shows that libphashtable indeed yields a 'perfect' item lookup latency distribution. That means the boxes are so flat that the median line covers them all and there aren't any outliers, in most configurations. In general, using the SDBM hash function as item hash function is a safe choice, especially when targeting a low-end CPU.</p>