9 ms·
Hash tables with O(1) worst-case lookup and space efficiency [pdf]
- sambeau 16y ago"WHY ELSE IS THIS COOL?" seems a very casual heading for an academic article.
- pa7 16y agothought exactly the same. define a "cool" way of doing things
- _delirium 16y agoIt looks like it was a workshop paper, from the 7th Workshop on Distributed Data and Structures. I don't know much about that particular workshop, but workshops often aim for a more informal atmosphere, since one of their main roles is fostering discussion (incl. of works in progress) and bringing communities of researchers together to discuss things.
- chwahoo 16y agoI like it when academic papers include some personality or touches of informality (in headings or examples for example), as long as the required rigor is not sacrificed elsewhere. Now "why else is his cool?" is probably a bit further than I go.
- tripzilch 16y agoI dig--if you're going to use an informal expression and risk being completely dated within half a decade, why not pre-empt the retro wave with WHY ELSE IS THIS GROOVY?
- ot 16y agoCuckoo hashing is not only optimal in theory, it is also very fast in practice. The only downside, though, is that the insert time has linear-time worst case. Thus it may be not the best solution if latency is an issue.
- jemfinch 16y ago"Linear-time worst case" is different from "amortized constant time", which is what cuckoo hashing provides. Almost all the containers we use on a regular basis provide only amortized constant time inserts.
- jules 16y agoLinear time worst case and amortized constant time are not mutually exclusive. You are right that most containers that we use have amortized constant time complexity, but they also have linear worst case complexity. Most times this is because an internal array has to be resized and the contents have to be copied over to the new enlarged array.
- jemfinch 16y agoNo, they're not mutually exclusive. But what actually matters in most software is "amortized constant time": linear time worst case only matters in hard real-time systems which can't tolerate any deviation from the expected runtime. Even algorithms like binary trees can end up with very bad worst cases unless great care is taken in allocating their nodes.
- ot 16y agoThe linear time behavior of cuckoo hashing is not triggered only when the table has to be enlarged, like standard containers (say, std::vector or python list): a linear numbers of keys can be "cuckooed" out of their slots for an insertion even when the load factor is under the capacity threshold. In standard containers if you pre-define the capacity (say with std::vector::reserve) all the insertions are guaranteed to be constant time. Cuckoo hashing can't give this guarantee.
- pmjordan 16y agoI'm unaware of any hash table implementations which successfully insert elements in absolute constant time in the event of collisions.
- thurn 16y agoAn interesting algorithm, and an engaging presentation. If only more academic writing was this accessible!
- 16s 16y agoIt's been my experience that the O(1) was on average, not worst case.
- lecha 16y agoIs open-source implementation of this data structure available somewhere?
- sanxiyn 16y agoThere is ckhash. http://canasai.tcllab.org/software/ckhash/ http://canasai.tcllab.org/software/ckhash/
- pbewig 16y agoI recently did an exercise on cuckoo hashing at http://programmingpraxis.com/2011/02/01/cuckoo-hashing/ http://programmingpraxis.com/2011/02/01/cuckoo-hashing/.
- kunjaan 16y agoI had loved that article. It was very succinct.
- jchonphoenix 16y agoI coded a cuckoo hashed hashtable for a class once, and recently had a lecture on cuckoo hashing given to my class by Rasmus Pagh himself (inventor of cuckoo hashing). Its really surprising actually how complex the probability behind cuckoo hashing really is (and how tied to graph theory/bipartite matchings it is). The amazing part is, not only is access O(1), the expected insertion time whenever there is no rehashing is also O(1) and rehashing occurs infrequently.
- brg 16y agoMitzenmacher, the author of Probability and Computing, has an interesting survey on cookoo hashing. In it there are a number of open research problems that, for those of you with interest, a worth looking over. The 7th is very interesting to me, regarding optimal ways to maintain a hash table in a parallel computing environment. http://www.eecs.harvard.edu/~michaelm/postscripts/esa2009.pdf http://www.eecs.harvard.edu/~michaelm/postscripts/esa2009.pd...
- sigstoat 16y agoI've had some luck turning a cuckoo hash into a sort of LRU cache. Whenever you do an insert, replace the older item. Iirc, everything else stayed the same. Using more than 2 hashed really helped.
- pjscott 16y agoI'd been wondering how best to make an LRU cache, and now you come along and give a really good solution. Nice!
- jrockway 16y agoThat is not LRU, it's "replace with some other random thing some time, based on a hash function".
- gfodor 16y agoThis is really clever, thanks for the hack.
- Deestan 16y agoThat's not a hack. It's an algorithm.
- martinkallstrom 16y agoOoh so a hack is sort of an eigentransform of an algorithm in the sense that a hacked algorithm is still an algorithm.
- ComputerGuru 16y agoI'd just like to point out that the worse your hash algorithm is, the better Cuckoo Hashing compares to traditional hashing...... therefore, study your hash functions! The ones that come with most languages or libraries by default quite simply aren't optimized for use on anything. There's hash functions that work better on strings and hash functions that work better on numbers (length bias). In the perfect world, this wouldn't be true, but in the real world, yes it is. That said, may I recommend MurmurHash3: code.google.com/p/smhasher/wiki/MurmurHash3 Switch your hash tables to this. The performance difference is incredible.
- ithayer 16y agoEvery time I've tried comparing cuckoo hashing vs traditional hash algorithms in practice, the time taken to compute the additional hash functions outweighs any gains in performance. Counter-intuitively, I've also noticed in many cases that using binary search over sorted elements in contiguous memory is actually faster than using a hash table at all. Has anyone else found this?
- leif 16y agoIt very much depends on your hash table implementation, but I'm betting that your hash table is storing pointers to objects stored elsewhere. In this case, an array of elements in contiguous memory will be much faster because of locality. It's sometimes surprising how badly most of the data structures we think about treat caches.
- pbewig 16y agoI almost always prefer some kind of balanced tree to a hash table, because no matter the original specifications, sometime during the development of a program I usually need the elements in order.
- tripzilch 16y ago> the time taken to compute the additional hash functions outweighs any gains in performance. Sounds like you're using the wrong hash functions. Are you using secure cryptographic hash functions perchance? (such as MD5, SHA, etc) Because they're not intended for use in data structures. Most data structure algorithms just require a hash function with good avalanche behaviour and a statistically even bit dispersion. The FNV hash will do this for you with just a MUL and a XOR per byte, which is (rough guess) at least 100 times faster than SHA. FNV hash (http://www.isthe.com/chongo/tech/comp/fnv/ http://www.isthe.com/chongo/tech/comp/fnv/) it's super-effective!