News for hackers. Stuff that matters.
Re:A new fast hash table in response to Google’s new fast ha... by MaxBarraclough on Tuesday May 29, 2018 @02:18PM (#17181680)
Arena-allocation? As in (roughly speaking) a Stack<Node> data structure whose lifetime is bound to the lifetime of the tree, right?

How could we support deletion of nodes?

Re:A new fast hash table in response to Google’s new fast ha... by stochastic_monk on Tuesday May 29, 2018 @10:47PM (#17184633)
This is getting deep into some wizardry, but if you used a custom pool-like allocator you could group contents close together in cache, and, if necessary/appropriate, even rearrange the elements in the container to be more cache-friendly for your purposes.
Re:A new fast hash table in response to Google’s new fast ha... by thecompilr on Wednesday May 30, 2018 @02:00AM (#17185425)
You could, but the premise of using a tree was to avoid unpredictable rehashing latency, if you start compacting the tree every now and then, you basically pay the same price.
Re:A new fast hash table in response to Google’s new fast ha... by MaxBarraclough on Wednesday May 30, 2018 @07:12AM (#17186700)
That approach tastes rather like a copying+compacting garbage-collector.
Re:A new fast hash table in response to Google’s new fast ha... by ztorkelson on Tuesday May 29, 2018 @03:08PM (#17182080)
Right. When you ask "how could we support deletion of nodes", am I right to assume you mean "how could we reclaim memory of deleted nodes"?

Conventionally, a free list would be used, though admittedly that sacrifices locality which was one of the original motivating factors. To the extent that deletion is a significant component of the workload, then yeah, this doesn't help.

Re:A new fast hash table in response to Google’s new fast ha... by MaxBarraclough on Wednesday May 30, 2018 @07:16AM (#17186722)
Yes, exactly. It would of course be trivial to unlink a node without reclaiming it, but then you're leaking.

Radix trees never rotate, right? Can that be leveraged to help with locality?