TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Undergraduate shows that searches within hash tables can be much faster

1304 点作者 Jhsto3 个月前

53 条评论

brink3 个月前
Krapivin made this breakthrough by being unaware of Yao&#x27;s conjecture.<p>The developer of Balatro made an award winning deck builder game by not being aware of existing deck builders.<p>I&#x27;m beginning to think that the best way to approach a problem is by either not being aware of or disregarding most of the similar efforts that came before. This makes me kind of sad, because the current world is so interconnected, that we rarely see such novelty with their tendency to &quot;fall in the rut of thought&quot; of those that came before. The internet is great, but it also homogenizes the world of thought, and that kind of sucks.
评论 #43005279 未加载
评论 #43006985 未加载
评论 #43009738 未加载
评论 #43008513 未加载
评论 #43008267 未加载
评论 #43008794 未加载
评论 #43006041 未加载
评论 #43006352 未加载
评论 #43005318 未加载
评论 #43007115 未加载
评论 #43005414 未加载
评论 #43006026 未加载
评论 #43011830 未加载
评论 #43008157 未加载
评论 #43006094 未加载
评论 #43008791 未加载
评论 #43009349 未加载
评论 #43007370 未加载
评论 #43006668 未加载
评论 #43007151 未加载
评论 #43005391 未加载
评论 #43009691 未加载
评论 #43016317 未加载
评论 #43007944 未加载
评论 #43014789 未加载
评论 #43016377 未加载
评论 #43012421 未加载
评论 #43012120 未加载
评论 #43006195 未加载
评论 #43016379 未加载
评论 #43009469 未加载
评论 #43010858 未加载
评论 #43013993 未加载
评论 #43013077 未加载
评论 #43008289 未加载
评论 #43011432 未加载
评论 #43005684 未加载
评论 #43009688 未加载
评论 #43012239 未加载
评论 #43012513 未加载
评论 #43009901 未加载
评论 #43012940 未加载
评论 #43007719 未加载
评论 #43008249 未加载
评论 #43010355 未加载
评论 #43006060 未加载
评论 #43006966 未加载
评论 #43010592 未加载
评论 #43011084 未加载
评论 #43009496 未加载
评论 #43006717 未加载
评论 #43010921 未加载
评论 #43007542 未加载
评论 #43011171 未加载
评论 #43007248 未加载
评论 #43006627 未加载
评论 #43007789 未加载
评论 #43012151 未加载
评论 #43009596 未加载
评论 #43012102 未加载
评论 #43007384 未加载
评论 #43006679 未加载
评论 #43007146 未加载
评论 #43008139 未加载
评论 #43006121 未加载
评论 #43012590 未加载
评论 #43007462 未加载
评论 #43017382 未加载
评论 #43012458 未加载
评论 #43005710 未加载
评论 #43006303 未加载
评论 #43008568 未加载
评论 #43012966 未加载
评论 #43008945 未加载
评论 #43007659 未加载
评论 #43007728 未加载
评论 #43008189 未加载
评论 #43011667 未加载
评论 #43011979 未加载
评论 #43012112 未加载
评论 #43007437 未加载
评论 #43008649 未加载
评论 #43007527 未加载
评论 #43009980 未加载
评论 #43010819 未加载
评论 #43009824 未加载
评论 #43005816 未加载
评论 #43013358 未加载
评论 #43008762 未加载
评论 #43008288 未加载
评论 #43007992 未加载
评论 #43007121 未加载
评论 #43007079 未加载
评论 #43006276 未加载
评论 #43010928 未加载
评论 #43007074 未加载
评论 #43012638 未加载
评论 #43009867 未加载
评论 #43009820 未加载
abetusk3 个月前
Ok, big shout out to monort [0] for the link to the video [1].<p>This is just a quick overview from a single viewing of the video, but it&#x27;s called &quot;funnel hashing&quot;. The idea is to split into exponentially smaller sub arrays, so the first chunk is n&#x2F;m, the second is n&#x2F;(m^2), etc. until you get down to a single element. Call them A0, A1, etc., so |A0| = n&#x2F;m, |A1| = n&#x2F;(m^2) etc., k levels in total.<p>Try inserting into A0 c times. If it fails, try inserting into A1 c times. If it fails, go down the &quot;funnel&quot; until you find a free slot.<p>Call \delta the fraction of slots that are empty (I&#x27;m unclear if this is a parameter that gets set at hash table creation or one that&#x27;s dynamically updated). Setting c = log(1&#x2F;d) and k = log(1&#x2F;d) to get worst case complexity O(log^2(1&#x2F;d)).<p>This circumvents Yao&#x27;s result by not being greedy. Yao&#x27;s result holds true for greedy insertion and search policies and the above is non-greedy, as it&#x27;s cascading down the funnels.<p>There are probably many little hairy details to work out but that&#x27;s the idea, as far as I&#x27;ve been able to understand it. People should let me know if I&#x27;m way off base.<p>This very much reminds me of the &quot;Distinct Elements in Streams&quot; idea by Chakraborty, Vinodchandran and Meel[2].<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43007860">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43007860</a><p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ArQNyOU1hyE" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ArQNyOU1hyE</a><p>[2] <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2301.10191" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2301.10191</a>
评论 #43010840 未加载
评论 #43009986 未加载
评论 #43011296 未加载
评论 #43066405 未加载
评论 #43010409 未加载
monort3 个月前
Talk by the inventor: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ArQNyOU1hyE" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ArQNyOU1hyE</a>
评论 #43009839 未加载
评论 #43009777 未加载
评论 #43008686 未加载
orlp3 个月前
Skimming the paper [1], the key difference they used is that their hash table insertion algorithm will probe further than the first empty slot, instead of greedily filling the first empty slot it finds. They combine this with a clever probing sequence which provably finds empty slots efficiently, even if the table is very full.<p>This means insertions when the hash table is less full are slower, but you avoid the worst-case scenario where you&#x27;re probing for the last (few) remaining open slot(s) without any idea as to where they are.<p>[1]: <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2501.02305" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2501.02305</a><p>---<p>An interesting theoretical result but I would expect the current &#x27;trick&#x27; of simply allocating a larger table than necessary to be the superior solution in practice. For example, Rust&#x27;s hashbrown intentionally leaves 1&#x2F;8th (12.5%) of the table empty, which does cost a bit more memory but makes insertions&#x2F;lookups very fast with high probability.
评论 #43005736 未加载
评论 #43005200 未加载
trebligdivad3 个月前
Anyone got a simple implementation of &#x27;Tiny pointers&#x27;? My mind prefers code&#x2F;pseudo-code first rather than the proof.
quantum20223 个月前
This is neat! I always wondered if there would be a way to &#x27;containerize&#x27; tables like this. IE a regular table is like a bulk carrier ship, with everything stuffed into it. If you could better organize it like a container ship, you could carry much more stuff more efficiently (and offload it faster too!)
评论 #43012444 未加载
joe_the_user3 个月前
The theoretical properties of hash table always seemed so impressive to me that they bordered on magic (and this just extends them). What seemed crazy was how they could be so much better than trees, which to me were intuitively the most efficient way to store data.<p>What I realized is that the theory of hash tables involves a fixed-sized collection of objects. For this fixed collection, you create a hash-function and used that like a vector-index and store the collection in a (pre-allocated) vector. This gives a (fuzzy-lens&#x27;d) recipe for O(1) time insert, deletion and look-up. (The various tree structures, in contrast, don&#x27;t assume a particular size).<p>The two problems are you have to decide size beforehand and if your vector gets close to full, you insert etc processes might bog-down. So scanning the article, it seems this is a solution to the bogging down part - it allows quick insertion to a nearly-full table. It seems interesting and clever but actually not a great practical advance. In practice, rather than worrying a clever way to fill the table, I&#x27;d assume you just increase your assumed size.<p>Edit: I&#x27;m posting partly to test my understanding, so feel to correct me if I&#x27;m not getting something.
评论 #43005198 未加载
评论 #43008015 未加载
评论 #43005824 未加载
评论 #43005169 未加载
default-kramer3 个月前
&gt; And for this new hash table, the time required for worst-case queries and insertions is proportional to (log x)2 — far faster than x.<p>&gt; The team’s results may not lead to any immediate applications<p>I don&#x27;t understand why it wouldn&#x27;t lead to immediate applications. Is this a situation where analysis of real-world use cases allows you to tune your hash implementation better than what a purely mathematical approach would get you?
评论 #43005003 未加载
评论 #43006620 未加载
评论 #43009105 未加载
评论 #43005510 未加载
评论 #43004992 未加载
评论 #43005215 未加载
评论 #43005195 未加载
评论 #43008088 未加载
评论 #43005456 未加载
评论 #43006879 未加载
dooglius3 个月前
It looks like the result only matters in the case where the hash table is close to full. But couldn&#x27;t one just deal with this case by making the table size 10% bigger? (Or, if it is resizeable, resizing earlier)
评论 #43005975 未加载
评论 #43014286 未加载
throwme_1233 个月前
Is someone aware of a GitHub repo with an implementation of this?
评论 #43010373 未加载
matsemann3 个月前
The intro picture about pointers in a drawer immediately reminded me of a talk I saw at FUN with Algorithms 2018 called Mind the Gap that gave me an aha moment about leaving space in data structures. Cool then to try to locate it, and see that it was by the same professor in the article, Martín Farach-Colton.<p>Not sure if it&#x27;s viewable somewhere. But the conference itself was so fun. <a href="https:&#x2F;&#x2F;sites.google.com&#x2F;view&#x2F;fun2018&#x2F;home" rel="nofollow">https:&#x2F;&#x2F;sites.google.com&#x2F;view&#x2F;fun2018&#x2F;home</a><p>I&#x27;m not an academic and got my company to sponsor a trip to this Italian island to relax on the beach and watch fun talks, heh.
ThinkBeat3 个月前
Do we have some nice implementations yet? I do better reading code than math.
_1tan3 个月前
Neat, started on some implementation: <a href="https:&#x2F;&#x2F;kraftwerk.social&#x2F;innovation-in-hash-tables&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kraftwerk.social&#x2F;innovation-in-hash-tables&#x2F;</a>
cb3213 个月前
For a different, perhaps more practical take on small pointers in hash tables, you might find this interesting: <a href="https:&#x2F;&#x2F;probablydance.com&#x2F;2018&#x2F;05&#x2F;28&#x2F;a-new-fast-hash-table-in-response-to-googles-new-fast-hash-table&#x2F;" rel="nofollow">https:&#x2F;&#x2F;probablydance.com&#x2F;2018&#x2F;05&#x2F;28&#x2F;a-new-fast-hash-table-i...</a> with contemporaneous discussion at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17176713">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17176713</a>
sternma3 个月前
For anyone looking for a PoC implementation, here&#x27;s python:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;sternma&#x2F;optopenhash">https:&#x2F;&#x2F;github.com&#x2F;sternma&#x2F;optopenhash</a>
评论 #43012512 未加载
foota3 个月前
I guess the most we could hope for here is that this leads to some other discovery down the road, either in hashtables or maybe one of the similar structures like bloom filters?
nexawave-ai3 个月前
I would like to see this being applied practically. Is there a video demonstrating this or is it still too soon? Is the algorithm secret sauce or will it be open sourced?
elcritch3 个月前
Anyone else think this could be used with distributed hash tables to dramatically speed up searching or building them? Maybe more exoticly to LLMs and lookup tables. A clever algorithm like this should be applicable in a lot of more specialized data structures or applications.<p>It&#x27;s likely a DHT would greatly benefit from this sort of algorithmic reduction in time and be less susceptible to constant factor overheads (if there are any).
froh3 个月前
(2021) for the paper itself<p><a href="https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2111.12800" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2111.12800</a>
评论 #43010502 未加载
Canigou3 个月前
I unfortunately did not study well enough to understand the paper.<p>Can someone explain to me how this isn&#x27;t some kind of Dewey Decimal Classification (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Dewey_Decimal_Classification" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Dewey_Decimal_Classification</a>) ?
duskwuff3 个月前
Paper: <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2111.12800" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2111.12800</a>
评论 #43004580 未加载
shaganer3 个月前
Read this within my half hour break and man, wow what a story. I&#x27;m not a software guy, I&#x27;m a sys and net guy. Despite not caring or knowing about hash tables, that articles a great read! Thanks for sharing!
varjag3 个月前
tl;dr sublinear worst case query and insertion in hash tables.
评论 #43004785 未加载
评论 #43004794 未加载
seinecle3 个月前
Anyone competent enough here to venture a guess on the speed gain to expect under various scenarios?
isaacfrond3 个月前
The paper is here: <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2111.12800" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2111.12800</a><p>Curiously, Andrew Krapivin, the genious undergrad in the article, is not one of the authors.
评论 #43010756 未加载
评论 #43012063 未加载
评论 #43011393 未加载
reportgunner3 个月前
Sad that the article doesn&#x27;t say what his approach actually is.
bnly3 个月前
Step one: Be a genius<p>Step two: Try to solve hard problems<p>Step three: Avoid reading too much of other people&#x27;s work in the area<p>Step four: (Maybe) Invent a brilliant new solution<p>But really, really don&#x27;t skip step one.
jjallen3 个月前
Is it just me or did the article not go in to how the improvement works, just the speed of it?
评论 #43006127 未加载
评论 #43004817 未加载
评论 #43012062 未加载
lupire3 个月前
The older a conjecture is, the more likely it is false.<p>That&#x27;s why the conjecture resists proof -- there is an counterexample that people aren&#x27;t seeing.
DeathArrow3 个月前
And we are taught to not try reinventing the wheel!
评论 #43012489 未加载
pizza3 个月前
Just realized that the Mixture of Million Experts paper from last year is similar in some respects to this tiny pointers idea
aqueueaqueue3 个月前
How full is your typical production hashtable?
评论 #43010443 未加载
hoseja3 个月前
Is this just theoretically better O(n) or is there an actually faster implementation somewhere?
victor1063 个月前
&gt; The team’s results may not lead to any immediate applications<p>Why not?
评论 #43012716 未加载
qntty3 个月前
A cool result, but it seems like it should be called a computer science conjecture
评论 #43006002 未加载
评论 #43004912 未加载
EternalFury3 个月前
What’s the time and space complexity of the new approach?
amazingamazing3 个月前
This is a good test because it’s recent. Let’s see if deep research can come up with this result without just copying this.<p>Edit: gpt4, Gemini 2 and Claude had no luck. Human driven computer science is still safe.
评论 #43006700 未加载
评论 #43006120 未加载
评论 #43007326 未加载
hemant10413 个月前
Interesting read!
nickhodge3 个月前
I bet this guy would still fail a first round FAANG developer interview requiring a Hash Table solution to move on in the process.<p>&quot;Yeah, sorry. You didn&#x27;t use the right Hash Table&quot;
评论 #43010036 未加载
ziofill3 个月前
&quot;it is well known that a vital ingredient of success is not knowing that what you are attempting can’t be done.&quot; — Terry Pratchett (equal rites)
评论 #43008030 未加载
percentcer3 个月前
&quot;arrowlike entities&quot;
评论 #43012706 未加载
MR4D3 个月前
Reading through this article is like reading a description of the Monty-Hall problem. [0]<p>It&#x27;s as through the conclusion seems to defy common sense, yet is provable. [1]<p>[0] - <a href="https:&#x2F;&#x2F;priceonomics.com&#x2F;the-time-everyone-corrected-the-worlds-smartest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;priceonomics.com&#x2F;the-time-everyone-corrected-the-wor...</a><p>[1] - 2nd to the last paragraph: &quot;The fact that you can achieve a constant average query time, regardless of the hash table’s fullness, was wholly unexpected — even to the authors themselves.&quot;
评论 #43005069 未加载
评论 #43006321 未加载
评论 #43005371 未加载
评论 #43005764 未加载
jheriko3 个月前
i feel this article is missing some detail or incorrect in reporting the actual development here. either that or i am missing something myself...<p>hash tables are constant time on average for all insertion, lookup and deletion operations, and in some special cases, which i&#x27;ve seen used in practice very, very often, they have very small constant run-time just like a fixed-size array (exactly equivalent in-fact).<p>this came up in an interview question i had in 2009 where i got judged poorly for deriding the structure as &quot;not something i&#x27;ve often needed&quot;, and i&#x27;ve seen it in much older code.<p>i&#x27;m guessing maybe there are constraints at play here, like having to support unbounded growth, and some generic use case that i&#x27;ve not encountered in the wild...?
评论 #43009906 未加载
ascorbic3 个月前
And they wouldn&#x27;t make him first named author on the paper
评论 #43004948 未加载
评论 #43005225 未加载
评论 #43004965 未加载
ryao3 个月前
&lt;deleted&gt;
评论 #43005354 未加载
travisgriggs3 个月前
This is cool enough. But I find the &quot;celebrification&quot; style of the piece a bit off putting. Did I really need to see multiple posed shots of this young man reposing in various university settings? It&#x27;s like we need our own version of La La Land to glorify the survivors of computer success to motivate more to participate.
评论 #43007307 未加载
评论 #43006842 未加载
评论 #43007004 未加载
评论 #43007643 未加载
pmags3 个月前
Nice result!<p>&lt;rhetorical&gt; Hmm....I wonder how such research gets funded?... &lt;&#x2F;rhetorical&gt;
评论 #43008153 未加载
评论 #43007481 未加载
jimnotgym3 个月前
Now we have faster data structures we can fill that extra time by writing less efficient code, and loading more pointless libraries. This is the march of computer science.
ChrisMarshallNY3 个月前
As the villain in <i>Scooby Doo</i> always said:<p><i>&quot;And I would have gotten away with it, if it hadn&#x27;t been for those meddling kids!&quot;</i>
zombiwoof3 个月前
Take that AI :)
sam0x173 个月前
This is huge, when can we get a rust implementation?
评论 #43004480 未加载
评论 #43004736 未加载
bruce3434343 个月前
Ok so what&#x27;s the algorithm? Ass article
kittikitti3 个月前
I read through this and I&#x27;m not sure if people have heard of dictionary trees for hash tables. Of course, quantamagazine.org has been known to sensationalize these types of things.
评论 #43007984 未加载