{"title":"Georg's Log - algorithm","link":[{"@attributes":{"href":"https:\/\/gms.tf\/","rel":"alternate"}},{"@attributes":{"href":"https:\/\/gms.tf\/feeds\/algorithm.atom.xml","rel":"self"}}],"id":"https:\/\/gms.tf\/","updated":"2020-11-22T16:00:00+01:00","entry":{"title":"Perfect Hashing","link":{"@attributes":{"href":"https:\/\/gms.tf\/perfect-hashing.html","rel":"alternate"}},"published":"2020-11-22T16:00:00+01:00","updated":"2020-11-22T16:00:00+01:00","author":{"name":"Georg Sauthoff"},"id":"tag:gms.tf,2020-11-22:\/perfect-hashing.html","summary":"

The beauty of perfect hashing<\/a> is that you never have to deal with\nany collisions during item lookup.\nI recently created libphashtable<\/a>, a perfect hashing hash table library for\nC\/C++ which focuses on minimizing item lookup latency jitter.\nThis article presents benchmarking results that show how its lookup\ntimes \u2026<\/p>","content":"

The beauty of perfect hashing<\/a> is that you never have to deal with\nany collisions during item lookup.\nI recently created libphashtable<\/a>, a perfect hashing hash table library for\nC\/C++ which focuses on minimizing item lookup latency jitter.\nThis article presents benchmarking results that show how its lookup\ntimes compare to those of a traditional hash table.<\/p>\n

Overview¶<\/a><\/h2>\n

The libphashtable README<\/a> contains some details on the libphashtable\ndesign and on hashing background.\nThis diagram provides a short summary on how libphashtable works:<\/p>\n

\"libphashtable<\/p>\n

Results¶<\/a><\/h2>\n

\"Perfect<\/p>\n

This graph is a boxenplot<\/a> (a boxplot<\/a> variant, a.k.a. letter-value\nplot) that describes all measured item lookup access times.\nIt's a comparison of a standard hash-table, i.e. 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).\nAgain, the libphashtable README's Measurements Section<\/a> contains further\ndetails on the benchmark setup.<\/p>\n

The median is marked by a dark grey line that is part (or on top)\nof the biggest box. The biggest box contains 50 % of the values.\nThe next smaller boxes contain the next 25 %, 12.5 % etc. of the\nmeasured values. Outliers are drawn in a diamond shape, where, of\ncourse, multiple outliers may be drawn on top of each other.<\/p>\n

Thus, the lower the median the better, less boxes are better than\nmore, flat boxes are better than higher ones, less outliers\nare better than more, etc.<\/p>\n

As expected, using a traditional hash table leads to much latency\njitter.\nIt's not just outliers, e.g. on Xeon 50 % of the lookups are\ndistributed over a 5 to 10 ns wide range or so.\nWhile e.g. on the Atom CPU, 50 % of the lookups are\ndistributed over a 20 ns range or so.\nThe very simple and old SDBM item hash function over the board yields very good results.\nAlso, using a more expensive item hash function doesn't really\nhave a good trade off here, such as less collisions due to a better\ndistribution of its range, i.e. the boxes and outliers basically\nare just shifted without being compressed.<\/p>\n

The graph shows that libphashtable indeed yields a 'perfect' item\nlookup latency distribution.\nThat means the boxes are so flat that the median line covers\nthem all and there aren't any outliers, in most configurations.\nIn general, using the SDBM hash function as item hash function is\na safe choice, especially when targeting a low-end CPU.<\/p>","category":[{"@attributes":{"term":"algorithm"}},{"@attributes":{"term":"algorithm"}},{"@attributes":{"term":"datastructure"}},{"@attributes":{"term":"C"}},{"@attributes":{"term":"C++"}}]}}